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]
