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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501180251.ga25...@xanadu.blop.info
