On May 22, 2009, at 12:04 AM, David Brownell wrote:
On Thursday 21 May 2009, Øyvind Harboe wrote:You didn't talk about when you cut the branch. I don't think we wantto slow down development in svn head for much more than a week or two?Alternatively, isn't the "branch" where all non-essential stuff should be parked until head is stabilized and cuts the release? With everyone focussing energy on the release, instead of any non-essential stuff?
I'm not fond of making branches to serve as the "trunk after the release". That just makes a lot of work for the release maintainer to straighten out the tree later. Now, I'm all for having large features developed on branches.
(Or what lots of folk do: private "quilt" series, updated as needed, until head opens to non-bugfix patches.)
I encourage developers to use tools like git-svn or quilt to build and maintain patchsets until they can be integrated into the trunk.
Agreed that key "when" parts were missing. Pending a working testing/QA/bug tracking proposal ... should there at least be a working schedule the next release? Maybe like: 25 May (Monday) -- last "features" go in ... four weeks of stability/testing/fixing/polish ... with weekly milestone labels, "RC1", "RC2", etc 22 June (Monday) -- target for release That's just an idea. Maybe three weeks of focussed work is a better target; only take another if that doesn't suffice. - Dave
A while back, we had kicked around a tentative date of 7/1. I'm not tied to it by any means, but it does seem to provide sufficient time to stabilize. As for doing RCs, I like to start that in the last 2 week window when the accepted patches are few and the branch has been cut. That way the RCs are tagged from the branch and things are already pretty stable.
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
