Date: Mon, 20 Dec 1999 21:26:47 -0500 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: freebsd-qa@freebsd.org Subject: Re: After 3.4 finally goes out the door Message-ID: <199912210226.VAA14961@spoon.beta.com> In-Reply-To: Your message of "Mon, 20 Dec 1999 17:59:51 PST." <19991220175951.A59081@mushhaven.net>
next in thread | previous in thread | raw e-mail | index | archive | help
A quick thanks to everyone who helped out on testing 3.4. The sentiments below seem to be fairly consistent with everyone's take on the process (myself included), so I'll take a minute and talk to them... > I agree with this totally. I also feel someone should step forward > and coordinate; Well, thats me :) Help me or yell at me as you like. I can take it ;) Overall, we tried. Unfortunately, we got started about 48 hours before the 3.4 release process started. During this 48 hours, we had to get volunteers, figure out a rough test schedule for the 16 days we had, and get as many people "ready" to hit it as possible. We didn't do too badly. I think we got some good exposure of the release. Contrary to belief, we did find and fix some things that would have made for a good, lengthy ERRATA file. > I didn't do more than install and see if it worked > as I am not familier with how things should be tested. You have to start somewhere. I think we got good coverage for a number of the critical pieces. In the real world, you'd have test tools to play with APIs for things (disks, mmap(), threads, etc.), which we didn't have this spin, but a lot of testing is still "taking it for a drive", which we all did in one way or another. > Also, I feel > that some things should be made available such as CVSUP scripts > and such to make sure the people involved really are testing the > right things. Could we maybe get a 'branch' named 'qa' that would show > rc or qa in the uname output? We asked for the tag. Its "too expensive" for the CVS repository. Normally, at the beginning of the project (for those late comers), the target stable snapshots are documented ahead of time... usually one every four days. Towards the end of this cycle (which I expect will happen in all cycles), it broke down in to daily or every-other-day snapshots so that we could be on top of the latest code, and really ride the day to day fixes. > That would also make things easier as we > could then test that tree for the cd, and bug fixes that are essential > could then be made to that tree only, and normal developement could > continue on the -STABLE/-RELEASE tree. The powers that be also don't like this (it, too, was brought up). It ends up being another merge issue (after all, you'll want fixes in your -RC branch to go back in to -stable sooner or later). I do agree that some of the last-minute changes caused some problems (*cough sysinstall *cough). I particularly don't like the fact that they slipped it in so late in the game. _But_, we are testers, not developers. Its not our place to make policy, only to point out the errors created by that policy ;) As to 4.0, here was the last conversation I had with Jordan on the topic... >> Hi, Jordan. I was just scanning -current, and have noticed alot about the >> "impending" 4.0-RELEASE. The only semi-solid number I've heard is 5 weeks, >> which will put it around 1/18/2000. > >It's somewhere in-between 1/15/2000 and 2/15/2000, the former being >the published date. > >- Jordan This means we all get a "Happy Holidays" break, and then we'll be looking at 4.0. Starting around 12/31, 1/1 (Hope its Y2K compliant! ;) ).... (Hint: If you want to start working on it now, the 12/27, 12/23, 12/31, 1/4, 1/8, and 1/12 dates will be the -CURRENT snapshots you want initially). This probably also means that we won't be test/feature rich for this release either. If there are a couple of good coders on the list who like writing tools to test things, then we'll abstain your need to test if you can provide said tools/scripts. After 4.0, I plan on starting some work in this area, but, as always with everyone, my time is somewhat limited. Anyhow, keep your spirits up. We're just starting, and it'll take some time to get a good working pattern down. The _best_ thing each of us can do is play with the upcoming releases and features, keep talking to each other about testing, and help out with tools as best as one can. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-qa" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912210226.VAA14961>