On Sunday 16 October 2005 14:20, Zac Medico wrote: > I am very impressed with the number of bugs closed in preparation for the > 2.0.53 release (dependencies of bug 108082) and it seems like it is in > everyone's best interest to keep up this pace so that all the easy bugs are > closed ASAP. There is already a large list of *open* dependencies for the > 2.0.54 (bug 108262) that will hopefully be closed and released soon. :)
It will likely be that some of the bugs marked against 108262 won't be fixed in time. Perhaps it would have been better to just open a metabug when the branch is opened and mark bugs against it as they are fixed. > It should be possible to integrate some refactorings+features without too > much slowdown of the easy bugfix release pace (call it the EBRP for now). > IMO the timing of such merges should be limited to times that everyone > (people with commit access) agrees will have a minimal impact on the EBRP. Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now worked out. Perhaps something like a 6 week cycle would be good? 2 weeks for any change, 2 weeks for small changes only, 2 weeks stabalizing... On Saturday 15 October 2005 14:16, Brian Harring wrote: > Really not much for 2.1 (existing ebd based) being brought up as a > release line N months down the line, since 2 branches of development > is a pita enough, let alone 3 with fairly radical differences between > each branch. Not saying the path can't be tweaked as we're > proceeding, but would *really* like to know that as a group/community, > this is what we're going towards rather then in N different > directions. I don't really like the idea of trunk being stabalized either. Too much work to bring forward all the changes in stable as well as fixing its own bugs. On Saturday 15 October 2005 13:59, Brian Harring wrote: > On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote: > > So, there's pretty much three ways we can go: > > > > 1) Backport refactorings+features and release. > > 2) Fix more bugs, backport refactorings+features and release. > > 3) Fix more bugs, release, backport refactorings+features and release. > > Aside from the 2.1 name being already slightly abused, prefer option > 4, bug/release work, integrating chunks in as they're ready and > releasing when things are stable. Basically... when the chunks are > ready to be integrated, they've been tested (ala cache patch + some > more time), yank the suckers in, and continue with stabilising towards > a release. To clarify: Treat backports as regular bugs and go through cycles of open the 2.0 branch for fixes for a while followed by stabalizing for a while? > On the subject of versions, which ever version the chunks get included > under, they're going to need integration testing, so versioning isn't > as much an issue to me as time. > > The delta between 2.1 and 2.0, last time I generated it was half a > meg; pulling chunks from 2.1 into 2.0 requires rewriting a chunk of > glue, so minimizing the time/delta is something of a concern- eg, > doing 2.0.* for a while, then a 2.1 I'm not totally much for. The thing I'm concerned about is the backports and bigger bugs that will require a longer stabalizing period. That and the fact that a few of them are also quite major in terms of what the user sees. It makes sense to me to group these together, bump the version to 2.1 and finally make the version numbers meaningful. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
