On Mon, Nov 29, 2004 at 08:28:16PM +0200, Jukka Marin wrote:
> On Mon, Nov 29, 2004 at 07:20:42PM +0100, Pavel Cahyna wrote:
> > Add all the ipfilter problems to that list.
> 
> There are ipfilter problems, too?  Sigh..  Won't be able to upgrade our
> firewalls, then.
> 
> > Or there was already a long delay and a perceived pressure to have 2.0 out...
> 
> I still fail to see the point in releasing broken code.  2.0 sounds like
> a major release (more so than 1.6, for example) - I think it should have
> been a stable one.

You seem to make two fundamental assumptions here.  Both seem, to me, to
be entirely silly.

The first assumption is that any code, anywhere, released or not, is
"broken" in no way.  It is a simple fact that any release we or anyone
else does will have bugs; pointing out that there are bugs in a given
release is basically like pointing out that the ground is wet when it
is raining, and says nothing about the actual utility of the released
software to any user other than yourself, nor anything about its utility
when compared to any particular other version of the software.

The second assumption is that your use case is everyone's use case; so
that software that is more "broken" or less "stable" for you is in fact
more "broken" or less "stable" for everyone else, everywhere else.

In fact, I do not believe that those assertions, for _most users_, are
true for the 2.0 release.  I administer or help administer well over a
hundred (in fact, possibly closer to 200) systems that run NetBSD; these
include general-purpose workstations, fileservers, large timesharing
systems, routers and firewalls, a compute cluster, servers for a wide
array of applications (including rsync and CVS over the entire NetBSD
source tree, with hundreds of simultaneous clients).  These systems have
literally _thousands_ of login users and many more users of
unauthenticated services.

In almost every case, it is my opinion that the 2.0 release is
significantly more stable, performs better, and offers significant
increases in functionality when compared to any release on the 1.6
branch.  I encounter some number of bugs in the 2.0 release that are
not present in the 1.6 release; but it is my opinion that these are
far, far outweighed by number of bugs and functionality limitations
in the 1.6 branch that are fixed in 2.0; and in most cases, there
are simple workarounds for the problems that I do encounter with the
2.0 code, so that I am essentially never tempted to downgrade a
system to 1.6.

Perhaps *in your particular use case* the 2.0 release does not work as
well as the 1.6 release did.  However, it is simply wrong to suggest
that, because of that, it is somehow a regression *in general* from
the release before.

Thor