15:01:03 <balunasj_mtg> #startmeeting
15:01:03 <jbott> Meeting started Thu Jun  9 15:01:03 2011 UTC.  The chair is balunasj_mtg. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:03 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:24 <bleathem> Hello everyone!
15:01:34 <balunasj_mtg> #info Agenda for today: http://community.jboss.org/wiki/RichFacesTeamMeetingAgenda6-9-2011
15:01:37 <jhuska> hello
15:01:43 <balunasj_mtg> jhuska: Hi
15:02:22 <balunasj_mtg> Pavol is on PTO today from QE, but the other guys are here
15:02:40 <balunasj_mtg> #topic Git migration
15:02:55 <balunasj_mtg> #info as you can see in the agenda we are very close to wrapping this up
15:03:17 <balunasj_mtg> #info lfryc has done a great job, and we only have a few open items left
15:03:49 <balunasj_mtg> BTW - we can officially welcome bleathem to the team as a red hat employee :-)
15:04:04 <lfryc> bleathem: welcome on board :-)
15:04:07 <lfryc> balunasj_mtg: one thing that left is decide about naming of FishEye repos
15:04:10 <bleathem> thanks! :D
15:04:25 <juank_prada> welcome although im not part of Red Hat (wishing i was)
15:04:30 <balunasj_mtg> lfryc: I've added various items to the agenda
15:04:44 <balunasj_mtg> lfryc: what do you want to start with?
15:05:10 <lfryc> I have also added some of them, just to finish some points
15:05:20 <lfryc> I would follow the structure..
15:05:24 <lfryc> basically here are current structure of FishEye: http://source.jboss.org/browse/
15:06:13 <lfryc> ah, I can see there are some changes done recently, so I need to sync up with Vlastimil
15:06:26 <lfryc> nevermind, I wil continue with other points
15:06:39 <balunasj_mtg> lfryc: please remember to use meetbot
15:06:57 <lfryc> #info I have prepared proposal of workflow which was published at http://community.jboss.org/docs/DOC-16874
15:07:08 <balunasj_mtg> #action lfryc follow up with Vlastimil on fisheye integration
15:07:36 <lfryc> bleathem: have you time to review it?
15:07:39 <balunasj_mtg> ppitonak: glad you could make it!
15:07:39 <bleathem> lfryc: the proposed workflow looks good!
15:07:50 <bleathem> one question
15:07:55 <ppitonak> balunasj_mtg: hi
15:08:06 <balunasj_mtg> #info this has been reviewed by balunasj_mtg and bleathem
15:08:07 <lfryc> ppitonak: just starting to discuss workflow..
15:08:14 <bleathem> apparently in github you can change the default branch that a user forks, when they fork the project
15:08:23 <bleathem> should we change this default fork to the develop fork?
15:08:34 <lfryc> bleathem: yes, thats on the agenda, I propose to change it to develop
15:09:08 <bleathem> ok, cool - sorry for jumping the gun
15:09:18 <balunasj_mtg> yup it can be set per repo
15:09:38 <lfryc> bleathem: but as I had mentioned, we should also encourage to use master in situations when develop would like to integrate the fix into his application immediately
15:09:38 <balunasj_mtg> lets work through the list, and then at the end we'll cover anything additional
15:09:59 <lfryc> bleathem: it might be problem to use cutting edge develop branch in these situations
15:10:55 <lfryc> #info I have also prepared Guide how to use pull request with RF JIRA (which has newly enabled Git workflow to support this model)
15:10:56 <balunasj_mtg> lfryc: Let shelf that now - and we'll cover when it is time in the agenda
15:11:23 <balunasj_mtg> #action balunasj_mtg review the pull request and rF jira workflow document
15:11:32 <lfryc> #info Guide can be found here and applies also to other projects: http://community.jboss.org/docs/DOC-16877
15:12:11 <lfryc> #info first point what we need to refine is modifying the existing branches structure to meet the workflow
15:12:47 <lfryc> we have lot of branches migrated from SVN and we simply don't need them anymore
15:13:09 <lfryc> the sample is here: https://github.com/richfaces/core
15:13:27 <balunasj_mtg> #agreed We can get rid of the branches that are not part of the current workflow
15:13:53 <balunasj_mtg> lfryc: any complications there - do you think?
15:14:17 <lfryc> balunasj_mtg: there should not be any problem since we will keep the tags
15:14:28 <lfryc> balunasj_mtg: but further question is what tags we would like to keep there
15:15:02 <lfryc> balunasj_mtg: bleathem any ideas why we should keep tags before 4.0.0.Final?
15:15:09 <bleathem> I don't think there is any need to get rid of the tags
15:15:29 <balunasj_mtg> lfryc: agreed - the tags that are there are accurate
15:15:35 <bleathem> they don't get in the way, but do add some context to the commit history
15:15:50 <balunasj_mtg> lfryc:  it is nice it did not migrate some of the MUCH older tags
15:16:04 <lfryc> #action lfryc will fire issue for removing all the unnecessary branches and tags (it means all except master and 4.0.0.Final)
15:16:37 <balunasj_mtg> lfryc: where are you seeing older tags?
15:16:52 <lfryc> balunasj_mtg: https://github.com/richfaces/core
15:17:13 <lfryc> under Switch tags, there are lot of tags - and it is the same as for each other repository
15:17:28 <balunasj_mtg> lfryc: I'm only seeing tags that are part of the 4.0.0 cycle
15:17:37 <lfryc> balunasj_mtg: yes
15:17:43 <balunasj_mtg> lfryc: I'm seeing 20 tags - I think those are fine
15:17:59 <lfryc> balunasj_mtg: ah, do you think we should keep all of them?
15:18:32 <balunasj_mtg> lfryc: yes - I don't think they get in the way and provide a good reference point for history
15:18:56 <lfryc> balunasj_mtg: some of them are duplicated per version because of respins (Final, M6)
15:19:09 <lfryc> balunasj_mtg: what about keeping only the last of each release?
15:19:46 <balunasj_mtg> lfryc: yup those are fine I think too - I just with the alpha's shared the same timestamp notation so they were in order
15:20:04 <bleathem> going forward, those feature branches would have been merged back into master
15:20:26 <bleathem> so the commits/tags will not be lost
15:20:36 <balunasj_mtg> bleathem: The release tags you mean?  or something else?
15:20:41 <bleathem> but if you remove the branches now, will the commits/tags be lost?
15:20:56 <bleathem> the release tags and branches
15:21:05 <bleathem> balunasj_mtg: the release tags and branches
15:21:08 <lfryc> bleathem: I assume keeping the tags in place will mean that the commit history won't lost
15:21:28 <balunasj_mtg> lfryc: agreed
15:21:31 <bleathem> but if you remove the branch, won't it remove all associated commits/tags that are not merged?
15:21:34 <balunasj_mtg> but I'm not git expert
15:21:52 <lfryc> bleathem: not an annotated tag (but will need to verify on personal repo)
15:22:11 <balunasj_mtg> so a good note to add with meetbot ;-)
15:22:45 <lfryc> #info stale branches can be removed as long as it will not remove the tags
15:22:53 <bleathem> 1 year from now we will all be git and meetbot ninjas!
15:23:07 <bleathem> well, hopefully sooner than 1 year...
15:23:30 <balunasj_mtg> I'm still getting used to it too
15:24:00 <lfryc> #info also there should be left only last of release tags
15:24:08 <lfryc> what about renaming the tags?
15:24:22 <lfryc> do you think we should rename them to 4.0.0.CR1, etc.?
15:24:33 <balunasj_mtg> lfryc: I'd like the Alpah tags renamed to follow the timestamp format
15:24:43 <balunasj_mtg> lfryc: I like it because it keeps everything in order
15:25:11 <lfryc> #action lfryc rename the tags to follow timestamp pattern
15:25:44 <lfryc> ok, let's continue with other points... any other comments?
15:26:00 <balunasj_mtg> lfryc: So just be be clear when done we will have master --> 4.0.0.Final
15:26:08 <balunasj_mtg> and develop --> master
15:26:12 <balunasj_mtg> current master
15:26:33 <bleathem> master is not going to be the release branch?
15:26:43 <lfryc> balunasj_mtg: exactly
15:26:56 <lfryc> bleathem: we will start releases on develop and finally introduce tag into master
15:27:15 <lfryc> bleathem: it means master will reflect the last stable release
15:27:31 <bleathem> ok, I misunderstood the "-->"
15:27:41 <bleathem> "-->" means merge into then?
15:28:01 <balunasj_mtg> bleathem: Sorry I just meant changing to be it;
15:28:03 <lfryc> yes, master will be reset to 4.0.0.Final
15:28:34 <lfryc> #action rename the master branch to develop
15:28:38 <bleathem> ok, and we will develop on "develop", which will get merged into master
15:28:49 <balunasj_mtg> bleathem: after a release yes
15:28:58 <lfryc> #action create new master branch pointing to 4.0.0.Final
15:29:09 <bleathem> got it!
15:29:22 <balunasj_mtg> ok - all that looks good
15:29:38 <balunasj_mtg> lfryc: want to move to next sub topic?
15:29:39 <lfryc> #action lfryc:  setup GitHub to have develop as default
15:29:45 <lfryc> balunasj_mtg: yes
15:30:01 <alexsmirnov> Hi, guys. you going to break git conventions and would confuse developers - usually, master is main development stream.
15:30:02 <lfryc> #info other topic is RFPL JIRAs and pull request workflow
15:30:09 * balunasj_mtg we need to have refactor agendas to allow for more topics instead of sub-topic
15:30:32 <balunasj_mtg> alexsmirnov: There are lots of workflows outthere
15:30:49 <bleathem> alexsmirnov: by setting the default branch appropriately in github, it should be transparent to the dev
15:30:59 <bleathem> they just fork, commit, and open a pull request
15:31:01 <balunasj_mtg> alexsmirnov: event in the book "pro-git" there were different approaches
15:31:10 <lfryc> alexsmirnov: that is not convention - I think developers which are not much experienced with project should start on master, which will reflect last stable release
15:32:07 <lfryc> alexsmirnov: more experienced users may get involved and know that develop is the main development branch and it is up to date
15:32:31 <balunasj_mtg> plus use of develop branch and feature branches is common
15:32:37 <balunasj_mtg> alexsmirnov: is that not your experience?
15:32:41 <lfryc> the only problem is about documenting this principle
15:33:01 * balunasj_mtg I'm going to start a new topic for next sub-topic
15:33:13 <balunasj_mtg> lfryc: I think you have done a good job at that in the workflow
15:33:26 <bleathem> lfryc: +1 !
15:33:47 <lfryc> balunasj_mtg: yes, please
15:34:11 <balunasj_mtg> #topic RFPL jira's and pull requests
15:34:38 <balunasj_mtg> #chair lfryc
15:34:38 <jbott> Current chairs: balunasj_mtg lfryc
15:34:59 <lfryc> #info RFPL contains issues which doesn't introduce commits
15:35:21 <lfryc> #info that's why they doesn't support pull requests
15:35:52 <lfryc> #info when developer works on RFPL JIRA which finally introduces commit and pull request, it have to be reflect in RF JIRA
15:36:12 <lfryc> #info either by creating and linking new RF JIRA or simply moving the JIRA into RF space
15:36:18 <alexsmirnov> balunasj_mtg: My only concern that atmost all other projects use master or svn trunk for development code, and mark releases by tags/branches. You just break that common wisdom, so anybody who come to project will confused.
15:37:11 <lfryc> alexsmirnov: do you think it is enough to document in header of our repositories?
15:37:14 <balunasj_mtg> alexsmirnov: I've seen a lot of people using develop - for latest dev.
15:37:39 <lfryc> also Seam is going to go this way..
15:37:52 <lfryc> any comments for RFPL and pull request work flow?
15:38:42 <lfryc> I will move to other topic
15:38:43 <bleathem> lfryc: I like the distinction between requiring/not-requiring a commit.  very clear
15:38:57 <lfryc> #topic Sharing feature branches
15:38:58 <balunasj_mtg> #agreed If RFPL jira results in source code updates to core project is should be moved to RF
15:39:33 <lfryc> #info feature branch may not be needed to be shared in project repositories
15:39:54 <lfryc> #info two developers can share code in personal repositories
15:40:06 <lfryc> #info it satisfies that no one will start work on feature branches
15:40:19 <lfryc> #info but seems to be very restricting rule
15:40:44 <lfryc> balunasj_mtg: you have commented in previous discussions, do you want comment here?
15:41:00 <balunasj_mtg> yup
15:41:41 <balunasj_mtg> #info For large tasks sharing a feature branch in the project repo is ok,
15:42:06 <balunasj_mtg> #info The same rules apply - when the jira is resolved and branch merged the feature branch can be removed
15:42:56 <lfryc> #agreed with removing branches
15:43:10 <balunasj_mtg> #info We will likely need to go through and "clean up" from time to time anyway - and the rule will be that features branches for resolved jira's can be removed
15:43:22 * balunasj_mtg all set on this topic from my pov
15:43:31 <bleathem> when developers work together on a feature branch, should the merges be ff? (as opposed to merging the into develop, which is a no-ff merge) branch
15:43:55 <lfryc> balunasj_mtg: what's the purpose for having large tasks directly in RF repository?
15:44:35 <lfryc> bleathem: I prefer final commit into develop being one merge commit
15:44:48 <bleathem> really?
15:44:56 <balunasj_mtg> lfryc: more visibility and easier sharing if the task needs to shift between people.
15:45:27 <balunasj_mtg> lfryc: but there is rebasing going on right?
15:45:32 <bleathem> I like the quote "we don't develop in a linear fashion, so why force our commit history to be linear"
15:46:19 <bleathem> rebasing on a shared repository will break things
15:46:46 <lfryc> bleathem: my preference is initiated in having one feature for component as one commit
15:46:59 <lfryc> bleathem: it may be better reviewable in the pull request
15:47:04 <balunasj_mtg> ah true that can cause issues - rebasing.
15:47:37 <bleathem> lfryc: that seems to be a little restrictive to me
15:47:41 <bleathem> some features are big
15:48:11 <balunasj_mtg> bleathem: what do you propose?
15:48:35 <bleathem> no-ff merges for merging feature branches into master
15:48:57 <bleathem> as per the suggestion in the original git workflow document
15:49:14 <lfryc> bleathem: but I agree with no-ff, maybe we have misunderstood each other :-)
15:49:59 <bleathem> so you are saying no-ff, but rebased into a single commit?
15:50:41 <lfryc> bleathem: as I understand it, no-ff will introduce new commit based on merging changes in paralel branch, right?
15:50:54 <bleathem> yes
15:51:11 * balunasj_mtg unless this can be cleared up in next minute - let move this to the dev forum so we can move on
15:51:25 <bleathem> ok, dev forum is fine with me
15:51:33 <lfryc> sure
15:51:46 <lfryc> #topic Release criteria
15:51:52 <balunasj_mtg> ok thanks - just want to get through more of the agenda - and have break outs as needed
15:52:18 <balunasj_mtg> #action lfryc post a dev forum post about previous topic to continue
15:52:27 <lfryc> thanks
15:53:01 <lfryc> #info the part of release testing criteria is that release should not start before the branch is stabilized
15:53:12 <lfryc> #info the new workflow is just following it
15:53:49 <lfryc> #info the difference from the past is based that functional tests wasn't ran just prior to each release
15:54:16 <balunasj_mtg> lfryc: If that is more than just build/unit test - then it needs to be automated in CI and build regularly
15:54:53 <balunasj_mtg> In my experience the longer the release process the fewer releases - and we want to keep ~1 month one we get to M1
15:54:57 <lfryc> balunasj_mtg: yes, important is that tests needs to be reviewed currently to satisfy that there are no errors
15:55:12 <lfryc> (functional tests)
15:55:14 <balunasj_mtg> ppitonak: This is more your area - I would like you to assist with defining this
15:55:43 <balunasj_mtg> ppitonak: What is covered, and what is satisfactory to you
15:55:56 <ppitonak> balunasj_mtg: basically in Richfaces 3.x and 4.0 we didn't follow test plan
15:56:09 <ppitonak> balunasj_mtg: we didn't run functional test before tagging
15:56:18 <ppitonak> balunasj_mtg: this is what I want to avoid
15:56:42 <ppitonak> balunasj_mtg: so my idea is to run all unit tests and some reasonable number of functional tests before creating a release branch
15:56:44 <lfryc> balunasj_mtg: my though is starting release after approval from QA - it will avoid necessity to running release tests which will found new issue
15:56:56 <bleathem> can't we run these functional tests via CI with ever push?
15:57:01 <balunasj_mtg> ppitonak: sure - we just need to make sure executing those tests are as easy as possible.  Ideally in CI
15:57:13 <balunasj_mtg> bleathem: iirc some take a long time
15:57:27 <bleathem> or run them nightly via CI?
15:57:28 <lfryc> bleathem: we can, but it takes ~2.5hrs for smoke tests and ~1.5days for complete suite
15:57:55 <balunasj_mtg> ppitonak: The smoketests is what should pass, but agree these need to be run every night
15:57:56 <lfryc> bleathem: and depends also on availability of machines in Hudson
15:58:06 <bleathem> cloudbees!
15:58:23 <ppitonak> bleathem: that would not work at the moment
15:58:28 <balunasj_mtg> I don't want to end up waiting 1/2 day or more to push a release because we're waiting on builds
15:58:46 <ppitonak> balunasj_mtg: neither do I
15:59:05 <ppitonak> balunasj_mtg: that's the reason why we wouldn't wait for all ftests
15:59:07 <balunasj_mtg> ppitonak: can these or are these run everynight?
15:59:17 <balunasj_mtg> the smoke tests I mean
15:59:18 <ppitonak> balunasj_mtg: they do
15:59:25 <ppitonak> balunasj_mtg: but the suite is not stable enough
15:59:36 <ppitonak> balunasj_mtg: there are about 2500 tests
15:59:39 <balunasj_mtg> ppitonak: the smoke tests or the whole suite?
15:59:42 <ppitonak> balunasj_mtg: from which 30-60 are failing
15:59:48 <ppitonak> balunasj_mtg: smoke test
16:00:01 <balunasj_mtg> ppitonak: ok so before we go M1 we need this to be working
16:00:11 <ppitonak> balunasj_mtg: agree
16:00:34 <balunasj_mtg> #action ppitonak please create jira's to cover stabilizing smoke test ftest suite before M1
16:00:39 <balunasj_mtg> I would make that a blocker for M1
16:00:53 <ppitonak> balunasj_mtg: sounds good
16:00:56 <balunasj_mtg> Here is the flow I would be ok with
16:01:12 <balunasj_mtg> 1) code freeze on day X ( end of day )
16:01:22 <balunasj_mtg> 2) Builds run overnight
16:01:38 <balunasj_mtg> 3) on Day X+1 if builds pass we start the process
16:01:41 <balunasj_mtg> release
16:02:08 <balunasj_mtg> sound right^
16:02:16 <ppitonak> balunasj_mtg: yes, that should work fine
16:02:20 <ppitonak> balunasj_mtg: one little detail
16:02:52 <ppitonak> balunasj_mtg: I don't see any reason in running the same tests again after a release branch was created
16:03:19 <balunasj_mtg> ppitonak: ok - you could start with the full suite then right?
16:03:34 <ppitonak> balunasj_mtg: yes
16:04:24 <ppitonak> balunasj_mtg: what I want to achieve is to run only manual tests during release testing (after creating branch)
16:04:31 <ppitonak> balunasj_mtg: that won't be possible for 4.1.0
16:04:43 <ppitonak> balunasj_mtg: but this is long-time goal
16:04:57 <balunasj_mtg> that is valid
16:05:16 <balunasj_mtg> So lets go with the release criteria above and move on
16:05:23 <balunasj_mtg> we can adjust as needed
16:05:32 <ppitonak> ok
16:05:39 <lfryc> ok
16:05:49 <balunasj_mtg> #action ppitonak document release criteria for 4.1 releases
16:06:01 <lfryc> the last point was already discuss: Renaming master branch to develop + reverting master to 4.0.0.Final
16:06:10 <balunasj_mtg> lfryc: anything else for git migration?
16:06:23 <lfryc> balunasj_mtg: not from my side, maybe other comments?
16:06:52 <bleathem> it all sounds good to me, just the merging details to work out on the dev forum
16:07:15 <balunasj_mtg> agreed - then documented on wiki and we will be good to go
16:07:36 <balunasj_mtg> #topic 4.1 planning
16:07:48 <balunasj_mtg> #info we are already over time for the meeting
16:08:05 <balunasj_mtg> #idea Have a separate meeting just for 4.1 finalization and discussing
16:08:24 <lfryc> #agreed yes, it would be good at this situation
16:08:27 <balunasj_mtg> #info because of timing it would be post JSFSummit
16:08:58 <balunasj_mtg> #info before then I'll email specific tasks and things that should be ready before then so we can hit that meeting ready to nail down specifics
16:09:09 <bleathem> does this keep us on track schedule-wise?
16:09:20 <bleathem> for the M1?
16:09:26 <balunasj_mtg> #action email specific tasks and things that should be ready before then so we can hit the meeting ready to nail down specifics
16:09:56 <balunasj_mtg> bleathem: we are going to need to cut down M1 and push to end of July imo
16:10:16 <balunasj_mtg> bleathem: We have tasks that need to get done before that
16:10:20 <balunasj_mtg> like git migration
16:10:25 <balunasj_mtg> getting you up to speed
16:10:41 <balunasj_mtg> jira reviews and update estimating
16:10:44 <balunasj_mtg> etc..
16:11:18 <bleathem> sounds reasonable
16:11:20 <balunasj_mtg> I want to get as much "prep" done in June so we can hit July running for M1 - but it is going to be tight I think
16:12:13 <balunasj_mtg> In the mean time I need everyone to review the docs - like the listshuttle, editor, etc.. and add comments, or ideas
16:12:50 <balunasj_mtg> #action everyone needs to review the docs in the agenda, and add comments, or thoughts.
16:13:16 <lfryc> yes, for the Editor, I will also follow on forums with my thoughts
16:13:31 <balunasj_mtg> lfryc: thanks - including reseaching alternative impls
16:13:47 <balunasj_mtg> anything else for now - from anyone?
16:13:54 <lfryc> balunasj_mtg: have you reviewed my sub tasks for editor?
16:14:07 <lfryc> balunasj_mtg: I'm curious if I haven't missed something important there
16:14:30 <balunasj_mtg> yup - I saw those after I posted the agenda  - sorry about that
16:15:05 <lfryc> ok, np, I will wait for your comments..
16:15:19 <balunasj_mtg> lfryc: question - where is the "implement the rich:editor subtask" :-)
16:15:35 <lfryc> balunasj_mtg: can you point me to JIRA? :-)
16:16:54 <lfryc> balunasj_mtg: good point :-) it would be good to have implementation..
16:18:07 <balunasj_mtg> :-)
16:18:09 <lfryc> + documentation for component
16:18:15 <balunasj_mtg> ok anything else for now?
16:18:22 <bleathem> I'm good
16:18:31 <lfryc> nothing from me
16:18:45 <balunasj_mtg> ok then thanks all and I'll get the minutes posted after lunch
16:18:50 <balunasj_mtg> #endmeeting