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]

Clarification about the idea to "split the distribution"



Hi folks!

A lot of people have sent me private mails and asked me to describe the
idea to "split our distribution" in more detail. Since I think this is of
public intrest, I'll do this here. (I hope you don't mind for the long
mail.) 

I would prefer if we can postpone the discussion a few weeks. I think we
should focus on getting Debian 2.0 out soon. (Perhaps the `code freeze'
period would be a good time to discuss this.) Furthermore, we might
consider discussing this on debian-devel--but we'll have to be very
carefully to not start yet another flame war.

First of all, let me note that there is no reason for anyone to "worry" 
about this idea. I know that everyone has strong feelings regarding
"censoring", "open development", "splitting the archive", etc. Nothing has
been decided, yet. These are all just my "humble" ideas and if you all
like we should discuss them. That's all. Please consider this as a
_proposal_.


Our current situation: In Debian 1.2 (aka "rex") we had about 950 packages
in our archive (main+non-free+contrib) and now we have about 1600
packages. (I hope this numbers are at least somehow exact. I just did a
few greps|wc :-) I bet that we'll get some more until Debian 2.0 will be
released. (Some could argue that the move to libc6 introduced several
additional "altdev" packages--I haven't checked this but I don't think we
have 650 altdev packages.)

While the large number of packages makes Debian the largest distribution
it also introduces a few disadvantages:

- A lot of users are overwhelmed by the large number of packages when they
are installing Debian for the first time. (The new "deity" might improve
this situation--we'll see.) Furthermore, digging through 1600 packages
takes some time and "having time" is our biggest problem, as we all know.

- It's hard to write documentation for the Debian system as a whole since
you have too many special packages. E.g., if you write a section about how
"vi" works, you'd have to explain elvis, vim, nvi, etc. Same applies to
mailer daemons, web servers, etc.

- Projects like the "keyboard configuration project" are really hard to do
because they affect a large number of packages. Such efforts will get even
worse if the package count continuous to increase.

- The more packages we have, the more time we'll need to implement major
changes. For example, we'll have to switch from FSSTND to FHS for Debian
2.1 and there might be a libc6->libc7 migration some time. (A lot of
people think that we should release "hamm" ASAP since Red Hat 5.0 has
already been released a few weeks ago. Since we have more packages than
what they have, it's obvious that we need more time.)

- With more packages, we have more maintainers and this raises the demands
on our "management". I think we need _more_ management to handle our 1600
packages. This would probably be easier if we had less packages/
maintainers. (Though, the solution might not be to drop any packages or
maintainers, but to improve our management and organization!) 

- With fewer packages, it would probably be possible to have a few people
"maintaining" the stable releases. I'm sure, this would get us a lot new 
users.

- More companies might offer commercial support for Debian systems if the
distribution would be a bit more "compact". (Currently, I think it's hard
to offer support for 1600 pieces of software.)


Now back to our current situation:

We already have divided our packages into three "areas", namely main,
non-free, and contrib. When we speak of the "Debian GNU/Linux
distribution", we usually refer to "main". That's because we want to build
an operating system which consists only of free software components, as
defined in the social contract. 

Though, the packages in "non-free" and "contrib" are still actively
maintained and have to follow our policy (best as possible). Furthermore,
we use the same resources (bug tracking system, mailing lists, etc.) for
these packages.

Now to my suggestion: (Please note, that this suggestion is still in
_draft_ state :)

We could split "main" into smaller parts, namely a "base" distribution
and a few "add-ons". The "base" part (not to be confused with the current
"base" section--I'm still looking for a better name here) will form the 
new "Debian GNU/Linux" distribution (or operating system).

Ideally, the "base" distribution would fit on a single CD-ROM including
source code and documentation. 

The "add-ons" parts will also be fully "DFSG-free", will be maintained by
Debian developers, and will also have to follow our policy. I'm thinking
of a "Documentation add-on" which includes a lot of non-technical e-texts
(the bible, all texts from the Gutenberg project, etc.), a "Perl add-on"
which contains the whole CPAN packaged up in deb packages, a "TeX add-on"
which is nothing else but CTAN packaged up, a "Multimedia add-on", etc. 

For practical reasons, the add-ons should probably not exceed a CD-ROM,
including source code.

Then we might choose some nice names for our distribution parts, for
example,

     Debian GNU/Linux Base Distribution
     Debian GNU/Linux Multimedia Extension
     Debian GNU/Linux Perl Extension
     Debian GNU/Linux E-Texts Extension
     ...

How does this sound? (Professional, IMHO :-)

This setup should solve most of the problems I explained above, while
keeping the flexibility and the variety of packages we currently have. So,
a Linux newbie could start installing the base distribution. (Ideally, the
installation should not require knowledge of any packaging details as it
does now. It should suffice to say "I want X, development stuff, a web
server, no TeX, ..." for newbies.--We might implement this on top of the
current installation procedure so that the "freaks" don't loose the
flexibility we currently have.)

With the "extensions", the experienced users will get the advantage of
having several well-maintained archives of specialized software--all
packaged up for our distribution.


Now to the FAQ's :-)

Q: How does this affect our "open development model"?

A: Not at all. (That's the reason why I don't want to use the name "core" 
for the "base" part as this reminds me of other projects which use a
closed development model.) Our development model does _not_ have to be
changed. 


Q: Can't we use our "Priorities" values to determine the new sections?

A: (Note, that this point probably requires more discussion.)  I think we
could start including all packages that have priority values "Required",
"Important", and "Standard" in the base system and place all the other
packages into the "extensions". (I expect that some packages currently use
the wrong "Priority" value so we'll have to check the details first.)

So the idea simplifies to classify "Optional" and "Extra" packages and to
divide them into new "sections" which we'll call "extensions" (or
whatever). (We'd have to check if we can simply "map" our current sections
to extensions, e.g., all "doc" and "text" optional or extra packages can
go into the "Documentation extension", etc.)


Q: What different treatment would the non-base packages receive ?

A: Tough question! I'd propose that we should treat them similar like we
treat "contrib" or "non-free" packages now. (Except for the license
issues--non-base packages should still be completely free.) Thus, usually
the have to apply to all our policies, but there might be some exceptions. 
For example, we could decide that Debian 3.0 will be completely libc7
based, but still allow libc6 packages in the extensions.


Q: How will the FTP structure look like ?

A: I don't know! Perhaps something like this (for a distribution with code
name "foo"):

      /debian/foo/
		main/
		extensions/
			doc/
			perl/
			tex/
			multimedia/
			...
		non-us/
		contrib/
		non-free/

However, I can also imagine to have some very specialized extensions which
will be maintained outside the project. (I don't think we can assume
unlimited disk space at our mirror sites :-) Thus, "main" and the
extensions might be on different file systems.


Q: Which changes would be necessary to our tools? 

A: I think it would be necessary to change dselect and its successor(s) to
be able to handle multiple sources at the same time. The whole system
(base+extensions) will likely exceed a single CD-ROM in the future (and
DVD is not available widely yet :-) and the extensions might be located on
different Internet servers as well.


Ok, I'll stop now. Now it's your part to comment :-) (But please keep in
mind that we'll probably start the discussion on debian-devel in a few
weeks, again.)



Thanks for your attention,

Chris

--                 Christian Schwarz
                    schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl?     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
      
Visit                  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com     http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .