Chris wrote:
On 05/05/06, Mark Linimon <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
