Date: Tue, 19 Nov 2002 10:19:14 -0400 (AST) From: "Marc G. Fournier" <scrappy@hub.org> To: Mike Hoskins <mike@adept.org> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: restoring definition of -stable Message-ID: <20021119100057.W19853-100000@hub.org> In-Reply-To: <20021118171406.K33213-100000@fubar.adept.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Nov 2002, Mike Hoskins wrote: > That's good, but it takes time to analyze the dumps, right? That's my > key point: You're not being ignored, people are just busy. Actually, this might be something that could be reduced ... one of the things that I *try* to do is add more detail to my own analysis/reports as I learn of new things ... one of the focii of any QA team should be to pool together as much information on how to analyze a core as possible, so that we're able to provide more detailed reports ... the Kernel Debugging section of the handbook mentions a couple of things, but how many reports are handed in that are incomplete, where a developer has to ask for more information? If we could come up with a more complete example over time, it should hopefully reduce the time a developer has to spend digging for it ... Its not guaranteed to always be useful, but if I can provide as much information as possible in the first report, it would save alot of time for everyone ... > Interestingly enough, I had started a past "stress test" thread. I.e. > An attempt to piece together a distributed test matrix through a > centralized reporting db. A number of good suggestions were made here > and offline... But things always boil down to time. (Shortly after > starting the thread my company's size was almost 1/2ed leaving me with > ~2x the work.) Okay, you seem to have the ideas for the 'centralized reporting db' ... I can offer up the server/db resources to host it on ... does someone (or a few ppl) have time to do the physical work? > Out of curiosity, what means of stress testing do you/Marc plan to > implement? As I mentioed several times .. I have two servers *in production* hosting an average of 100 jails each, each of which hosting several domains, that are not even close to idle: jupiter# ruptime jupiter up 2+06:53, 2 users, load 4.57, 17.53, 28.35 mars up 2+17:49, 0 users, load 4.28, 4.39, 3.53 venus up 2+15:23, 0 users, load 1.41, 6.27, 11.62 My personal intention is to upgrade venus to -STABLE on Friday night after I get a firmware upgrade done to its RAID controller ... best uptime I've had so far before a crash is 20 days on jupiter, so I'm going to be working at a 30day uptime before upgrade ... same with jupiter, but the following week, and same with mars the week after that ... So I'll end up running copies of STABLE a week apart to start with ... when/if a server crashes, using the core file, I'll send in as complete a report as I know how (which will hopefully improve over time and knowledge) and upgrade to the latest STABLE for that server, and start my 30 day cycle over again ... at 30ish days, even if 'stable', I'll be upgrading yet again ... personally, based on my experiences with the servers at the University, if I can keep venus/jupiter running for 30 days straight, lower load servers shouldn't have a problem with it ... which would mean that the source code of the date that I started the 30 days appears to be 'the latest stable checkpoint' ... if it crashes before the 30 days, then the day I CVSup for that run had some sort of bug in it, and therefore should be avoided ... With CVSup's date= value, we should be able to generate a reasonably constant running timeline of "stable checkpoints" ... it won't be perfect, but it would be a start ... > to build on his target at that time.) The usefulness of such a tool would > obviouslly grow as more robust test suites were developed, more people > contributed to the results database, etc. All of this takes time as well. So, we need someone (or a couple of ppl) that have some spare personal cycles to act as a "webmaster" for the site ... as mentioned, I can dedicate the physical resources for this .... 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?20021119100057.W19853-100000>