The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Continuous Releases?



On Thu, 30 Jan 1997, Daniel Quinlan wrote:

> > All packages are, IMO, unstable until i've successfully installed
> > them on my system.
>
> I'm not sure how this metric would successfully apply to Debian
> project development.

my system, your system, anybody else's system. my point was that putting
a package into a section called stable doesn't increase my trust in it
at all. nor should it.

According to what I've read on debian-user and other places, by ignoring
the stable tree on my own systems and upgrading continuously I have
avoided nearly all of the packaging problems which other users have
had. I have also been able to use my experience of what worked and what
failed to help some of these people when i saw a post on deb-user which
i could answer.

I've upgraded many debian systems many times. In my experience many more
problems will be encountered during an upgrade the longer the upgrade is
delayed. End result is that i have much more stable systems with less
downtime (i.e. negligible).

As well as getting less problems total, i get less of them at any one
time. Instead of upgrading once every 3 to 6 months and getting 100
packaging problems at once, I get only one or two packaging problems per
upgrade. The former would be a disaster which could take several days
to fix. The latter is only a minor hassle which can almost always be
resolved immediately by:

 1) using dpkg to downgrade to previous version,
 2) using dpkg to install libraries etc which the package needs before
    running dselect again,
or sometimes
 3) editing /var/lib/dpkg/status with vi to fix obvious dependancy
    problems (e.g. ssh 1.2.17-2 depended on xlib rather than xlib6)

An hour once/week is a lot better than (potentially) several days every
3 months.

Another big advantage to it is that it familiarises me with dpkg and
dselect - i use it as often as I use some other system admin tools. I
have a reasonable understanding of how it works, its strengths, and its
weaknesses. This is vital. I depend upon dselect, so I can't afford not
to understand it.

> > (also IMO, "Stability" as far as debian is concerned is primarily
> > about whether a package installs OK without breaking
> > dpkg/dselect. Whether the package performs as advertised is another
> > matter entirely.)
> 
> Stability should be a reflection of the status of the package. That
> includes installing correctly, but should also mean that the contents
> of the package are quality-tested. The testing should catch things
> such as maintainer-created security holes.

Yes, I agree. However, that is the individual package maintainer's
concern (with help and advice and support from other debian developers
and users). As a distribution, debian's primary concern is whether the
whole collection of packages integrates well with each other.

Mostly, that will involve setting standards and fixing dependancy and
other packaging problems.

Debian's secondary concern is to provide the forum for debian users &
debian developers to help each other - web site, ftp site, mailing list,
bug tracking system, etc.

debian ISN'T libc5.deb, and it isn't dpkg.deb, and it isn't gcc.deb,
debian is the sum total of all of the packages.


> We really must end the practice of sending a package straight (not
> counting automated checks) from the package maintainer to the user.
> Even the best package maintainers make mistakes from time to time.
> Packages should be tested by humans before they go to the public.

That's what unstable is for, isn't it?


> >> We have shown that this does not work. Let's try something more
> >> conservative.
>
> > actually, it's been *asserted* that this does not work. we've never
> > actuallytried it...
>
> I don't understand. Debian has never had any serious testing of
> packages. Maybe we are using different meanings for "stable" and
> "unstable".

Every time somebody suggests promoting debian as being a continuously
updated system, the idea is squashed by saying 'it will never work'.
therefore it has never really been tested.

Now i suppose many/most people see the "real debian" as being the stable
tree which can be found on ftp sites and cd roms....with unstable being a
buggy alpha/beta test of the next real debian.

I see it the other way around.

I see unstable as being the "real debian", with stable being a concession
to cd-rom manufacturers and those who dont have good net access.

As far as I can tell from comparing other people's experiences to mine,
my paradigm works better.

I'm NOT saying we shouldn't have a stable/cd-rom distribution.  That's
absolutely necessary.

What i'm saying is that we would be better off thinking of debian as a
live distribution rather than a static one.

Anyway, we already have a moving target distribution - 'stable' keeps on
getting updated all the time..."Debian-1.2.5" at the moment.

Craig


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com