Jason Stubbs wrote:

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's nice to have a list of open bugs against the release where everyone can 
see it.  I suppose this mailing list can serve that purpose though.


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...


I'm not so sure about the "2 weeks for *any* change" part. We need to be very 
selective about the larger changes.

<snip>

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?

<snip>

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.


Longer stabilization periods also concern me.  Many of the larger changes 
should probably be reserved for a major version bump.  However, it's possible 
that along the way, some larger changes will be possible without significantly 
increasing the stabilization periods.  Of course, such changes should be 
carefully evaluated and the time that they are merged should be carefully 
coordinated.

Zac
--
gentoo-portage-dev@gentoo.org mailing list

Reply via email to