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: Why don't we publish a "Roadmap for Debian/Linux"

On Sun, 20 Oct 1996, Chris Fearnley wrote:

> 'Dominik Kubla wrote:'
> >
> >Hi folks,
> >
> >it's me again.  I just figured it would be a good idea to have some sort
> >of Roadmap for Debian with some fundamental changes to me waiting behind
> >the next corner (like kernel v2.1.x, glibc, POSIX certification ...)
> 
> I think kernel 2.1 should be ignored for /at least/ 9 months (Debian
> 1.5, maybe).  2.1 is too risky for a distribution and I need stability

I disagree. I am currently running the 2.1.5 kernel because it fixes some
minor problems with my CMD640 IDE controlers that are still present in the
2.0.22 kernel. This is not, however, the reason I disagree. The fact that
Linus intends to fold back features developed in the 2.1.x kernels into
the 2.0.x kernels will make the distinction between the two series less
clear.

> on my clients' machines.  When 2.1 development winds down, we should
> start to follow it again (and well before 2.2 is released because
> distributions can often find bugs that kernel delevelopers can't!).
> I like the idea of being the first distribution with 2.0 support.  And
> I hope we can be the last distribution with 2.0 support too!  [I.e.,
> our stable distribution should have a newer kernel than Red Hat or
> Slackware.]
> 
It's a little unclear what you mean here, but you can't be on the leading
and trailing edge at the same time.

> glibc5, libc6 also should wait until adopted and considered stable by
> the developer community before risking our novices and clients.
> 
The incorporation of these upgrades into the distribution will,
ultimately, be driven by the the rest of the packages in the distribution,
and their need for features/fixes provided by these newer packages.

This idea of "stable" as being something static and firmly grounded is
becoming very quaint. The current development environment for linux is
driven by the development of the kernel. With "new release waiting times"
of between 1 week and several hours a better model should be one of
"dynamic equalibrium" more along the lines of a surfer riding a wave, than
an individual standing on firm rock while the surf pounds around it.

My feelings about what kernels to provide lie in the broadest support
possible. Thus we should provide two kernel packages with a distribution.
One from the previous distribution that has proven itself to provide the
broadest support for the various platforms our users have and another that
represents the newest kernel that can be made to run on at least some of
the platforms that we support.

Luck,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  dwarf@polaris.net

------------ If you don't see what you want, just ask --------------

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