This message is being sent primarily to the debian-policy mailing list, with a carbon-copy to another low-traffic list; I've set a reply-to to the policy list and myself, but don't know if it will stick.
I write to you as someone who wants to tell you what I wish to see in a Debian distribution who is seriously considering a switch as a user from RedHat (due to a lack of reponsiveness). First off, I am concerned that the current stable release uses a kernel quite a few years old: for stability, that is great, and should continue to be supported for that reason, however it is a sorry state of affairs for those of us who have been working for 4+ years on capabilities in the kernel that are finally now released and we expect to start seeing widespread acceptance, application development and implementation of (e.g., IPv6, standarized threads, etc.). As I have not inputted this into the Debian beaurecratic machine that I see mentioned at http://www.debian.org/devel/constitution and http://www.debian.org/vote/, I hereby request that you, where "you" is those of you who are able to do so, please do so where appropriate to further these concerns. 1. Fully switch to FHS 2.0 (http://www.pathname.com/fhs/) by the next freeze date. * I converted my system from an old 1994 Slackware distribution to FSSTND by hand, and that took about one full (hacker's) day. It saved me more than quadruple that amount of time in future incompatibilities due to filesystem differences: sticking to a standard really helps in this case. I was annoyed by FSSTND's lack of heterogeneous environment support, however. * I was annoyed to see FSSTND change names to FHS and change, but as soon as I cracked FHS open, my annoyance flittered away for the most part (exception being the odd names of everything and lack of aggression to fix those crazy names, but a standard is a standard and that is definitely what counts); I was happy to see that most of it centered around two important things: refinement and the new ability to handle heterogeneous environments, my chief complaint of the FSSTND which otherwise served me very well. Of course, I was sold immediately, and converted to FHS 2.0 immediately. This also took almost a day. I have since encountered no problems, am very happy with FHS 2.0, and advocate its adoption by everyone at this time ("immediately"). It is definitely my opinion that the idea of FHS/FSSTND is good, the specific standards are good, and going with FHS 2.0 is the right way to go. It should be in the next release. It saves that much time to do it; I mean, the time put into it will be rewarded by less time maintaining it later on. I recommend an intent of and attempt at "full" FHS compliance, but would (begrudgingly) accept a few lingering fixups that will wait until the following stable release. FHS 2.0 already isn't a pie-in-the-sky perfect holy sacrament; therefore not doing it exactly would be ridiculous (I could hardly stand *two* unholy variations of an imagined perfect theme!!!). Hint: when you send configuration patches to package maintainers nonspecific to Debian, please say something to the effect of ``The directory and file paths in the Debian/Linux configuration for this package have been upgraded from FSSTND 1.2 (or whatever it was) to FHS 2.0; please see FHS 2.0 at http://www.pathname.com/fhs/ for details on FHS'', in case some other package developer or maintainer is still running a FSSTND system (so as to prevent upgrade loops). 2. Get a Linux 2.2 kernel and GLIBC 2.1 based distribution out soon. A freeze date of September 1st has been proposed. Waiting for the Perl upgrades has been proposed. FHS is the only other thing. I propose that a freeze on everything besides FHS issues happen so that we may concentrate on FHS-izing everything; it's kind of a flag-day item, anyway, so this is OK to do it like this. Then, a freeze of the FHS stuff can finally happen, and a release worked on. Those good-feeling release dates that make us more media-savvy -- sorry, I cannot promise that. But it does make sense to get something out which has a current stable kernel version in it soon. 3. On a minor note, I find the "ip" program written by Alexey Kuznetsov <[EMAIL PROTECTED]> available at ftp://ftp.inr.ac.ru/ip-routing/ which replaces the "ifconfig" and "route" commands to be very well written in terms of usability and consistency, and recommend it to everyone who uses Linux 2.2+ and to the Debian distribution in general; I have not actually cracked open Potato so do not know the status of "ip" and the old "ifconfig"/"route" crap. Above other things, "ip" understands IPv6; "ifconfig" and "route" have many versions which do not: administratively, this trivializes the concept that the new and improved "ip" program (more stable, easier to use, more consistent, and more capable) will of course support IPv6 whereas the others are ``good luck, you'll need it''. In both cases, you need to compile properly to get IPv6 functionality. This brings me to my next paragraph. To repeat, replace "ifconfig" and "route" with "ip" in administrative utilities, initialization scripts, etc. I recommend that "ip" be *included* and *supported* by the next release (but not (necessarily) the initscripts, etc.), with the scripts switched over to using "ip" by the *following* release, if the next release is to come soon (i.e., less than two months); otherwise, to *very strongly* consider switching to "ip" in all initscripts, etc. by the next release completely. 4. I recommend the following time-release plan for IPv6 support: Here I work under the assumptions that IPv6 is not supported at this time by Debian (OOTB) and that a good plan for it does not exist; assumtions that may be woefully wrong since I have not actually looked; please interpolate as appropriate. IANA is now assigning IPv6 IP numbers (and consequently the regionals). It is now the time for IPv6 to ramp up. While the task of *fully* IPv6ifying Debian may be daunting and too large a chore for the very next stable release, I do recommend that at the very least the core-core-core packages be compiled with IPv6 enabled so that the progression to a Debian distribution with IPv6 is much, much easier due to the incremental nature of something as large as this type of upgrade. What this means specifically is that the kernel (v2.2) and the "ip" utility be compiled with IPv6 support compiled in (that is only two packages and trivial to do by a freeze date even less than a month away; I think it's ok to do IPv6 as a module in the kernel). Other packages with IPv6 support can come in at the speed that they make it naturally. So, under the assumption that the next release will not be fully IPv6 ready, it can be considered a semi-IPv6 release (kernel & "ip" program), with some document somewhere describing what is and what is not yet IPv6, with a future release down the road sometime being a full IPv6 release. If this is done on a slow-track, I recommend next stable release have kernel and "ip" utility with IPv6 compiled in; following release have most of the *simple* upgrades, such as those packages which already have IPv6 versions but just haven't been put into the Debian distribution until this prodding came up to do so (examples are some of the basic utilities such as ping, traceroute, etc., and, for backward compatability, the IPv6 enabled versions of "route" and "ifconfig" despite how much I hate them, as well as some of the larger packages such as Sendmail, FTP, Apache, DNS, etc. which have already had IPv6 upgrades applied to them in various places). Finally, a third stable release in the future can be considered a fully IPv6 enabled release, where every package is tested to work well on an IPv6 network; this is more involved, but the incremental nature of this IPv6 compliance I propose should severely reduce the amount of work involved in such a final test. Also, by that time, environments where this testing can actually take place will be more plentiful by then (until the development of the third stable release begins, some of us may still be "in the dark"). I think this is a reasonable expectation for the Debian project. Thank you for your attention. Please cc: to me as I sometimes don't track the mailing lists. Brad Allen <[EMAIL PROTECTED]>
pgp4bVjuQkOb0.pgp
Description: PGP signature
