Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote:
> You're saying:
>
> Problem:
> I acknowledge that people are not interested in stable releases
> enough and that the RT has to compensate all the time.
Those two statements are true:
- A subset of DDs care about doing stable releases. The rest of DDs
don't care.
- A subset of DDs care about doing 'rolling'. The rest of DDs don't
care.
The release team obviously cares about stable releases, and I mostly
read the individual positions of RT members in this thread as "if we do
'rolling', it will be harder to do stable releases." Their position is
completely understandable. It's likely that doing 'rolling' will impact
stable releases in some ways. Some of the impact might be negative, some
might be positive.
But what we (the project) need to decide on is where we want to go.
After all, we could decide not to do stable releases, or to do them
every six months instead of every two years. The current choice of
doing stable releases every two years is there only because a large
subset of DDs care about doing that.
It seems that the 'rolling' idea has some supporters. So what we need to
do is:
1. determine one or more action plans around the 'rolling' idea, and
their impacts on all the parts of the projects (including the process of
doing stable releases). This thread provides great input about that, and
badly needs someone to do a summary (hint hint).
2. determine who is in support of each action plan, through a GR or a
poll.
There are some 'cheap' ways (for the project) to do 'rolling'. For
example, we could decide to:
[Plan A -- s/testing/rolling/:]
- rename testing to rolling
- advertise it as something end-user friendly
- manage it exactly like testing (freeze it even for 6 months, etc)
That would have a very limited impact on the release team AFAICS.
Or we could decide to implement the 'frozen' plan:
[Plan B -- rolling+frozen:]
- do Plan A.
- But instead of freezing rolling, fork it to a 'frozen' branch, and
continue the normal 'rolling' process.
This plan clearly has a severe impact on the preparation of stable
releases.
There are "compromise" solutions, too:
[Plan C -- freeze rolling before forking frozen:]
- do plan A.
- But When the release team decides to do a general freeze,
rolling is frozen for a few months to maximize user testing and
developer attention. After two to four months, 'frozen' is forked
from 'rolling', and the normal 'rolling' process resumes.
(And of course, there's:)
[Plan B -- do not change anything]
Can anyone think of other plans?
Dear Release Team members, what would you think of Plan A? Are there
conditions under which Plan C would be acceptable from your POV?
- Lucas
Reply to: