Re: Debian development modem
On Wed, May 27, 1998 at 06:00:20PM -0500, David Engel wrote:
> These replies are part of the discussion I was hoping to start.
>
> On Wed, May 27, 1998 at 08:44:05PM +0100, Enrique Zanardi wrote:
> > I agree. We know the symptoms. What about trying to identify the cause?
> >
> > Hints:
> >
> > 1) Huge number of packages. Many of them not actively maintained. That
> > makes very difficult to achieve goals that involve a significant part of
> > the distribution, like moving the whole distribution to libc6 or the
> > upcoming transition to FHS. IMHO, Debian would greatly benefit by breaking
> > "main" in "main-core" and "main-add-ons". Perhaps using priorities to
> > decide what goes where. (That would help in the "official CDs" front, I
> > guess).
> >
> > 2) No clearly defined goals/roadmap/schedule. Brian made a good schedule
> > a year ago, but it wasn't followed at all.
>
> I think you've hit the nail on the head here. I'll take a break from
> purely ranting and try to offer some constructive criticism. IMO, the
> two biggest problems with Debian are 1) that there is an extreme lack
> of strong leadership and 2) that the main distribution is way too
> large to be managed by an all volunteer work force.
IMHO, this is what we should do:-
a) Push out more releases, but label them "work in progress", or something
similar if need be. We _CAN_ do this every 3 or 6 months, and people
won't complain (hopefully).
b) Shrink the main distribution somehow. I'm not suggesting a "core
_developer_" approach - but a "core _distribution_" approach.
This means that I can maintain packages in both distributions, no matter
who I am, but that the distributions are managed (as a whole) separately.
c) Do our best to motivate people more. I personally would be motivated
by better PR on the part of the distribution, or free stuff (CDs,
T-shirts, etc). Better PR is important though, and making fairly
regular releases comes into that too.
What de-motivates me is seeing 500 messages on the -devel list I haven't
read, and having too much "catching up" to do before I know if its
worth doing any particular bit of development.
d) Try our best to create more manageable release goals. Releases should
be specifically planned to take 3 months to update. Most of the work
that actually should happen in a release should be updating to new
versions of packages. More long-term goals (eg FHS compliance, libc6
updating) should be managed very carefully. One possible solution
is to create a method of generating, eg both FHS and FSSTND packages
using the same scripts. Then, as packages are updated, we keep
two dists - the "standard" dist, which is released on time, and the
"long-term" dist., which becomes the standard dist when its ready.
In my opinion, the best thing we can do to keep the current stable
distribution well maintained (at any one time), is to make it easy for
people to maintain two versions of their package at a time, _OR_
when this is not possible, assign two maintainers.
I think the "standard"/"long-term" model will work well. BOTH should
be ACTIVELY developed at the same pace. In the case of many goals,
eg FHS, PAM, libc6, etc., packages can be made to compile to both
standard and long-term versions easily.
Another thing which might be useful would be a system whereby developers
actually upload only source changes, and the binaries are updated
automagically (except in certain circumstances). The *BSD folks do
this with CVS, but this would certainly achieve consistency fairly
easily.
> > 3) No easy way to transfer work to backup maintainers. Some critical
> > positions (ftp.debian.org manager, for example) are a lot of work for a
> > single person, even a hard working one as Guy Maor. Those positions
> > should have well known co-maintainers ("well known" added for those that
> > fear "dilluted responsibility").
> >
> > (more hints later...)
>
> On Wed, May 27, 1998 at 04:10:42PM -0400, Steve Dunham wrote:
> > (I would suggest that release delays are rising exponentially, but I
> > was around before the first release.)
> >
> > I have an idea that may remedy this: Split Debian into a core and
> > non-core distribution. The core distribution would contain the base
> > operating system and be worked on my a smaller group of developers.
>
> I would be very careful about this. One of Debian's greatest
> strengths is it's openness. That shouldn't be sacrificed with even a
> hint that Debian should go to a "core developer" approach.
Unfortunately, I am now tending to think that this is also one of Debian's
greatest weaknesses. There is too much list traffic (particularly on -devel)
for many to read everything (including myself). General development is
somewhat anarchic, and I don't think this is really due to a lack of
leadership.
Or maybe I just need a better mailing-list-reader (I'm using Mutt at the
moment, but I might try GNUs) :)
> > It would have it's own release schedule. (I working under the
> > hypothesis that all of the extra stuff is causing the big delay in the
> > release.) The core release would work similar to the current Debian,
> > with a possible addition of a CVS source tree. (But core developers
> > should only check out what they are working on, and use push
> > technologies to get updates to other pieces.)
The big problem with a core disitribution having a CVS tree is that it only
works for people with fast 'net access (although we could snarf CTM from
the *BSD folks). I would like to see core packages developped using CVS,
but not necessarily over the net using cvs.debian.org. The CVS repository
could be periodically synced to master for this purpose.
> > For non-core packages, I'd imagine a "stable" and "unstable" for the
> > last two incompatible core releases and for the current unstable core
> > release. (frozen core releases would take the place of one of the
> > first two.) There would have to be some criteria for moving a package
> > from unstable to stable.
>
> I'd rather see non-core packages simply moved to "contrib", with
> "contrib" clearly given a lower status than the core packages.
In our context, "contrib" has a different meaning. It needs to be
called something else. "core" and "periphery" (or whatever) are
good names, but you are confusing them with the *BSD style of
development.
--
Tom Lees <tom@lpsg.demon.co.uk> <tom@debian.org> http://www.lpsg.demon.co.uk/
PGP Key: finger tom@master.debian.org, http://www.lpsg.demon.co.uk/pgpkeys.asc.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: