quota deadlock on 6.1-RC1

[Mark Linimon]

On Sat, May 06, 2006 at 09:26:51PM +0100, Chris wrote:
> 1 - it does increase stability if the extra time is spent fixing bugs
> and testing the fixes.

This assumes that you can persuade committers to focus on bugfixes instead
of on other things that they consider more fun.

> 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. 

This is the opposite from what most people experience, at least from my
experience with the mailing lists and GNATS.  5.3 was somewhat rough, due
in part to a large number of things merged into it during the QA cycle.
5.4 was a substantial increase in stability vs. 5.3 without having that
many new features.  6.0 had a fair number of advances in the code but by
the time it was released, most of the developers had turned their attention
away from 5.X and to 6.X.  Thus, many people found that not only did 6.0
have more features, it also had had more testing, and a large degree of
stability.  There were certain cases where things did not work as well as
we would have liked; however, for quite a number of people, 6.0 worked
better than even 5.4.

6.1 incorporates a large number of fixes more oriented to stability than
features.  5.5 incorporates a subset of those, because of the infeasbility
of back-merging many of those changes (they would risk more instability).

> 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.

Much of the work was done on internals, which will fix race conditions,
increase performance, and add stability in the long run.

In particular, the wireless support in 6.0 is (AFAICT) much more advanced
than 5.4.

> 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.

This is completely tangential to the other issues.  ULE to some degree is
still a research project.  If you are not willing to live on the bleeding
edge of testing, you probably do not need to be running ULE.

> 4 - new features in minor version, why are we discussing an issue where
> there isn't enough time to fix some bugs

a) there is never enough time to fix all the bugs.
b) fixing bugs relies entirely on developer interest.  The 5.X experience
proved that longer release cycles do not necessarily raise developer interest.

> 5 - bug reports not acknowledged.  I have submitted a PRs myself and none
> have even been acknowledged

If they have not been acknowledged by GNATS, you need to email
bugmaster at FreeBSD.org and point these out so that we can identify the
problem.  (If your email has no reverse resolution, your email will not
make it to GNATS).

If they have been acknowledged by GNATS, then you should understand there
there are currently 5,424 PRs in the system (984 are ports PRs; many
others are kern/ or bin/).  We have far more PRs arrive than we have
developers who are willing to spend time working on them.  (The arrival
rate is somwehere around 40-50/day, 3/4ths of which are ports PRs and can
be cleared somewhat more quickly.)  If you have any concrete suggestions
on how we can get more current developers interested in working on PRs,
or some new developers that are primarily interested in working on PRs,
please make them.  I have been trying to come up with suggestions for a
while and haven't come up with much of anything.

> Ultimately RELEASE is supposedly the stablest branch.  Yet due to a
> rush to push out a release to keep people like slashdot happy people
> running freebsd servers around the world will suffer problems because
> of these bugs and may possibly move to linux as a result.  When are we
> going to go back to a FreeBSD that just works.

Keeping the slashdot crowd happy is merely a side-effect of making
releases that fit most user's needs, and in a timely fashion.  We have
definitely erred in not making them in a timely fashion in the 5.X
series; arguably, the push to wait until 'all promised features were
complete' failed to meet most users' needs as well.

The FreeBSD that "just worked" was release 9 or 10 out of a series that
was a far simpler codebase than the current one which runs on systems
with ACPI, multiple processors, multiple architectures, and a much larger
number of motherboards and peripherals.  We are currently ready for release
1 out of the 6 series.  If you compare 6.1 to 4.1 you'll find that there
is absolutely no comparison at all.

> After my rant I will say 6.1 so far has proven to me a lot more stable
> then 6.0

Well, this is where the "rubber meets the road" as the expression goes.
This seems to be the common experience.  (There are certain users who
seem to have problems with 6.0/6.1; these seem to be in the minority, and
possibly depend only on certain workloads.)  And, in addition, most users
seem to feel that 6.X is both more feature-complete, and more stable,
than 5.X.

We continue to do the best that we can; IMHO we make amazing progress
with a small number of developers, on a large number of architectures,
on several code branches simultaneously, on a bewildering variety of
motherboards and peripherals.

But we're not going to satisfy everyone.

mcl