Re: A suggestion for the woody freeze
> I read and failed to understand your proposal for how a release might
> work. You don't provide enough detail that I understand you.
You are right, I try to give more detail below.
> Second, you fail to explain why your scheme is likely to do better
> than what we have now. You could make the argument that your scheme
> is better because it is diffirent and what we have now is clearly
> broken. I wouldn't accept that argument because I don't think it is
> strong enough.
Yes, sorry, I missed this:
1. It should be clear when a package gets removed from testing and
everyone should have a chance to fix the problems before a package gets
removed.
2. It should be clear to every developer what will happen at which time
within a freeze.
3. A freeze should be organized in a way that it's efficient in the sense
that we waste neither work nor time.
regarding 1. and 2.:
In my scheme everyone every developer knows which RC bugs must be fixed
until a certain date. This gives also motivation because you see the
progress when e.g. after the first bug squashing cycle all RC bugs older
than two weeks are eleminated and the number of RC bugs is at a lower
level.
regarding 3.:
I'm currently missing any idea of how to come to the next stage of the
freeze in the current scheme. My idea is to have two weeks cycles (like we
had them at the potato freeze) - and the next one should always start
immediately after the one before ended.
> I think you need to show why your proposal is going to get us a
> release faster. You show a faster timeline, but that isn't
> sufficient. You need to show that your time line is realistic. You
> need to convince us (the developers) that there won't be too many RC
> bugs that you are forced to slip your time line because the release
> candidate is not acceptable. Until you do that I don't think your
> proposal is a good idea.
To release at the end of June means that there's room for 10 two week
cycles, which means e.g. eight bug squashing cycles and two release
candidates. IMHO it's realistic to get all packages into a releasable
state after eight cycles when each of them should fix all RC bugs that
were present at the beginning of the cycle and no new upstream versions
are allowed during the freeze.
cu
Adrian
Reply to: