Re: [gentoo-portage-dev] The road ahead...

[Zac Medico]

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@g.o mailing list