Date: Tue, 23 Nov 1999 20:52:47 -0500 From: Robert Withrow <witr@rwwa.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, stable@freebsd.org Subject: Re: speaking of 3.4... Message-ID: <199911240157.UAA45302@rwwa.com> In-Reply-To: Your message of "Tue, 23 Nov 1999 10:34:45 PST." <2190.943382085@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
jkh@zippy.cdrom.com said: := I generally get absolutely no feedback at all until 2 days before the := release goes "gold" and then a lot more feedback about a week after. := They always start the same way, too "Sorry I didn't have time to tell := you this before, but..." :-) Being one of the people who has done this (more than once) to Jordan, I can speak with some authority. ;-) What *would* improve *my* ability (and I suspect the ability of others) to get back timely QA feedback on a candidate release would be a reliable release schedule. In my case it takes a week or two to free up a machine, and free up the time, to take a day or two to wring out a release. If releases are announced to happen two weeks hence, guess what? I miss the window. Now I've been in the software business for nearly 30 years, so I know that the phrase "reliable release schedule" is nearly a contradiction in terms. Still, if we could settle down to a quarterly or thirdly (?) release schedule, with more-or-less fixed dates for code-freeze and release-cutting, I could plan that into my schedule (or even get one of my people) to test the release. If there were a schedule and no more than 4 releases a year, I could mostly do that. [Of course, recent 3.X releases have become so stable in my environment (especially due to the NFS work that has been done; God bless-em) that the testing process goes much quicker than in the 2.X days.] Another think that would help pre-release QA is some kind of special problem reporting track (perhaps a special PR coding or something) that would allow fast triage to separate problems in to blocking and non-blocking categories. This might allow the precious volunteer resources to be focused on the truly important release-stoppers in the critical pre-release period. Another suggestion: Why not engage some of the large corporate users like the Yahoos et. al. and get them to buy into the concept of being so-called "limited-access/early-access accounts" with special access to some developers on the understanding that they will commit to seriously wring out new releases? For that matter, why not see if they would fund a mini-Cygnus kind of operation for FreeBSD? And yet another sugestion: Could the product be split into different components with different release schedules. For example, I would like to get a set of ports/packages CDs every quarter. That would save me the effort of searching around for updates. (And it would be especially cool if it would come with a utility that would scan through my installed packages and notify me of the updated ones, allowing me to install them if I wish.) I would prefer to get OS updates only twice a year. Updating the OS is much more disruptive than updating packages and ports. Also, if critical bug fixes (like CERT fixes and things of this severity) could be distributed as packages/ports, this would reduce the pressure for new releases somewhat. I don't know if any of the above are truly workable in the FreeBSD development environment, but at least it is food for thought. --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911240157.UAA45302>