Re: Goals for 1.3?
Christian Schwarz:
> (BTW is the new release called 1.3 or 2.0?)
I'd suggest to leave 2.0 for something major like glibc, kernel
2.2/3.0, at least one stable non-x86 architecture, building the
whole system from a single source tree, etc. (one of the above
mentioned things, not necessarily all of them :-)
> Here is an extrait from the mail "Upcoming Debian Releases" Brian posted
> here on "Sat Dec 21 00:27:50 1996":
> Thu, Jan 30, 1997 -- Bo will be frozen.
>
> Tue, Feb 25, 1997 -- Bo will be released.
We probably should change these dates, there is very little time left
before the next freeze. Better still, don't announce any release
dates until we are sure the system is ready to ship. Just in case
there is another security hole just before the scheduled release...
> - Boot disks should contain drivers for more systems/cards (???)
... but drivers that don't probe reliably shouldn't do it by default,
unless explicitly enabled at the boot prompt. cm206 locks up solid,
NE2000 cards are mis-identified as sonycd535 CD-ROMs, etc.
More suggestions for the boot/base disks:
- allow installation of the base system from a CD, without floppies
(and write a Debian-CD-Making-HOWTO so that people get it right).
- include vi (probably nvi - needs no X libraries) on base disks
(base14-4 is very small, so there is some extra space). Believe
it or not, some people find vi easier to use than ae :-).
> * No bug reports older than 12 months at release time
Some bugs need to be fixed upstream - I don't think we should close
them just to satisfy the above requirement... (and then re-open them
right after the release :-)
> * Move config information from install scripts to "cfgtool" (???)
Hmm, I feel a little nervous about putting thigs like
SULOGIN=`cfgtool --get boot.sulogin`
at the very beginning of /etc/init.d/boot. Why not just:
. /etc/default/boot
and have a tool to modify (carefully - create the new file with
different name, fsync() it, then rename() it) files containing
name=value pairs - the shell already gives us all the tools we
need to read them. Are there any problems with this?
> Any thoughts about that?
Start using the new pty devices (major 2 and 3) introduced in
the 2.0.x kernels. The old ones (major 4) may not be supported
in future kernel releases, and there is a maximum of 64 ptys
(with the new ones - 256). Packages that use ptys need to be
modified to use letters [p-za-e] insted of only [p-s].
Another nice idea would be to clean up /dev a little - there
are about 1000 entries there now, and it makes things slower.
Most of them aren't needed on most systems - they should be
created using MAKEDEV only if necessary. Also, maybe we should
tell the device list maintainers about that great concept:
directories... (example: /dev/vcs63 -> /dev/vcs/63)
Marek
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: