Taking the branch on the 14th and making an RC1 on the 14th is possible, just the RC is likely to be a little rough as there won't be much time at all to do checking. But as we're talking about RC1 not expected to be _the_ RC then i guess that could be fine.
...ant On 8/28/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > This sounds pretty close to what I had in mind. But I'm concerned about > cutting the branch before the 14th. IMO the 14th is the earliest > possible date we could cut the branch that would allow us to get enough > done in the trunk to put us in a position to move into this more > controlled mode. > > Simon > > ant elder wrote: > > > On the question of differing JIRAs, I think it depends on the JIRA :) > > > > We have to be careful making too many changes in the branch as > previously > > there's always been regressions due to changes. There's also the > question of > > who does the work - just raising a JIRA doesn't get the problem fixed > and > > with the time pressure of getting an RC out there's not so much the > release > > manager can do with a whole lot of open JIRAs other than defer them. > > > > How about doing these two things: > > 1) after the branch is cut become more and more strict about not making > > changes as RCs are done > > 2) JIRAs raised as critical or blocking don't deferred without agreement > > from the raiser or ML discussion > > > > So that would mean something like: Make an RC1 by the 14th for review, > not > > really expecting that to be the final 1.0 but having an RC to vote on > makes > > reviewing easier. The branch would be cut a little before the 14th to > get > > things ready. People raise JIRAs for issues they find while reviewing > and > > ideally fix the problem in branch and trunk themselves, but otherwise > > general development and changes are kept to a minimum in the branch but > > still possible if absolutely required. Then by the 18th start > vote/review > > for RC2 and from then be more strict about what changes go into the > branch, > > non-trivial fixes are only moved from trunk to branch after some > community > > review and permission of the RM. Non critical or blocking JIRAs get > > deferred, those blocking ones get discussed and fixed if a volunteer is > > found to fix them in a suitable time frame. > > > > That gives time for three or maybe even four RCs and IPMC voting and a > > release in September. > > > > ...ant > > > > On 8/28/07, Simon Nash < [EMAIL PROTECTED]> wrote: > > > >>Cutting the branch around the 14th to give more time to get the > >>release into shape sounds good. > >> > >>We always seems to run into lots of minor sample problems when > >>we produce an RC and I would expect that we would use some of > >>the time after cutting the branch to fix these up and polish the > >>samples. I'm not sure what we would do about "functional" problems > >>after the branch has been cut. For the 0.9x releases we have > >>tended to defer many of these JIRAs to the next release. For 1.0, > >>I would expect there to be a greater focus on making sure the > >>function we deliver in this release is working correctly. So I > >>could imagine a 1.0 RC respin to fix a JIRA in the branch for a > >>functional problem that is serious from a user perspective. > >> > >>Is this in line with others' expectations? > >> > >> Simon > >> > >>Jean-Sebastien Delfino wrote: > >> > >> > >>>ant elder wrote: > >>> > >>> > >>>>On 8/9/07, Venkata Krishnan < [EMAIL PROTECTED] > wrote: > >>>> > >>>><snip> > >>>> > >>>>- Post 0.95, maybe a couple of weeks after the release, we'd cut > >>>> > >>>> > >>>> > >>>>>another branch and head with that for 1.0 release. Being a 1.0 > >>>>>release, we prob. need a branch early as that so that we can whet the > >>>>>things we are targetting for the release. > >>>>> > >>>> > >>>> > >>>> > >>>>This seems like a really good idea to me. The 0.99 release has again > >>>>shown > >>>>that it always takes at least a couple of RCs to discover and resolve > >>>>regressions caused by last minute changes and to polish up the > >>>>samples, and > >>>>for 1.0 we're all likely to be a bit more pedantic about readme and > >>>>sample > >>>>problems. How about aiming for a 1.0 branch and RC1 around the 14th of > >>>>September? That gives 3 weeks from now for getting things ready and > >>>>then two > >>>>weeks which should enough for 2 or 3 RCs and voting and still get a > >>>>1.0 in > >>>>September. > >>>> > >>> > >>> > >>>+1 > >>> > >>> > >>>>I've created a 1.0 JIRA version and started moving into there JIRAs > >>>>i'd like > >>>>to try to get done for 1.0 : > >>>> > >> > >> > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312698 > >> > >>>> > >>> > >>>Nice! I think we should all spend a little bit of time now to take look > >>>at the JIRAs that we ran into recently. I suggest the following: > >>>- target them for SCA-1.0 if you care about them > >>>- volunteer for them and assign to yourself if you really care about > >>>them :) > >>>- target them for SCA-next if you think they can be handled post 1.0 > >>> > >>> > >>>I'll go over the JIRAs I know enough about in the next 2 days. > >>> > >>> > >>>>One thing that would be good to do now while they're fresh in our > >>>>minds is > >>>>for people to commit fixes to trunk for all the sample and readme > >> > >>issues > >> > >>>>they reported in the 0.99 review so they don't get forgotten till > >>>>1.0review. > >>>> > >>>> ...ant > >>>> > >>>> > >>> > >>> > >>>+1 > >>> > >> > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
