Date: Thu, 04 Dec 1997 21:52:49 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: "Jonathan M. Bresler" <jmb@FreeBSD.ORG>, nate@mt.sri.com, toasty@home.dragondata.com, jak@cetlink.net, current@FreeBSD.ORG Subject: Re: 3.0 -release ? Message-ID: <24128.881301169@time.cdrom.com> In-Reply-To: Your message of "Thu, 04 Dec 1997 19:29:10 PST." <199712050329.TAA02198@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> stability >> performance >> predictibility >> > How about compelling business reason and delivery of the > product? I think we can decipher through all this that Amancio has an axe to grind about release schedules and a lack of firmness in same. That's fine. I don't think that anyone here disputes our general inability to hit a fixed release date if we're not allowed to sneak up real close to it first. We *suck* at this, in many ways, and we're going to continue to suck right up until such time as the whole release engineering process transitions from "release engineering guy" (hi!) to "release engineering group", where "group" is defined as at least 2 to 3 install hackers, a CVS buildmeister and a test engineer with one or more assistant testers. Even at minimum staffing levels, that's 5 full-time people either actively working away on a release or using the in-between hours to work on improving their tools. That's probably also about 10 machines (representing "typical configs") in a test lab, with someone doing double-duty as the lab manager who keeps track of all the bits and bobs that need to be tested. Figure on 4 average-sized office rooms to hold the lab and the project member offices, you're talking about a non-trivial amount of funding to sustain that kind of organization. Should I ever have that kind of funding available, you can also bet that's exactly what I'll do with it. :-) It's unfortunate that your average volunteer also tends to make a poor substitute for any of these "5 minimum personnel" in my scenario since doing this kind of work for free on an ongoing basis quickly starts to suck (just trust me on this :). You really need for your release engineering group to be *accountable* for their pieces of the puzzle if a release is actually going to come off on a reliable schedule and in the volunteer world, unfortunately, people are always wandering off suddenly with cryptic "sorry, family crisis, gotta go!" explanations or otherwise just becoming so suddenly swamped with other work that for several weeks solid they come home and fall asleep immediately without even reading their email. That's totally forgivable for a volunteer, of course, but if he's also your buildmeister and it just happens to be release week (and nobody else understands the build system quite like he does), well... That's sort of going to muck with your release schedules a bit, you know what I'm saying here? :-) So, in summary, if you want to make sure that Jonathan's "stability, performance & predictability" criteria are not seriously compromised by the schedule, and you really want to stick to an *exact* schedule, then somebody's going to have to find me at least $500K/year hidden under a rug someplace so that I can hire those folks and stick them in the kind of environment where they can communicate directly with one another and focus exclusively on the problem, 40 hours a week minimum, and actually do the job the way it's *supposed* to be done. :) If you want to preserve Johnathan's criteria without spending at least $500K/yr, on the other hand, then you've got to settle for a floating schedule. Sorry! Law of physics. Not my fault. ;-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24128.881301169>