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
