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]

[RFC] Restructuring of the Debian Project



Debian GNU/Linux                                         Dominik Kubla
Request for Comments                                        March 1997
Category: Proposal                                       


	           Restructuring of the Debian Project


Status of this memo

   This memo is intended for the developers within the Debian Project.
   It does not describe any procedures or standards and is intended
   solely as basis for further discussion.  The distribution of this
   memo is restricted to the "debian-private" mailing list.

Introduction

   It was expected, the the election of a "Board of Directors" to
   oversee the further development of Debian, would move the project
   back on track and enable the developers to engage in constructive
   work.  But recent events have shown, that the current development
   is

   a) not favoured by a large group of the developers, not to mention
      many users,

   b) not without flaws, which are increasingly difficult to fix or
      circumvent,

   c) and that the number of developers and software packages has
      reached unmanageable proportions.

   Because of this several changes to the Debian Project are proposed
   to complement the election of a Board of Directors (BoD) earlier
   this year.

Reorganisation of the distribution

   At first the current specifications for developers need to be
   reworked and clarified.  There are some points which have caused
   lengthy discussions, but have never been completely resolved, like
   the /usr/local issue or the usage of non-standard interpreters like
   perl for system scripts.

   As a matter of fact the author firmly believes, the the compliance
   with existing standards like POSIX, SVID and XPG shall be the
   ultimate goal of any development of a Unix-compatible operating
   system.  So the author proposes, that the use of non-standard
   software should be limited to the user and application level and
   should not be used by any part of the system unless the relevant
   function is not needed to rebuild, install or maintain the system.
   If software required by any of the aforementioned standards is not
   available ad free software, it should be the goal of the Debian
   community to write a free implementation, essentially converting
   the Debian developers from mere VAR's to true developers of free
   software.

   In addition the current way Debian manages system resources,
   software, users and printers shall be reviewed and if possible
   adjusted to follow the IEEE proposals outlined in 1003.x and
   1387.x, formerly known as POSIX.7

   Other issues like a road map for the development have been proposed
   in the past, but for various, often not widely known reasons, never
   been done, so that developers started to pick what they thought
   would fit best.  That created an unmanageable system, where, at the
   moment, three different tcl versions, perl and a lot of other
   non-standard (again speaking in terms of POSIX, SVID and XPG)
   software needs to be present on the system if a random package
   should install without any problems.  And even then the
   installation is not error free, not even for essential parts of the
   system. This is a problem not to be taken lightly, but all to easy
   to solve, if the will is there to do it.

   So the following restructuring of the distribution is proposed:

   a) Basic system (Debian GNU/Linux):
      - The Linux kernel
      - The run-time libraries needed (glibc, ncurses, ...)
      - All tools needed to use Linux features (eg. modutils)
      - All tools required by POSIX (IEEE 1003.2).
      - All tools required by System V Interface Definition (SVID3),
        with the exception of SCCS, which is not freely available.
      - All tools required by the X/Open Portability Guide (XPG4).
      - Tools commonly found on BSD-derived systems, those are to be
        placed under /usr/ucb.

      The base system is installed as one package, eg. BASE-2.0.deb.
      Subsequent changes are distributed as "fixes", eg FIX970401.deb.
      The base system is distributed without sources, which can be
      retrieved as a single unified source-tree from the Debian master
      site or any of its slave sites.

      The Base System is intended to be capable of running any
      command-line and character-graphics oriented POSIX-based
      application without the need of further system software.
      In addition the Base System shall contain all software needed to
      fit a system in to networked system, may it by for dedicated
      applications like a Point-of-Sale system or a network client which
      gets all additional software from a central server. 

   b) X11 Environment (Debian X11 Environment):

      - The X11R6.1 core distribution (to be replaced by X11R63 as soon
        as possible).
      - The X11R6.1 contributed software as distributed on the "contrib
        tape" of the, now dissolved, X Consortium.
      - In addition to the standard Athena Widget set, it is recommended
        to select a more sophisticated toolkit.  In the light of the
        recent success of the Motif-based CDE, the use of the free Motif
        clone called "lesstif" is suggested.

      The suggestion to choose a single toolkit for all X11-based
      applications is driven by the need to offer a single coherent
      user interface.  This has to be done, because the resources of
      the Debian developers are not sufficient to maintain and document
      several distinct interfaces at once.

      Also CDE chosen as the standard by commercial vendors is not
      available as free software, a strong commitment by Debian to use
      a CDE equivalent, may ignite the development of a free CDE, a
      move which would benefit the whole Linux and Unix community.

   c) Software Development Kit (Debian/GNU SDK)

      - The GNU C-Compiler suite.
      - The GNU binutils
      - Utilities found in the original "Programmer's Workbench":
        cb, cflow, cxref, lint, ...

      The SDK includes all development tools needed to recompile both
      the Base System and itself without the need of further software
      components.

   d) Additional Software Packages.

      All the packages that are not covered above, but are actively
      maintained through the Debian bug-tracking system.  These
      packages are to be installed under /opt/debian.

   e) Contributed Software Packages

      All the packages not covered above and distributed under a free
      license.  Maintenance of these packages is not guaranteed.
      These packages are to be installed under /opt/contrib.

   f) Commercial and Non-Free Packages

      All the packages not covered above. Maintenance of these
      packages is not guaranteed, buy may be done at the discretion of
      their distributors.  They are not distributed via the Debian
      Network, only registered in the "Available Software Database".
      These packages are to be installed under /opt/<vendor> or
      /opt/non-free.

   This way all software not maintained by the core team has a stable
   and well-defined environment in which it can be compiled, packaged
   and distributed.  Together with stricter rules on what may be
   assumed by any package, this should make the maintenance of Debian
   software packages much easier.

Reorganization of the Development team:

   In order to reflect the proposal above and to avoid problems
   inherent to the current development process, a core group of
   developers need to be created which are responsible of maintaining
   the BASE and SDK systems from a single source tree.  This source
   tree needs to be appropriately controlled, which calls for a
   revision control system.  To avoid duplicating existing
   developments, the use of existing software is necessary, even if
   the software enforces certain changes on the work of the
   developers.
	
   Therefore the use of CVS/SUP for the source repository and GNATS
   for the bug-tracking is recommended.  The existing bug-tracking
   system may stay in place for the maintenance of packages listed in
   category "d" above, but the policy of forwarding all bug reports
   to the mailing list should be reconsidered.

Reorganization of the Debian Project:

   With the recent turmoil around the position of the project leader,
   it is proposed, that the following actions should be taken:

   - The Board of Directors should appoint a new Project Leader to
     ensure continuous leadership.  In addition it should appoint the
     officers needed to oversee the organizational part of the
     project.

   - The Board of Directors should register a company called "The 
     Debian Association, Inc." as a non-profit organization.  All
     affiliations with "Software in the Public Interest" should be
     terminated.

   - The Board of Directors should register "Debian" as a trademark
     of "The Debian Association, Inc." to prevent misuse of the name,
     as has happened with "Linux" in the US.

   - The Board of Directors should call for a vote by developers and
     users regarding the proposal of a fee collected from CD
     manufactures.  The aforementioned registration of a trademark
     would be the legal foundation for that.

   - The Board of Directors should select from the active developers
     a well-skilled group of no more than 15 people to form the "core
     developers group", which will build and maintain the unified
     source tree.

   - The Board of Directors should select a small group from the
     developers to update the Developer's Manual to reflect the changes
     proposed above, as well as clarify outstanding problems (like the
     /usr/local problem or the usage of Pluggable Authentication Modules
     as a standard).

   - The Core Developers Group should draft a road map outlining the
     further development of the Debian system and submit it for the
     Board of Directors for approval and publication.

   In addition the BoD should start to contact Software Vendors
   selling products for Linux and encourage them to package their
   software for Debian GNU/Linux and to use Debian GNU/Linux as a
   development platform.  With the reorganization of Debian as
   proposed above, it should be easy to convince them of the stability
   and maturity of both Debian GNU/Linux and the development team
   behind it.

About Policy Changes

   Proposals for changes of the project policy should be brought
   forward to the Board of Directors in form of a "Request for
   Comments", which then should decide whether or not to put the issue
   on vote by the developers and/or users.  Voting on fundamental
   issues should always include the users as registered on the
   debian-user and/or debian-announce mailing lists.