peter@taronga.hackercorp.com (Peter da Silva) (03/23/91)
Request for Discussion -- MINIX sources group.
The group comp.os.minix contains a large proportion of source postings:
including patches, updates to MINIX, and complete sources. For the past
couple of week there has been discussion about creating a separate group
for these postings. I have volunteered to run the vote, and have been
gathering material for a formal RFD, so here it is.
While it is considered traditional to create a moderated group, with a
name like comp.sources.minix, the largest proportion of material that does
not fall under the traditional definition of source postings... in fact
the majority seems to be large uuencoded archives of patches for the MINIX
kernel: patches from Andy Tannenbaum for new releases of MINIX, and patches
for enhancements like 32-bit mode on the 386 from MINIX users.
Thus I am presenting a number of options that have come up during the
discussion: a moderated traditional comp.sources.minix, an unmoderated
comp.os.minix.sources (or, to reflect the fact that it's not complete
source code postings, comp.os.minix.code), as well as my idea of a
moderated sources group and an unmoderated patches group. Several people
have come forward as possible moderators, should that option win.
There is also a gatewayed mailing list, and whether it should be split
into two lists or should be gatewayed to and from one and/or the other
also has to be considered. A separate binaries group, so people who
don't have enough CPU to run GCC can get GCC-compiled software, has
also been suggested.
Andy Tannenbaum, who is after all the author of MINIX and thus deserves
a couple of vote all by himself (:->), wrote the following in comp.os.minix
(in article <9302@star.cs.vu.nl>):
- I'm happy to have you run the vote. I definitely don't like the idea of
- a moderated group. I'm not even sure I'd contribute to it. Anarchy has
- worked pretty well so far. If we align with the formal structure of USENET,
- other people may insist that comp.sources.minix contains full programs, not
- just 2-line cdiffs and the like, since that is the way the other groups work.
- For copyright reasons that is not always acceptable, depending on the source
- of the material. In short, comp.sources.minix is quite different than
- comp.sources.xyz for all xyz. For this reason I don't think it belongs there
- in the hierarchy.
- Personally, I don't think a split is necessary, but if everyone else does,
- I could live with an unmoderated comp.os.minix.sources or maybe
- comp.os.minix.code or comp.os.minix.patches just to emphasize that the group
- is not intended for the exclusive posting of public domain sources.
- I would prefer to keep comp.os.minix, but if for technical reasons groups
- with the syntactic structure a.b.c.d and a.b.c are not allowed, then
- comp.os.minix could become comp.os.minix.d or comp.os.minix.disc.
- I think any voting proposal should at least have several possibilities.
- My own preferences from best (1) to worse (5) are:
- 1. Keep it as it is now Best
- 2. comp.os.minix and comp.os.minix.code (unmoderated) |
- 3. comp.os.minix and comp.sources.minix (unmoderated) |
- 4. comp.os.minix and comp.os.minix.code (moderated) V
- 5. comp.os.minix and comp.sources.minix (moderated) Worst
As for me, I'm not going to argue strongly for any particular case. There
are plenty of voices already, and as the vote-taker I don't believe it
would be proper for me to display significant bias.
--
(peter@taronga.uucp.ferranti.com)
`-_-'
'U`