Releasing Potato
This message started out on -private; I've revised it a little thanks
to some comments from Martin "Joey" Schulze. I'll confine my editing
to [stuff in brackets], and adding a few points along the way.
---
[Responding to discussion about how many extra eons it'll take to
release potato if we also update slink.]
We can't release potato in the near future anyway, unless we accept:
1. Policy version >= 3.0.0.0 is invalid for potato. (i.e. we revert to
FSSTND and throw out packages that already transitioned)
or
2. Policy 3.1.0.0 specifies a transition that does not require the
modification of more than N packages, where N is ~sqrt(number of
packages in the dist.)
[NB: We're apparently going with 2, according to the tech
ctte. decision announced here. I assume the debian-policy package
will incorporate the tech ctte. decision soon.]
Nowhere has there ever been any discussion of what the minimum
acceptable standards-version for potato will be. If we do convert
wholly to FHS for potato (instead of fixing core packages to accept
FHS locations but not insist upon them), presumably it will be
3.0.0.0; otherwise, somewhere around 2.4.0.0 would be reasonable for
self-contained packages (i.e. ones that don't touch mail or look at
man pages or docs).
[See above. 2.4.0.0? 2.5.0.0? Inquiring minds want to know...]
The main problem is that there are no goals for potato. "Working boot
floppies for potato" means nothing without other goals, and therefore
is not a goal, because "potato" is an amorphous target.
[Joey pointed out that goals are controversial. My attitude is that
any release has goals, whether or not we come out and call them goals,
so we'd best make them explicit.
Anyway, now that the tech ctte. has acted, most of the "we need to get
this done" list for potato is simplified.]
Here are some real, satisifiable goals for potato:
1. Perl transition completed, by NMUs if needed.
2. All dummy transition packages have nothing in potato that depend on
them solely (i.e. Depends: perl | perl5 is OK; Depends: perl is
not). This affects python and a few other things too. [A list?]
3. XFree 3.4.* included.
4. Kernel 2.2.1[234567] as default kernel. Source packages have
gcc272 as compiler in Makefile, and depend on gcc272.
cfr. discussion on linux-kernel (it's not just union aliasing that
breaks the kernel on Intel).
5. All packages capable of dealing with FHS-compliant file locations
(i.e. web browsers can find docs in /usr/share/doc; man page readers
can find man pages in /usr/share/man; info browsers can find docs in
/usr/share/info; mail programs use /var/mail) as well as the
FSSTND-compliant ones.
[The /usr/share/doc thing is solved by the tech ctte. decision; I
don't know where man page and info readers stand. Perhaps "all"
can be "the most common". Note that the oft-cited "emacs has a man
command too" issue is bogus, since M-x man uses the man commmand.
And M-x info has found /usr/share/info for a while, IIRC.]
6. All packages provide documentation in the same location (either via
symlinks or real files). Precise method from tech ctte.
[/usr/doc for potato. See decision of tech ctte.]
7. glibc 2.1 included on all arches. [m68k still on 2.0? Can't
remember...]
8. apt 3.x included and relatively stable.
9. All (Depends, Recommends, Suggests) in potato are satisfied within
potato (+contrib/non-free/non-US), per policy.
10. Boot floppies that can cope with 1-9.
1 and 2 may be the same thing, and should be virtually completed. 3
is on it's way from XSF [3.3.4 is in, 3.3.5 is on the way]. 4 is
waiting on Linus or Alan to stabilize. Some of 5 may be waiting on
the tech ctte. The rest of 5 and 6 are done as soon as everyone
complies with the tech ctte. decision. 7 and 8 are done (I think).
We keep track of 9 somewhere. 10 is sorta on hold until we stabilize
on a kernel and base system (maybe we need an earlier "base freeze").
Are there any goals that need to be accomplished *other* than these?
If not, we should wait on these things being satisfied, freeze when
everything that doesn't require a new package is "in", and release.
I'm obviously missing what other people are saying is a problem with a
near-term release of potato. We're not in anywhere near as bad shape
as when slink froze... we have working CD scripts, boot-floppies that
sorta-work. We even have console-apt for the people who hate
dselect. What's not to love? :-)
Bottom line: the project doesn't need reorganization, a parliament, a
dpkg-maintainer coup, functional groups, or anything else. Let's get
on board for Richard Braakman's freeze date (only 8 weeks away!) and
push hard for the release of potato. In the meantime, we can get an
updated slink out there (2.1r4 or some such) in the next month or so
(with contributions from VARs) to cover us during the 2-4 months we
need to perfect potato.
Chris
--
=============================================================================
| Chris Lawrence | Get your Debian 2.1 CD-ROMs |
| <quango@watervalley.net> | http://www.lordsutch.com/ |
| | |
| Grad Student, Pol. Sci. | This address has been spam-proofed. |
| University of Mississippi | All spam goes to your postmaster. |
=============================================================================
Reply to: