Re: Debian development modem
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?
> 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
> 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.
> 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.
> 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.)
> 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.
David Engel ODS Networks
email@example.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com