quota deadlock on 6.1-RC1

Chris chrcoluk at gmail.com
Sun May 7 19:16:46 UTC 2006

On 07/05/06, Scott Long <scottl at samsco.org> wrote:
> Chris wrote:
> > On 05/05/06, Mark Linimon <linimon at 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 fully
> >> > 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 spare
> >> 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 not
> >> a positive motivator.  If they wanted to be in that position, they could
> >> just stay at their $realjobs for those extra hours.
> >>
> >> Part of their shared goals, however, is to turn out the best system that
> >> they possibly can, in the hopes that people will find it useful and want
> >> to contribute back to it.  However, there are no guarantees involved,
> >> implicit or explicit.  (If you want to compare and contrast to how much
> >> "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 features
> >> need to be included and what bugs need to be fixed.  From the standpoint
> >> of the people who attempt to coordinate this process, in technical jargon
> >> 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 features
> >> that were only available in an "experimental" branch that some people
> >> considered critical (wireless, anyone?) while that "experimental" branch
> >> 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 fixed."
> >> 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 smaller
> >> 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 about
> >> 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 are
> >> 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 until
> >> 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 they
> >> 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 for
> >> 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 that
> >> it's time for 6.1 to go out the door, because for the majority of users
> >> 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 time
> >> to thoroughly test that any proposed fix doesn't cause more problems than
> >> it cures.  Within a few days of release, that simply isn't the case right
> >> 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


More information about the freebsd-stable mailing list