Release schedule plans

[Jake]

David Miller wrote:

> 1) Should we abort the 2.20 freeze and make our March 15 freeze be for 
> 2.20 instead of 2.22?

I don't think anybody would be surprised to hear that I'm in favor of 
doing this. I think an RC for the next version being released at the 
same time as a long awaited current stable isn't really a good idea.

That does raise a question. What major features are contained in 2.20 
that aren't in 2.18? I've seen it suggested that the whining patch is 
about the only one. It's a nice feature, but IMHO the UI could use a 
little work. It's my opinion that a few more features and a little more 
time between 2.18 and 2.20 would be a good thing.

> 2) Should we attempt an "eased transition" into the 6 month cycle 
> where we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 
> would freeze March 15 as above), then 9 months for 2.22 (making it Jan 
> 1 2006), then 6 months from there on out?

Personally, I'm not even sure if 6 months is the ideal release cycle. 
But more on that in another message. If 6 months is decided upon, then I 
don't think we'd necessarily need an "eased transition." This mostly 
seems to be a way to cover up our overlapping feature freezes. Perhaps 
the best thing to do would be to simply "un-overlap" them (eg, reopen 
the trunk, do a March 15th freeze [if that's the date you want], and 
move on with life).

> 3) Our newly frequent releases (if we can stick to them) are going to 
> create a lot of branches to simultaneously maintain.  Should we have 
> branch managers for each branch?

I guess the big question I'd have is: what's the benefit of a branch 
maintainer? Is it just somebody other than Dave that can say whether or 
not a specific patch can land on that particular branch? I suppose that 
could be a useful thing, especially if we end up supporting a lot 
branches at the same time (more in another message, again).

> 4) b.m.o upgrade schedule was discussed.

I do like this idea, though I'm also in favor of Gerv's suggestion of 
doing the upgrade right after the feature freeze but before the branch. 
That would give roughly a two week time frame in which nothing could 
land on the trunk except for bug fixes before we branch for a new version.

> 5) What kind of branch lifetime and support level should we provide?

Now this is one of those interesting questions in life. The ongoing 
battle between software coders who want users to constantly be enjoying 
the newest features and the administrators who actually have to go 
through the pain of upgrades. So the real question here is, how often 
should we "force" somebody to upgrade. And how compatible is this with 
other means of distribution than downloading it via bugzilla.org. For 
example, I've seen some things recently where Debian's stable distro is 
in need of security patches, but it's something we abandoned long ago. 
Perhaps branch maintainers will help solve this problem. We tell them 
what our minimum support time is and if they want to continue to support 
it after that (because it's still being used somewhere special), that's 
entirely up to them.

> == Bugfixes provided
> -- Security only
>
>      Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
> 2.16 --|
> 2.18 ======-----------|
> 2.20 =======-----------|
> 2.22   |======-----------|
> 2.24         |======-----------|
> 2.26               |======-----------|
> 2.28                     |======-----------|
>
Obviously, part of the problem that's going to be causing us to have to 
support 6 branches at the same time is the overlapping feature freezes 
which is the who point of this discussion. If we do away with that and 
simply normalize right now, we'll only need to support 4 branches at 
once (which is still a lot).