Date: Sun, 7 May 2006 20:16:42 +0100 From: Chris <chrcoluk@gmail.com> To: "Scott Long" <scottl@samsco.org> Cc: stable@freebsd.org, pjd@freebsd.org, linimon@freebsd.org, Mike Jakubik <mikej@rogers.com>, kris@freebsd.org, rwatson@freebsd.org, Mark Linimon <linimon@lonesome.com> Subject: Re: quota deadlock on 6.1-RC1 Message-ID: <3aaaa3a0605071216m5fa3b38fu7c1afde22dd5e2e0@mail.gmail.com> In-Reply-To: <445D55D9.5070701@samsco.org> References: <445B991F.3050600@rogers.com> <20060505192152.GA17616@soaustin.net> <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com> <445D55D9.5070701@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/05/06, Scott Long <scottl@samsco.org> wrote: > Chris wrote: > > > On 05/05/06, Mark Linimon <linimon@lonesome.com> wrote: > > > >> Make Jakubik wrote: > >> > >> > FreeBSD users now demand stability and performance, as opposed to an > >> > influx of new bells and whistles just before the release [...] I ful= ly > >> > understand that this is a volunteer project [...] > >> > >> I'm sorry, but the former statement proves the latter false. > >> > >> Let's try to do our Semi-Annual Refresher Course On Open Source > >> Development: > >> > >> The developers (at least 99% of them) work for free. In their own spa= re > >> time. Their motivations vary but I don't believe any of those include > >> being in a position to feel they need to respond to demands. That's n= ot > >> a positive motivator. If they wanted to be in that position, they cou= ld > >> just stay at their $realjobs for those extra hours. > >> > >> Part of their shared goals, however, is to turn out the best system th= at > >> they possibly can, in the hopes that people will find it useful and wa= nt > >> to contribute back to it. However, there are no guarantees involved, > >> implicit or explicit. (If you want to compare and contrast to how muc= h > >> "guarantee" you get from closed-source development, please pull out a > >> copy > >> of your EULA. They barely even "guarantee" that there are bits on the > >> CD.) > >> > >> There's a long process where the developers try to agree on what featu= res > >> need to be included and what bugs need to be fixed. From the standpoi= nt > >> of the people who attempt to coordinate this process, in technical jar= gon > >> the process is know as "herding cats". I would be able to serve as an > >> expert witness in court about this. (Side note: some of the cats hiss= , > >> bite, and scratch; very few, if any, have _any_ interest in being > >> herder.) > >> > >> There are always tradeoffs between stability and features. During the > >> 5.X cycle we managed in some degree to de-optimize both: we had featur= es > >> that were only available in an "experimental" branch that some people > >> considered critical (wireless, anyone?) while that "experimental" bran= ch > >> was unsuitable for production use. The idea was that we would hold on > >> to declaring 5.X "STABLE" until all the major bugs were fixed. > >> > >> And as a consequence, we didn't release for -- what, 2 years? > >> > >> So we've thrown out the idea of "wait until every possible bug is fixe= d." > >> It leads to rare releases, and larger code chaos, larger instability, = and > >> allows FreeBSD's detractors to sniff "well, they're never going to > >> release > >> anything again." (Notice how the "BSD is dying" crowd on Slashdot has > >> been a lot quieter since we released 6.0?) > >> > >> So now what we're doing is trying to come up with more regular (not on > >> absolute deadline) releases, with smaller feature sets, to enable smal= ler > >> sets of new code to be debugged simultaneously. > >> > >> The features that some users see as critical, others don't. (I don't > >> have > >> quotas enabled; I have disabled soft-updates on the theory that as a > >> single > >> user I can trade longer startup time for possibly greater error > >> recovery). > >> > >> > I wish i was a good Unix C programmer myself, so i could contribute > >> in a > >> > more direct way > >> > >> And there's the rub. The people who _are_ good Unix/C programmers are > >> the > >> ones doing the work, and as such, feel that they have the final say ab= out > >> what goes and what doesn't. While I hope that each of them will > >> listen to > >> what individual users are saying, and take good suggestions to heart, = the > >> fact remains that they are under no _obligation_ to do so. > >> > >> Finally, as has been pointed out already, the interactions between > >> quotas, soft-updates, and the rest of the system have problems that ar= e > >> probably going to be fairly difficult to isolate and test. Thus, they > >> could take days, weeks, or months. If we were to hold the release unt= il > >> these were fixed, basically our last 2 months of QA would be out the > >> window. This is not a way to keep developers happy; at some point the= y > >> will tire of the inability to work on the things that they find > >> interesting, > >> and wander off to find something else more fun to do. > >> > >> Summary: it's too bad that there are regressions, but sometime they're > >> a fact of life. If these regressions are in areas that are critical f= or > >> a certain user, that user should just skip 6.1 and wait for 6.2. The > >> stability gains that 6.1 have over 6.0 in so many other areas means th= at > >> it's time for 6.1 to go out the door, because for the majority of user= s > >> it's going to be a big win. > >> > >> As always, we welcome test cases on e.g. non-critical systems, earlier > >> in the release process (or between releases), where there's enough tim= e > >> to thoroughly test that any proposed fix doesn't cause more problems t= han > >> it cures. Within a few days of release, that simply isn't the case ri= ght > >> now. > >> > >> mcl > >> _______________________________________________ > > > > > > nice post and ultimately you are correct, I personally would prefere a > > higher gap between releases for the following reasons tho. > > > > 1 - it does increase stability if the extra time is spent fixing bugs > > and testing the fixes. > > > > No, actually it doesn't. The real push to get bugs fixed doesn't happen > until about 2 weeks into the start of the release cycle. It doesn't > matter if it's been 2 months or 2 years since the last release; letting > it sit longer absolutely does NOT result in fewer bugs. in fact, it > results in MORE bugs, because more happens in the longer gap that needs > to be fixed. > > > 2 - its easier for administration, upgrading freebsd every 2 to 3 > > months isnt ideal for administrators. I know releases are supported > > for much longer but given what kris told me recently that ports are > > only supported on the very latest release I found that a bit worrying. > > There is nothing forcing users to upgrade at every release. For my > company's product, I just updated us to 6.1, and I don't expect to do > a full update again until 6.3 or 6.4, other than some small targetted > micro-updates as needed. For my production mail and firewall servers, > they are running RELENG_6_0, and I probably won't upgrade them until > 6.2 or 6.3. > > > > > 3 - it raises profile for the release, the euphoria surrounding a > > release is much less if there is one every other month. > > It was never, ever suggested that there be one release per month. It > was planned that there be a release every 18 weeks. There are snapshot > builds every month, and that is done to make sure that the releases > scripts continue to work, and give the adventurous users something to > play with. > > > > > In terms of a new major version ie. 7.x over 6.x I think that should > > only be released when their is something major changed like 5.x over > > 4.x had a new filesystem smp support etc. and I happen to think > > because 5.1 and 5.2 werent STABLE the 5.3 STABLE release turned out > > very stable at least in my experience and was more stable then 6.0. > > 5.1 and 5.2 were not given the 'STABLE' nomenclature. As for 5.3 being > "more stable than 6.0", that is a very subjective statement. I can > give you a list of at least 500 things that were fixed in between 5.3 > and 6.0. Unfortunately, a few things regressed, as often happens. > > > What > > was major difference between 6.0 and 5.4? if I understand it > > correctly their has been a lot of work done fixing problems that > > existed in 5.x but no new feature to shout about. ULE which was > > unfinished in 5.x still remains unfinished in 6.x and I wonder if will > > be a unfinished feature in 7.x. > > You obviously never read the release notes, sorry. MPSAFE VFS was a BIG > feature for 6.0. Given that your discussion seems to be headed away > from researched facts, I'll just stop here. I won't even recognize your > statement about adding Java to the base system. > > Scott > > Wow I generated some responses. my comments I think were too strong and harsh but I will respond. GNATS didnt reply so I will send the info about email address I used and see if I can find the pr number as well. One issue was a dicussion on here which already had a PR so I didnt post a seperate PR for it that was the bge issue. I dont have servers with massive uptimes at the cost of security, if something has a patch that will pose a risk to me I will schedule the necessary maintenance on that server I dont immediatly apply it tho since I cant be rebooting servers every week. I was reffering more to making sure everything carries on running on the server after the upgrade. But you are right in that I dont upgrade every version anyway, I will have to on my 5.4 server's to 5.5 since 5.4 is EOL end of may. I will put all my 6.0 to 6.1 for stability reasons and hopefully after then I can wait till 6.3 like you said. The java I picked up from a newsletter about the licensing changes, obviously I misread it if my information is incorrect I apologise for that. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3aaaa3a0605071216m5fa3b38fu7c1afde22dd5e2e0>