[Mon 01:00:45] <justdave> ok, people have got me thinking a lot about this...
[Mon 01:01:15] <justdave> having 2.18 and 2.20 releasing so close to each other could be wierd...
[Mon 01:01:23] <avatraxiom> It could be.
[Mon 01:01:34] <avatraxiom> The major problem will be branch maintenance.
[Mon 01:01:54] <justdave> a few people have suggested we just abort the 2.20 freeze and make our March 15 freeze be for 2.20
[Mon 01:02:00] <avatraxiom> Maybe.
[Mon 01:02:07] <avatraxiom> If our freeze period had been nine months, when would we have been releasing 2.20?
[Mon 01:02:28] <justdave> we would be freezing this coming week
[Mon 01:02:32] <justdave> for 2.20
[Mon 01:02:38] <justdave> if we had done 9 months instead of 6
[Mon 01:04:46] <avatraxiom> Hrm.
[Mon 01:04:57] <avatraxiom> Well, I suppose it's up to you.
[Mon 01:05:23] <avatraxiom> The only problem I see with releasing a 2.20 now is that we'll have a lot of branches to maintain.
[Mon 01:05:32] <avatraxiom> What's our branch maintenance time, now that we do time-releases?
[Mon 01:05:55] <travis> branch maintenance is a good question...
[Mon 01:06:02] <travis> right now, we're putting out 2.18, and dropping 2.14
[Mon 01:06:06] <travis> support, that is. Correct?
[Mon 01:06:20] <avatraxiom> Correct. But obviously we can't drop 2.16 support as we release 2.20. :-)
[Mon 01:06:29] <travis> Right... that's the issue
[Mon 01:06:39] <novice> 2.14's been out for a year, right?
[Mon 01:06:41] <travis> why not? It *looks* like the same distance from one to the other
[Mon 01:06:49] <novice> (dropped -- out of the picture)
[Mon 01:07:07] <travis> And obviously we can't drop 2.18 support when we release 2.22 either
[Mon 01:07:25] <travis> so that means we're supporting, simultaneouslt: 2.16, 2.18, 2.20, and 2.22 ... which seems like a bit much to me.
[Mon 01:08:22] <novice> the branches become more similar under the quicker release schedules, so porting is easier
[Mon 01:08:59] <novice> 2.16 can go at any time, i think. it's almost 3 years old
[Mon 01:09:02] <avatraxiom> novice - Yes, but patch review becomes a nightmare.
[Mon 01:09:29] <justdave> We announced at the 2.18rc1 release that we'd be dropping support for 2.16 when 2.22 releases.
[Mon 01:09:37] <avatraxiom> Oh, OK.
[Mon 01:09:45] <travis> right, novice... it IS almost 3 years old... but when you put out 3 releases in four months, tht's going to catch a lot of people flat-footed
[Mon 01:09:51] <justdave> With the current release timing, I'd been planning to drop both 2.18 and 2.20 when we release 2.24
[Mon 01:09:58] <avatraxiom> Ahhh.
[Mon 01:10:04] <avatraxiom> And when will 2.24 release, with the current timing?
[Mon 01:10:14] <justdave> (which would make sense if they release so close together)
[Mon 01:10:27] <travis> a year from 2.20, in theory Max, right dave?
[Mon 01:10:34] <justdave> 2.24 would freeze on Sept 15 2005
[Mon 01:10:40] <justdave> and release whenever the blockers are gone
[Mon 01:11:00] <avatraxiom> So we'd hopefully release by the end of the year.
[Mon 01:11:05] <justdave> right.
[Mon 01:11:08] <avatraxiom> That's too short of a support period for 2.18, I think.
[Mon 01:11:14] <travis> I'd agree.
[Mon 01:11:14] <avatraxiom> Even Fedora has a longer support period than that. :-)
[Mon 01:11:19] <justdave> If 2.20 is any guide, we shouldn't go more than a month from a freeze to a release
[Mon 01:11:28] <justdave> yeah, that would have made sense if 2.18 was out sooner
[Mon 01:11:34] <justdave> we should give it at least a year
[Mon 01:11:34] <travis> I don't think 2.20 will be a good guide for releases on 2.22
[Mon 01:11:50] <travis> for timing from freeze to release, rather.
[Mon 01:11:57] <travis> or are you talking only an RC, not final release?
[Mon 01:12:24] <avatraxiom> OK. So I think that we need a "releases get minimum X time of support" policy.
[Mon 01:12:36] <avatraxiom> This is a sort of a thing that PHBs are interested in. And admins too, really.
[Mon 01:12:43] <justdave> well, I mean that I was ready to call 2.19.1 2.20rc1 but I didn't only because 2.18 wasn't ready yet
[Mon 01:12:48] <travis> From my admittedly limited perspective, it seems to me that anything that's blocking 2.20 is also affecting 2.18
[Mon 01:12:58] <travis> whereas that's not going to be true in the future.
[Mon 01:13:01] <justdave> other way around actually, travis
[Mon 01:13:08] <justdave> anything blocking 2.18 also blocks 2.20
[Mon 01:13:11] <travis> okay, right, other way around. Point still stands.
[Mon 01:13:14] <justdave> yes.
[Mon 01:13:26] <novice> why don't you revise the time-release schedule from cold-turkey to smooth-transition... release 2.18, give 2.20 12 months, give 2.22 9 months, and 2.24+ 6 months...
[Mon 01:13:46] <avatraxiom> novice - Oh, that might be a good idea. :-)
[Mon 01:13:50] <justdave> that's a thought.
[Mon 01:14:08] <travis> So we release 2.18 and 2.20 within a month of one another, then nothing for a year?
[Mon 01:14:28] <justdave> that sounds like nuking the existing trunk freeze
[Mon 01:14:35] <travis> or am I misunderstanding you
[Mon 01:14:37] <travis> ?
[Mon 01:14:39] <justdave> and freezing again for 2.20 in March
[Mon 01:14:39] <avatraxiom> justdave - Yeah, that's what I was getting.
[Mon 01:14:46] <justdave> (which would be a year from when we froze for 2.18)
[Mon 01:14:52] <avatraxiom> travis - No, we'd give 2.20 12 months for development.
[Mon 01:15:18] <avatraxiom> justdave - The only major feature of 2.20 that I know of is the Whines.
[Mon 01:15:20] <novice> right. starting from back when it opened
[Mon 01:15:24] <justdave> 12 months is too long. that's only half what we did for 2.18, and look how long that took to clean up after.
[Mon 01:15:48] <avatraxiom> justdave - Let's just give 2.18 an extended support period.
[Mon 01:16:25] <travis> justdave: I know you're leery of opening up a trunk that seems mostly stable, but from a user's perspective... two releases so close together smacks of poor planning (or execution). I am most emphatically *not* trying to point any fingers or lay any blame; I am merely speaking to the public perception.
[Mon 01:16:43] <justdave> on the other hand, a lot of our problems over the last 2 years have been absentee management...
[Mon 01:16:49] <justdave> and we have a paid project manager now
[Mon 01:17:00] <travis> really? who? >B^)
[Mon 01:21:37] <avatraxiom> justdave - Perhaps we should just say that we won't freeze the tip until we actually release a version, from now on.
[Mon 01:22:15] <avatraxiom> If we had multiple "branch managers" this wouldn't be so much of a problem.
[Mon 01:22:26] <avatraxiom> Or if we had as many contributors as the kernel. :-)
[Mon 01:22:40] <justdave> yeah. Although I suspect we probably won't have that problem again (overlapping freezes)
[Mon 01:22:46] <travis> avatraxiom: that's my thought. Release version XX, freeze for YY, branch for ZZ.
[Mon 01:23:07] <justdave> I've brought up the idea of branch managers before...
[Mon 01:23:12] <justdave> didn't get any takers.
[Mon 01:23:19] <justdave> all the movers and shakers want to stay on the tip :)
[Mon 01:23:20] <avatraxiom> Hahaaha. Yeah, it doesn't seem too fun. :-)
[Mon 01:23:26] <travis> I do think that people are losing sight of the fact that this situation is a rather unique one, which is not likely to repeat itself any time in the near future.
[Mon 01:23:27] * avatraxiom wouldn't really want to do it. :-)
[Mon 01:23:36] <avatraxiom> travis - Good point!
[Mon 01:24:07] <justdave> had I known we'd still be sitting on 2.18 in January I *wouldn't* have enforced the 2.20 freeze in September
[Mon 01:24:19] <justdave> at the time I was still thinking it would probably only be a few more weeks until 2.18 was out
[Mon 01:24:23] <avatraxiom> justdave - Yeah.
[Mon 01:24:36] <travis> justdave: wasn't 'the ability to foretell the future accurately' in your job description? :(
[Mon 01:24:44] <avatraxiom> travis - Hahahaha. :-)
[Mon 01:24:44] <justdave> hahaha I wish :)
[Mon 01:24:57] <travis> Well if not, then people should stop *acting* like it is!
[Mon 01:25:24] <avatraxiom> travis - Yeah. :-)
[Mon 01:25:24] <avatraxiom> justdave - The *only* problem we're facing is branch management.
[Mon 01:25:39] <travis> (How to get your point across, chapter three: use humour to underscore fundamental truths.)
[Mon 01:27:32] <MrNull> it's tip all the way here :)
[Mon 01:27:59] <avatraxiom> Well, we're also facing the problem that I can't remember why the chart dataset bug seemed so obvious and now mystifies me... :-)
[Mon 01:28:00] <MrNull> although might go with v2.20 branch for one of our customer bz's
[Mon 01:28:11] <travis> avatraxiom: go get drunk again.
[Mon 01:28:27] <avatraxiom> travis - Ha ha ha.
[Mon 01:28:57] <justdave> I've been thinking to keep b.m.o on a release branch after the next time we branched...
[Mon 01:29:19] <justdave> having 6 month release schedules would make that easy. We waited almost a year for new features on b.m.o last time
[Mon 01:29:46] <justdave> then b.m.o can update to tip-of-the-branch every time there's a checkin without fear of major regressions.
[Mon 01:30:19] <justdave> we move b.m.o to the next release branch as soon as we cut one
[Mon 01:30:23] <avatraxiom> justdave - OK. I think we'll need some clear policy on what goes in branches and what doesn't. :-)
[Mon 01:30:26] <justdave> that gets every rc1 on b.m.o for testing
[Mon 01:30:43] <justdave> yeah, we used to be *really* strict about the branches...
[Mon 01:30:54] <avatraxiom> justdave - Yeah. And people still used them.
[Mon 01:31:01] <justdave> once we branched, *nothing* went in, unless it fixed a regression, a security bug, or dataloss.
[Mon 01:31:16] <avatraxiom> justdave - OK. Any reason not to go back to that?
[Mon 01:31:36] <avatraxiom> I suspect the only reason we left it is because of 2.16's age.
[Mon 01:31:44] <justdave> it's nice to get bugfixes on a stable branch.
[Mon 01:31:48] <justdave> yeah, exactly
[Mon 01:32:09] <avatraxiom> justdave - Well, how about we have "support periods."
[Mon 01:32:13] <justdave> phb's won't let you upgrade until we declare it stable
[Mon 01:32:25] <avatraxiom> justdave - Like, "for X time you get bugfixes", "for Y time you get security stuff."
[Mon 01:32:32] <justdave> which still means 2.16 for most folks right now
[Mon 01:32:36] <avatraxiom> Yeah.
[Mon 01:32:41] <justdave> yeah, RHEL does that.
[Mon 01:32:54] <avatraxiom> Yeah, so does Microsoft.
[Mon 01:32:55] <justdave> 2 years for bugfixes and 5 for security for RHEL
[Mon 01:33:11] <avatraxiom> I think we could almost definitely go way less than that. :-)
[Mon 01:33:28] <avatraxiom> Maybe 6 months for bugfixes, and 1 year for security?
[Mon 01:33:32] <novice> :-D
[Mon 01:33:35] <avatraxiom> Barring only if there's not a release available?
[Mon 01:33:45] <justdave> yeah. We could do 2 years for security and 6 months for bugfixes pretty easily...
[Mon 01:33:55] <avatraxiom> OK. Let's do that, then.
[Mon 01:33:59] <justdave> that'd keep 5 branches open at once though
[Mon 01:34:03] <avatraxiom> Yeah...
[Mon 01:34:07] <justdave> except we'd be doing security-only on 2 of them
[Mon 01:34:12] <avatraxiom> Yeah. We could do 1 1/2 years for security.
[Mon 01:34:23] <avatraxiom> Frankly, we don't have too many security bugs nowadays, it seems.
[Mon 01:34:49] <justdave> 6 months on bugfixes and 18 months on security would get us 4 branches
[Mon 01:34:57] <avatraxiom> I think that would be acceptable.
[Mon 01:35:10] <justdave> yeah. we're about to have 4 right now as soon as we branch 2.20
[Mon 01:35:35] <avatraxiom> Yeah. So it will be hectic for a while, with 2.20 so close after 2.18, but it will smooth out after a year or so.
[Mon 01:35:41] <justdave> we'll have 5 as soon as 2.22 branches until 2.22 actually releases and we drop 2.16
[Mon 01:35:57] <avatraxiom> Right. 2.16 can be dropped a bit early, perhaps. :-)
[Mon 01:36:16] <novice> hee hee. he said "early"
[Mon 01:36:36] <avatraxiom> I think we'll just have to post the "what goes on the branch in what time periods" policy on bugzilla.org.
[Mon 01:36:47] <justdave> yeah.
[Mon 01:36:55] <avatraxiom> And I think that with that policy pretty clearly set, we can release 2.20 just as we planned.
[Mon 01:37:04] <novice> the fact is: you can only support what your team will support unless you strongarm them somehow
[Mon 01:37:25] <avatraxiom> novice - It doesn't take too much strongarming, in Bugzilla. :-)
[Mon 01:37:43] <avatraxiom> novice - It's mostly just Dave saying, "We still support that branch! Write a patch, yo!" :-)