Date: Mon, 18 Nov 2002 18:27:55 -0800 (PST) From: Mike Hoskins <mike@adept.org> To: freebsd-stable@FreeBSD.ORG Subject: Re: restoring definition of -stable Message-ID: <20021118171406.K33213-100000@fubar.adept.org> In-Reply-To: <20021118233258.GA80653@grimoire.chen.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Nov 2002, Jonathan Chen wrote: > -stable prove to be "stable" again. There *are* volunteers: Marc Fournier, > has stepped up to the plate to stress-test -stable *and* provide > core-dumps. 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. 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.) Out of curiosity, what means of stress testing do you/Marc plan to implement? An offline response to the previous thread from an operating system company that produced a Unix-like RTOS revealed that, until a formal test suite was completed (lots of time, change in development ideology, etc.), they found that building the entire system + X + Motif covered ~80% of a normal system. From that, it was agreed that a centralized site that defined a "test build" and allowed reporting of build status on various targets would be useful. (I.e. Joe User wants to grab the latest -stable, he goes to somesite.com, searches for keywords relevant to his target or simply checks a given branch's status, and determins if what he cvsups is likely 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. > What we don't have is buy-in from -core; and the only way that will > happen is if enough people voice their concern. It's hard to work from > the inside if you're on the outside, and no one's asking you in. Do you believe that if you make valued contributions (like analyzing the cores and submitting patches), follow the steps to becomming a committer, etc. that the core team will tell you to go away? I disagree. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/article.html The issue, admittedly as I see it, is not core's willingness to help or allow others to help... But rather finding time to cater to everyone's requests. If we had a core team that was 3x the size, with 20x the userbase and 5x the systems programming experience... there would still be someone saying "Hey, why did it take so long to fix my problem?" The answer in that case would still be, "Because we can only do so much in a given amount of time." I guess I see people arguing that "core isn't helping them" - I think core's trying to help, based upon past experience, but they're buried in other tasks. (Sometimes project-related, sometimes life-related.) Since you can't demand time from volunteers, the only solution is finding more qualified help. That's something we're always trying to do... So, in a sense, the entire community is already busy working on your problem. What initially started this thread was a post indicating production use of stable, and resulting frustrations when stable breaks. No indication of a staging process was included. (Although this sort of thing is common in environments where you're moving code around.) Suggestions were made indicating how some mitigate the risk of migrating a development branch of code into a production environment, and those suggestions will indeed often reduce frustration resulting from production breakage. Asside from taking safeguards to protect yourself from breakage, unless you're writing the code to fix your problems, you can't really do much more than report your issues with send-pr. If you do fix your own problem, then you can submit the patch and a core member will assist as needed. I guess I don't see how that process is broken. I look forward to seeing your unique solution to your problem set. (Everyone has opinions based upon typical usage patterns, etc.) Please don't take my posts as a desire to NOT see FreeBSD improve... Or as resistance to change... Or as an attempt to (as previously stated) belittle the significance of your issues. I believe everyone here wants to see FreeBSD improve. However, I also think that many of the issues facing us today are resource related, and that's something that won't likely go away in the near future (no matter how many processes we put into place). Can we agree to that? I.e. Even if you and Marc start doing verbose boots and saving cores for all issues you encounter... Going from data gathering to a working, tested solution takes time. This, in turn, goes back to having a proper staging process in place... Then your production servers aren't broken while fixes are being developed. 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?20021118171406.K33213-100000>