Re: join us!

[Seth Cohn <scohn@clipper.net>]

On Sat, 16 Sep 2000, David Benfell wrote:

> In an ideal world we would have the time to turn over every stone
> before we ever said a thing.  I don't think any of us can claim
> innocence here.

If someone found a seemingly 'old' version in Red Hat 6.2, writing to
support@redhat.com might or might not yield a result.  You aren't sure who
at Redhat is responsible for that given piece of software.  In Debian,
that is _never_ true.  If I find a bug in the X server, I know that I can
either file a bugreport or write directly to Branden, who maintains it,
and often a response is immediate.  Debian is the only distribution that
can say this:  you know the exact person who claims responsiblity for any
given item.

> > No, they are NOT forking.  Consider: the only way to get the Debian version 
> > is from a Debian site.  Debian packages are set up as orig.tar.gz and a 
> > Debian Patch. This prevent the exact problem you are talking about.

> This is a good start.  Really it is.  I still think you're duplicating
> effort, but it is a very good thing that you're making very clear what
> you've changed by shipping along diffs.

It's not about duplicating effort at all.  Clearly, you haven't been
exposed to the 'Debian' way at all.  Debian is very picky about doing
things the 'right' way.  Since we can't insist that all authors make
their software do things the 'right' way, since we have the code, we patch
it and release the diff, which brings the code to Debian specs.  For
instance, the policy manual clearly says what can and can't go where.
Nothing in /usr/local, for instance.  If an author wrote the software to
install in /usr/local, we _must_ patch the software to put it into the
'right' place.  You might argue about the duplication of effort, but I
always know where the documentation, the binary, the libraries, etc, all
are in any Debian packed piece of software.  And there are lots of other
less clear examples that can be made.

> Part of my job, however, is making Linux more accessible to newcomers.

Mine too.  I am president of the local Linux User Group, and I install
usually 2 or more systems a week.

> To me, it's not that far-fetched to suppose that somewhere down the
> road someone will look around, see Debian, see the old version
> numbers, see the issues associated with those versions, and ask the
> same question.

True.  And Debian hasn't been blind: the major criticism is still 'this
stuff is old' because everyone else rushes stuff out the door except
Debian.  Package pools will fix that, and it's already in the planning...
I'm going to guess that Debian 3.0 will implement pools in some fashion,
and that will make more up-to-date software releases.

> So I'd definitely encourage you to tell people up front that you
> backport selected improvements, seeking to produce the most stable
> packages possible.

This should be said clearer, I think the whole thing with Kurt proves
that.

> The obvious question I'm failing to answer is where and how you should
> tell people.  Perhaps you should insert this in a statement of your
> development philosophy.  Debian is, in part, a distribution for, and I
> don't mean this negatively, idealists.
> 
> So, as idealists, in the positive sense of the word, you can make a
> statement that you support free software; this is why you separate
> free from non-free.  And you can state your method of development in
> your quest for stability.  If it's well written and succinct, I can
> hope that people will actually read it.

Hehehe.  Gee, you really don't know Debian at all, do you?  Before you
write long critics, you should do your homework.  All of this exists.
Go to the website and take a look.  It's well written and succinct, but
you haven't read it yourself.

> > No, this allows Debian to ship 'known stable' but still 'security-hole' 
> > with a minimum of problems.  Given the choice between a patched hole of 
> > version 1.2stable and 'secured' 2.0beta, the choice is clear.
> 
> beta yes.  But if I recall the examples correctly, you were three or
> four versions out of date.  Other distributions ship out of date
> versions too, but my impression is that most of them aren't quite as
> far out of date.  My reading of this is that you're hanging on to old
> code too long, spending too much time fixing bugs that have already
> been fixed, and that this is, perhaps, part of the reason you are
> taking so long to release a distribution.

Not at all.  The problem is the nature of the freeze versus the
_extremely_ fast release cycle of some software.  Debian planned the
potato freeze, and it took 6-8 months (and many will agree, it was too
long but it took what it took) and in that 6-8 months, some software
_will_ release 3 or 4 versions.  Release early, release often.  However,
Debian policy is:  once frozen, no new versions, except for _serious_
problems, and backports if possible.  Some people disagree with this, but
the consensus is that this is often because of the reason I state above.

> My perception (please do correct me if I'm wrong) is that you have
> more developers than any other distribution.

Maybe.  More committed developers, for sure.  Everyone who packages
something has an itch to scratch, and since the pay is zero but pride, the
quality in packages is immense. 

>  I also perceive that
> you're shipping at least three times as many packages as anybody else.
> I don't think these are trivial advantages; you've got a lot going for
> you here, where no one else comes close.

I agree, which is why I'm on the verge of becoming a developer for Debian.
I want to part of this amazing effort.

> But my perception of Slink was that it was so old, it was broken.  I
> remember all too well, a bunch of people in my office, installing
> Debian, running to me because I had a floppy disk with a working
> dhcpcd.  I think you desperately need to shorten the time between
> releases and I think you have the resources to do it.

No, Debian doesn't.  It's a volunteer effort, and there are _always_ never
enough people to do all the jobs.  Slink wasn't broken, it just aged
badly compared to other distributions because they upgraded.  Compare
Slink a Redhat 5.2 or a Caldera 1.3 and you see how well done Slink
was.  Comparing Slink to Mandrake 7.0 isn't at all evenly matched.

I agree (and others do) that the release time issue is
important.  Personally, I think package pools are one important step.

> > As for non-reproducible anywhere but Debian, this is why Debian has a 
> > bug-tracking system.  And a maintainer who will track and fix those 
> > problems, since they are the patcher in most cases.
> >
> Ah, the duplication of effort I already spoke of...

Not at all.  Let's take X as a wonderful example:  Branden tweaks X so
that things work.  He held off on Xfree 4.0 for a long time, because in
his experienced position, he saw how much work it still needed.  He didn't
package it at all until 4.01 and he's still working on the package...

A maintainer who didn't care would have slapped it together, thrown it out
the door, and said 'it's a bug upstream, let them fix it'.  Debian
maintainers _care_ about the package.  They often use the software
themselves, often have a good relationship with the upstream (submitting
patches etc), and probably are one of the foremost experts on the software
in question (they must get down and dirty with it to package it, and
follow it closely to upgrade it).  I know that if I contact a maintainer,
it's not just 'another' piece of code to them, it's something they care
about.  Often, when a developer gets tired of the package, they will
orphan it, and usually someone else will step up to bat, taking the same
care and control.

This is as far from duplication as you can get.  This is about
participation in the development cycle.

> > Someone took responsiblity to patch things.  It's not just 'hey, here's a 
> > patch'.
> > It's "The maintainer felt that this patch was critical to the software, 
> > even tothe point of a backport."
> >
> This is a statement that sounds good.  But it overlooks the
> difficulty involved when patches cannot be applied cleanly, or worse,
> when you find out the hard way that some patches couldn't be applied
> cleanly.  I think you're duplicating a tremendous amount of effort.

Not for the developer who has to do it.  Often they are one of the people
who _does_ know the software well enough to do this.

The patches they release will apply cleanly, because they will take the
time and effort.  Red Hat, Mandrake and everyone else take the easy
road: They just package the new version most of the time and recommend
everyone upgrade.  They don't take responsiblity, they shift it
upstream.  "Oops, that might break your system, but it's not our fault,
they released a new version".  Debian avoids this consistently.

> Sometimes bugs go away, seemingly, on their own.  It can happen when
> somebody looks at some ugly code and decides to clean it up.  He
> decides what this ugly mess is supposed to do and writes clean code to
> do it.  As long as he understands correctly what the mess is supposed
> to do, there is a very good chance that the clean code will be more
> efficient and more robust.
> 
> In these cases, older versions are not more stable; they contain more
> ugly hacks.

But for any given package, the best judge of this is the maintainer of it.
And we have that.  If he/she thinks it's ugly, often they are the ones to
help fix it.  If you took a poll, you'd probably find that most
maintainers have submitted patches back upstream.

> > Yes, it's called the Debian bugreport and Debian's history of security.
> >
> Securityportal.com published a comparison of distributions at
> http://www.securityportal.com/cover/coverstory20000724.html  I see
> this is also by Kurt Seifried.  He didn't really include Debian in the
> comparison; even if he had, you would presumably accuse him of bias.
> I'm left searching for an impartial comparison.

Debian's bug reporting is impartial.  It's 100% open and mostly archived.
Anyone can submit a bug report, and you can always see the history, the
age, etc.   Debian's release of security fixes is usually at the bleeding
edge.  Often Debian's release is days ahead of the other distributions,
and keep in mind, our people don't get paid to do this.

> > Yes.  and it's size, and it's known issues (or lack thereof)
> > 
> We'll have to agree to disagree here, unless you have a poll of 2.0
> users to back this up.  I don't know anyone who chooses to install a
> 2.0 kernel, unless they were installing Slink; then they were
> installing Slink-and-a-Half as soon as it could be found.  The
> footprint would certainly be a legitimate issue, if we find a lot of
> people choosing 2.0 for that reason.

2.0 is used for things like embedded software, Tom's root boot, and other
'tiny' things.  As the kernel gets bigger and bigger, there will continue
to be people who find uses for the older stuff.

> There are no physicists in the hottest parts of hell, because the
> existence of a "hottest part" implies a temperature difference, and
> any marginally competent physicist would immediately use this to
> run a heat engine and make some other part of hell comfortably cool.
> This is obviously impossible.
>                                 -- Richard Davisson

There are no Debian developers in any part of Hell, because the good karma
incurred by being one takes you straight to the pearly gates.  Of course,
the frequent flame wars you put up with on the Debian lists make up for
this on Earth.
					- Seth Cohn

Seth