Bug#1861: knews does not use /etc/news/server
Package: knews Version: 0.9.3 Revision: 1 When installing knews, it asks for a my nntp server name. It should check for the presence of /etc/news/server and use its connents if available. --- Kenny Wickstrom | gnu - a new generation in s/w devel/support [EMAIL PROTECTED] | Linux - a much improved Un*x clone (708)740-4008 | Debian - a Linux distribution setting the #include |standard for future distributions
Bug#1862: knews does not need to depend on X11R6
Package: knews Version: 0.9.3 Revision: 1 knews depends on X11R6 and does not need to. In my case, I use a different X-terminal and I don't need to have the entire X11R6 suite installed. I did dpkg --install --force-depends to install. --- Kenny Wickstrom | gnu - a new generation in s/w devel/support [EMAIL PROTECTED] | Linux - a much improved Un*x clone (708)740-4008 | Debian - a Linux distribution setting the #include |standard for future distributions
returned mailed everytime I mail to debian-changes
Mail Router writes: > From [EMAIL PROTECTED] Tue Nov 14 19:01:21 1995 > From: Mail Router (smail 2.9 dl,da,fa,tu,po,qf,lo,dbm 03/23/95 43) <[EMAIL > PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > Date: 14 Nov 95 10:03:02 GMT > Subject: Returned mail > To: [EMAIL PROTECTED] > > Your mail could not be delivered because of the following reason: > > >- Transcript of session follows - > No matching or similar name in the people > database for 'jasonbramsden'. Can he be removed from the debian-changes list or something? Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Re: Bug#1859: Start/stop scripts do not work when not invoked by init
Ian Jackson <[EMAIL PROTECTED]> said: > [...] It's just that /etc/init.d/functions is > obsolete, and should be replaced with an empty file so that people > stop thinking it's useful :-). > > It shouldn't be removed until all the packages that source it have > been updated not to do so, or they'll all fall over. Not only that. Done right, attempts to downgrade one of those packages to a version which requires /etc/init.d/functions should be refused after the sysvinit package is upgraded to a version which does not suppoly /etc/init.d/functions. As I understand it, the supported mechanism for doing this is for the sysvinit package to declare version-based conflicts with the latest version of each individual package and version which requires /etc/init.d/functions. This is unlikely to happen, I'd guess. That means that packages will be able to be downgraded to earlier versions which will fall over because of /etc/init/functions being missing.
Overdue problem reports
The following problem reports are very old but have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] or as forwarded to a developer by CCing a message to [EMAIL PROTECTED] Please help ensure that these bugs are dealt with quickly, even if you are not the package maintainer in question. (NB a full list of outstanding bug reports is posted on Fridays - this is a partial list only!) OVER 9 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 379 mount Repeatable mount(1) problem wi Bill Mitchell <[EMAIL PROTECTED] 416 wenglish perl doesn't flush output auto [EMAIL PROTECTED] 421 term unreasonable restriction on te Raul Miller <[EMAIL PROTECTED]> OVER 8 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 563 tartar -x fails to overwrite or c [EMAIL PROTECTED] (Ian Jackso 579 image (?) missing /usr/man/man8 manpages Bill Mitchell <[EMAIL PROTECTED] OVER 7 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 660 gdbGDB gets address of structure [EMAIL PROTECTED] (Ian Jackso 662 procps top doesn't behave sensibly if [EMAIL PROTECTED] (Ian Jackso 691 textutils textutils package, fmt(1) prog Bill Mitchell <[EMAIL PROTECTED] 702 findutils locate crash with large db Ernie Elu <[EMAIL PROTECTED] 710 xs3X server problem with hardware [EMAIL PROTECTED] (Ian Jackso 713 mh mh should pause after printing [EMAIL PROTECTED] (Ian Jackso 723 xconfigX server default configuration [EMAIL PROTECTED] (Ian Jackso 725 xbase twm places windows incorrectly [EMAIL PROTECTED] (Ian Jackso 729 procps Bizarre corrupted output from [EMAIL PROTECTED] (Ian Jackso 731 ncursesncurses wgetnstr doesn't work [EMAIL PROTECTED] (Ian Jackso 737 gawk gawk references to `$0' in END [EMAIL PROTECTED] (Ian Jackso 740 xbase xclock leaves `droppings' in i Ian Jackson <[EMAIL PROTECTED] 746 cpio mt doesn't support setblk (and [EMAIL PROTECTED] (Ian Jackso 759 kbd, xbase /usr/bin/X11/showfont conflict [EMAIL PROTECTED] (Raul Miller) 773 xbase xmh falls over if mh is not in [EMAIL PROTECTED] (Richard K 775 xbase twm reports errors on incorrec [EMAIL PROTECTED] (Richard K 783 tartar --same-order doesn't work [EMAIL PROTECTED] (Ian Jackso 784 manpages Infelicities in fopen manpage [EMAIL PROTECTED] (Ian Jackso 785 cpio mt problems[EMAIL PROTECTED] (Bill 786 syslogdsyslogd gone awol [EMAIL PROTECTED] (Ian Jacks 797 (base) /etc/termcap console keydefs f Bill Mitchell <[EMAIL PROTECTED] 798 svgalibsvgalib gets control key mucke [EMAIL PROTECTED] (Raul Miller) OVER 6 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 808 emacs Info anchors not active in ema [EMAIL PROTECTED] 817 tartar -T /dev/null extracts whol [EMAIL PROTECTED] (Ian Jackso 818 bash bash builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 819 tartar should have null-separated [EMAIL PROTECTED] (Ian Jackso 820 tcsh tcsh builtin `echo' doesn't ch [EMAIL PROTECTED] (Ian Jackso 821 shellutils /bin/echo doesn't check write [EMAIL PROTECTED] (Ian Jackso 822 tartar -t doesn't check write err [EMAIL PROTECTED] (Ian Jackso 824 cpio cpio should have non-verbose, [EMAIL PROTECTED] (Ian Jackso 825 trntrn warning messages corrupt t [EMAIL PROTECTED] (Ian Jackso 827 libc or sh who reports wrong hostname (wa [EMAIL PROTECTED] (Christian 835 sysklogd syslogd dies, leaves system un [EMAIL PROTECTED] (William 836 (base) Possible bugs in termcap syste "Emilio C. Lopes" <[EMAIL PROTECTED] 841 ncursesdselect from dpkg 0.93.34 says [EMAIL PROTECTED] (Bill 844 manpages readdir(3) should document str [EMAIL PROTECTED] (Ian Jackso 845 manpages access(2) is ambiguous [EMAIL PROTECTED] (Ian Jackso 850 indent [indent] option mentioned in d [EMAIL PROTECTED] (J.H.M 853 shellutils `nice' does not do anything[EMAIL PROTECTED] (Ian Jackso 857 gs_bothgs (2.6.1pl4-4) doesn't use /e [EMAIL PROTECTED] (Ian Jackso 860 mount `only root can mount' can mean [EMAIL PROTECTED] (Ian Jackso 864 make make gets MAKEFLAGS wrong [EMAIL PROTECTED] (Ian Jackso 887 xarchieR6 xarchie barfs when ftp closes [EMAIL PROTECTED] 889 info Info 3.1-6 [EMAIL PROTECTED] (Emilio C. OVER 5 MONTHS OLD - ATTENTION IS REQUIRED: Ref PackageKeywords/Subject Submitter 902 lprlpr can't print a PostScript f [EMAIL PROTECTED] (Ian Jackso 903 (base) /dev miscellaney Bill Mitchell <[EMAIL PROTECTED] 911 libc libc causes rsh to fail on com [EMAIL PROTECTED] (Ian Jackso 918 miscutils mkboot and image packages [EMAIL PROTE
Re: New packaging guidelines - draft
Ian Jackson <[EMAIL PROTECTED]> said: > Below is a draft copy of a revised set of packaging guidelines. > Please comment if you feel appropriate. [...] Comments: 1. "Text documentation should be [...] installed in /usr/doc." This is wrong. Text documentation should be installed in /usr/doc/. /usr/doc got so cluttered that it was decided to require packages to use individual subdirectories. 2. "If a subdirectory of /usr/doc is warrented, please create one." This should be strengthened, I think. Packages should install no plain files in /usr/doc. Packages may install subdirectories /usr/doc/ and /usr/doc/examples/ and place items in those subdirectories. 3. "include a description of your changes in the `debian.README' (which, as described above, [...]" However, debian.README has not been described above. 4. "`Description'The description of the package" This needs to explain about the extended description field, its formtting requirements, how strongly it's suggested, and its desired content (some packages have been criticised after uploading on the basis of extended description content. If such criticism is to be forthcoming, guidelines for avoiding it should be provided.). 5. "`Essential' a boolean field used by the base packages" Should provide info on the required contents to indicate the boolean values True and False. (wait a minute. I now see that this information is provided, but it's provided five pages later. Perhaps the information be relocated.) 6. "`Section' The `section' of the package, as shown and used by `dselect', and used as a location for this package in the distribution." I think we decided that this is no more than a suggestion by the package maintainer, and that the central distribution maintainer may decide, without consultation with the package maintainer, to place the package elsewhere than in the location described by this field. I also believe that we decided that when this is done, the (now erronious and misleading) `Selection' field provided by the package maintainer will be retained. The central distribution maintainer is not under any requirement to notify the package maintainer of this situation. (I note that this field is re-discussed several pages onward, under "Priority, Section, and Essential". Rather than being discussed partway in each of two places, perhaps these fields should be discussed only in one place. If they're mentioned in more than one place, a pointer can be provided where they're mentioned to the place where they're discussed.) 7. "If your maintainer scripts need to prompt for passwords and/or do full-screen interaction should do these things [...]" ^ +-- missing words? 8. "and they should ensure that the user will only every be asked [...]" ^ ? 9. "If these scripts exist they shouuld be left in the `DEBIAN' directory [...]" This sounds as if we've suddenly shifted gears from talking about files and directory locations on the target system to files and directory locations in the package being constructed. This section seems to be speaking to the situation where a package maintainer has taken over responsibility for a pre-existing package and has found a DEBIAN directory in the source package. This needs more foundation. 10. "The `Conflicts' field lists packages that conflict with this one, for example by containing files with the same names. [...]" However, this is not an absolute, and this should be explained. For example: elv-fmt and textutils packages, for example, both supply /usr/bin/fmt. It's been determined, however, that these packages should be allowed to overwrite this file from whichever package happened to be installed last without specifying a conflict with one another. Such special cases should be explained in the packaging guidelines, and guidelines should be provided for when, what, and why special-case handling is appropriate. The various vi clones use a rather baroque "update-alternatives" mechanism, which needs to be mentioned here with a pointer to the documentation. 11. A pointer to the document describing legal virtual package names, their menaings, and the procedure for establishing and advertising a new virtual package name should be provided. 12. "Priority, Section and Essential [...] "you should be sure you keep this information up to date [...]. This implies an assumption that package installers will always be working from a matched set of the most up to date packages. That assumption won't always be satisfied. This isn't the forum for this, but I have doub
Re: New packaging guidelines - draft
Ian Jackson <[EMAIL PROTECTED]> said: > Below is a draft copy of a revised set of packaging guidelines. > [...] >(This file was last updated on 6th November 1995. Please check the > directory `project/standards' at any Debian GNU/Linux archive for a > potentially more up to date copy.) How about creating a packaging-info.doc package, and placing it in the distribution? It could just unpack packaging information docs into /usr/doc/packaging-info. Some or all of the individual docs could also be placed on the distribution site, of course.
Re: New a.out/ELF development packages
> I've uploaded the first cut at the new a.out and ELF development > packages to ftp.debian.org. Only the binary (.deb) and diff files are > currently there. It will probably take all night to upload the source > files to my machine at work so I won't upload them until tomorrow. Has anyone besides Ray Dassen tried these out yet? Ray has sent me a couple of minor suggestions which I will incorporate in the next day or two. While I'm doing that, I'd like to fix any problems others may have found as well. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: returned mailed everytime I mail to debian-changes
Andrew Howell wrote: > Mail Router writes: > > No matching or similar name in the people > > database for 'jasonbramsden'. That name isn't in the subscriber list. Sometimes people get the list via a secondary reflector or an alias. The system probably has its mailer misconfigured, as it should always return errors to the Errors-To address or the envelope "from" address, in that order. Neither of these contained your address. I note wryly that it belongs to ATT. Thanks Bruce -- See Pixar's "Toy Story", at a theater near you starting November 22. "Toy Story" Toys and Soundtrack Album are available now!
Bug#1863: smailconf perl5 problem
Package: smail Version: 3.1.29.1-13 smailconf generates broken 'satelite' system configuration. The following Patch will fix this: --- /usr/sbin/smailconfig~ Mon Jun 26 14:19:54 1995 +++ /usr/sbin/smailconfig Tue Nov 14 22:15:41 1995 @@ -377,7 +377,7 @@ " smart_user: driver=smartuser; - [EMAIL PROTECTED], + [EMAIL PROTECTED], well_formed_only "); Gretings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],ka.sub.org} http://home.pages.de/~eckes/ o--o *plush* 1024/E010B09D [EMAIL PROTECTED] +4972573817 *plush* (OO) If privacy is outlawed only Outlaws have privacy
Bug#1864: smail logfiles
Package: smail Version: 3.1.29.1-13 The logfiles of smail are stored in /var/spool and not /var/log. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],ka.sub.org} http://home.pages.de/~eckes/ o--o *plush* 1024/E010B09D [EMAIL PROTECTED] +4972573817 *plush* (OO) If privacy is outlawed only Outlaws have privacy
Bug#864: Re: smail-3.1.29-1: ambiguous switch for 'make'
In May I reported to debian-bugs a bug in make 3.73-1 that makes it
impossible to build Debian's Smail package with Debian's make.
This bug still exists in 3.74-1 (and the debian-bugs logs don't
contain any messages about the problem being passed on to the FSF).
Surely we and the FSF can do better than this ? In the meantime I'll
keep using my own private binary of GNU make 3.70.
Ian.
--- start of digest (3 messages) (RFC 934 encapsulation) ---
To: Debian bugs submission address <[EMAIL PROTECTED]>
Subject: make gets MAKEFLAGS wrong
Package: make
Version: 3.73-1
When trying to build smail (3.1.29.1-11, source code will be on
ftp.cps soon) I get:
make: option `--w' is ambiguous
numerous times, with usage messages.
I seem to remember this being due to an incompatible and broken change
in the semantics of MAKEFLAGS.
Please can this change be reversed, or the old `make' restored.
In the meantime I'll have to build Smail with my old installation's
make.
Ian.
--
From: [EMAIL PROTECTED] (J.H.M.Dassen)
To: [EMAIL PROTECTED]
Subject: smail-3.1.29-1: ambiguous switch for 'make'
Date: Tue, 13 Jun 1995 13:38:10 +0200 (MET DST)
Message-Id: <[EMAIL PROTECTED]>
Ian,
it looks like one of the options given to make while building smail-3.1.29-1
is ambiguous when using make-3.73, resulting in a failing build.
While making the dependencies, make is called with '--wn'; make --help
shows no option matching this.
Options starting with '--w' are: '--what-if=FILE' and
'--warn-undefined-variables'.
Could you disambiguate this for the next release?
Regards,
Ray
- -- begin shortened 'debian.rules binary' log --
[...]
chmod -w Makefile
Make dependencies under conf ...
make[2]: Entering directory `/exp/build/farm4/smail-3.1.29.1/conf'
Make dependencies under conf/arch ...
make: option `--w' is ambiguous
Usage: make [options] [target] ...
Options:
-b, -m Ignored for compatibility.
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
-d, --debug Print lots of debugging information.
-e, --environment-overrides
Environment variables override makefiles.
-f FILE, --file=FILE, --makefile=FILE
Read FILE as a makefile.
-h, --help Print this message and exit.
-i, --ignore-errors Ignore errors from commands.
-I DIRECTORY, --include-dir=DIRECTORY
Search DIRECTORY for included makefiles.
-j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg.
-k, --keep-goingKeep going when some targets can't be made.
-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is below N.
-n, --just-print, --dry-run, --recon
Don't actually run any commands; just print them.
-o FILE, --old-file=FILE, --assume-old=FILE
Consider FILE to be very old and don't remake it.
-p, --print-data-base Print make's internal database.
-q, --question Run no commands; exit status says if up to date.
-r, --no-builtin-rules Disable the built-in implicit rules.
-s, --silent, --quiet Don't echo commands.
-S, --no-keep-going, --stop
Turns off -k.
-t, --touch Touch targets instead of remaking them.
-v, --version Print the version number of make and exit.
-w, --print-directory Print the current directory.
--no-print-directoryTurn off -w, even if it was turned on implicitly.
-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
Consider FILE to be infinitely new.
--warn-undefined-variables Warn when an undefined variable is referenced.
Make dependencies under conf/driver ...
make: option `--w' is ambiguous
[...]
Make dependencies under conf/os ...
make: option `--w' is ambiguous
[...]
Make dependencies under conf/lib ...
make: option `--w' is ambiguous
[...]
make[2]: *** [depend] Error 2
make[2]: Leaving directory `/exp/build/farm4/smail-3.1.29.1/conf'
[etc...]
- -- end --
- --
UNFAIR Term applied to advantages enjoyed by other people which we tried
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY,
UNDERHAND and JUST LUCKY I GUESS.
- - The Hipcrime Vocab by Chad C. Mulligan
--
To: [EMAIL PROTECTED] (J.H.M.Dassen),
Debian bugs submission address <[EMAIL PROTECTED]>
Subject: Bug#864: Re: smail-3.1.29-1: ambiguous switch for 'make'
J. H. M. Dassen writes ("smail-3.1.29-1: ambiguous switch for 'make'"):
> it looks like one of the options given to make while building smail-3.1.29-1
> is ambiguous when using make-3.73, resulting in a failing build.
>
> While making the dependencies, make is called with '--wn'; make --help
> shows no option matching this.
> Opti
dselect CD-ROM / hard disk / NFS method
I'm going to program the names `stable' and `development' for the two release trees and `contrib' and `non-free' for the secondary package trees into the dselect disk-based installation scripts unless someone tells me otherwise. If it sees what looks like a Debian mirror of some kind (possibly in a `debian' subdirectory) and has `stable' and `development' subdirectories it will offer the user the choice between the stable tree and the development one, rather than requiring them to specify the pathname themselves. (The user will still be able to specify a different pathname if they want to.) If `contrib' and `non-free' directories are detected it will offer to use those too; otherwise it will say it doesn't see them anywhere and will ask the user if they know where to find them. It will be much easier for the user if the script has the right names. So, in summary, the script will look for trees named stable development contrib non-free and in each tree will it look for binary and binary/Packages or binary/Packages.gz It will look for these trees in the root of the installation filesystem, or in a subdirectory `debian' of that filesystem. Ian.
Re: Free CD's to authors
Andrew Howell <[EMAIL PROTECTED]> writes: > Holger gave me permission to package mirror magic. As I understand our > distribution policies, packages which we don't have permission to put > on the CD go in non-free. > > Andrew No, if you have to *ask* for permission, then it isn't free. It would be conditionally free for Debian (until permission is withdrawn), but would remain non-free (or less-free) for users of Debian. That's bad. Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
Re: md5sum passwords
Andrew Howell <[EMAIL PROTECTED]> writes: > After discussing security with some friends we got around to using > md5 instead of crypt. I think you mean "instead of DES". It's the crypt(3) function that would be changed to use MD5 (MD5a). > This has been brought up before but nothing much seemed to > happen. Is debian going to switch to md5 with 1.0 or are people > opposed to this? I think switching would probably be a decent idea, although it is not of earth-shattering importance to me. I'm also concerned about doing Debian doing it alone, instead of with the cooperation of the rest of the Linux community. I am more interested in longer user names and longer password. I'm disgusted with being limited to eight characters. A little reading on using MD5 instead of DES turned up a FreeBSD web page on the topic. http://www.freebsd.org/handbook/handbook68.html BTW, I like the way their manual is set up and on the web. And I also like that it seems more geared to open contributions than the Debian manual. Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
Re: md5sum passwords
Date: Wed, 15 Nov 1995 02:29:27 GMT From: Daniel Quinlan <[EMAIL PROTECTED]> BTW, I like the way their manual is set up and on the web. And I also like that it seems more geared to open contributions than the Debian manual. Hmm.. Well, I did release a draft of the manual in July so that the Project could contribute. I've received exactly two patches to date. Due to lack of interest, I never released an updated interim draft, and I'm still in the process of getting ready to release the final draft. What, exactly, have I done to discourage "open contributions"?
Re: md5sum passwords
Daniel Quinlan writes: > I think you mean "instead of DES". It's the crypt(3) function that > would be changed to use MD5 (MD5a). Yes, wasn't thinking straight obviously. > I think switching would probably be a decent idea, although it is not > of earth-shattering importance to me. I'm also concerned about doing > Debian doing it alone, instead of with the cooperation of the rest of > the Linux community. Though it would be nice if the whole community switched I don't think it's that great a deal whether they do or not, us using MD5 and others using DES shouldn't lead to any incompatibilties or problems as far as I can see. > I am more interested in longer user names and longer password. I'm > disgusted with being limited to eight characters. Yes, MD5 obviously makes the system that much more secure from attempts at using crack on a passwd file. MD5 being much slower than DES and also just the fact that you can't count on the password being 8 characters long anymore would make it a quite a more difficult process. Andrew -- Dehydration - 34%, Recollection of previous evening - 2%, embarrassment factor - 91%. Advise repair schedule:- off line for 36 hours, re-boot startup disk, and replace head - wow, what a night! -- Kryten in Red Dwarf `The Last Day' Andrew Howell [EMAIL PROTECTED] Perth, Western Australia [EMAIL PROTECTED]
Re: dselect CD-ROM / hard disk / NFS method
On Wed, 15 Nov 1995, Ian Jackson wrote: > If it sees what looks like a Debian mirror of some kind (possibly in a > `debian' subdirectory) and has `stable' and `development' > subdirectories it will offer the user the choice between the stable > tree and the development one, rather than requiring them to specify > the pathname themselves. (The user will still be able to specify a > different pathname if they want to.) > [...] > So, in summary, the script will look for trees named > stable > development > contrib > non-free > and in each tree will it look for > binary > and > binary/Packages > or > binary/Packages.gz > > It will look for these trees in the root of the installation > filesystem, or in a subdirectory `debian' of that filesystem. "it" is dselect, right? Unless I misunderstand, that's what it looks like to the user. Could we have a dselect(1) or dsleect(8) man page which explains such things as this, or points the user to another man page which explains them?
Re: md5sum passwords
On Tue, 14 Nov 1995, Ian Murdock wrote: >BTW, I like the way their manual is set up and on the web. And I >also like that it seems more geared to open contributions than the >Debian manual. > > Hmm.. Well, I did release a draft of the manual in July so that the > Project could contribute. I've received exactly two patches to date. > Due to lack of interest, I never released an updated interim draft, > and I'm still in the process of getting ready to release the final > draft. What, exactly, have I done to discourage "open contributions"? If I might offer a general comment here without it being taken as confrontational, I think the general linux and LDP models have worked better than the debian model has. As I perceive it, the linux and LDP models have been to make "best current effort" releases continually available, with known shortcomings acknowledged in a highly visible fashion alongside requests for help, info, contrbutions (e.g., in the LDP publications, numerous sections unashamedly labeled as just a guess, or still in progress, or yet unwritten, or as needing input). For those able and motivated to contribute, this has highlighted areas where contributions would be useful. For those not in those categories, the portions which were more finished were useful, even if the total work was unfinished. The debian model, OTOH, has been to keep everything pretty private until the development team, or its key members, judged things good enough to make public. I think we might have made faster progress with a more open model. This might be a bit harsh WRT the distribution itself. Too much open input can lead to a lot of haggling over diverse viewpoints on this or that alternative (not that we haven't had a bit of that anyhow). However, I think that perhaps it might be useful to make the documentation public in a less-than perfect state, formatted so that it's easy to identify mostly-finished and mostly-unfinished areas.
Re: md5sum passwords
Ian Murdock <[EMAIL PROTECTED]> writes: Daniel Quinlan <[EMAIL PROTECTED]> >> BTW, I like the way their manual is set up and on the web. And I >> also like that it seems more geared to open contributions than the >> Debian manual. > Hmm.. Well, I did release a draft of the manual in July so that the > Project could contribute. I've received exactly two patches to > date. Due to lack of interest, I never released an updated interim > draft, and I'm still in the process of getting ready to release the > final draft. What, exactly, have I done to discourage "open > contributions"? It was not my intent to insult. Maybe I should offer some suggestions that might help encourage contributions. 1. Release a new copy. Make it very public. It has been my experience that contributors are more apt to continue contributing if things aren't kept so private and are updated often. - People like to see the results of their work - People like to contribute to projects that are moving forward at a significant pace or are updated often. - People don't like to repeat work. Knowing the status of things means that you won't repeat work. - The urge to work is often the result of seeing something new that you have strong feelings about (positive or negative). 2. Stop calling it a draft, call it a work in progress. Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
Re: md5sum passwords
Bill Mitchell <[EMAIL PROTECTED]> writes: > This might be a bit harsh WRT the distribution itself. Too much > open input can lead to a lot of haggling over diverse viewpoints on > this or that alternative (not that we haven't had a bit of that > anyhow). Open input is good, in general. If you want to guarantee haggling, do it on a mailing list. If you don't want haggling, have input sent to a responsible party. Most Debian contributors seem to think every issue concerns everyone, everyone debates on everything, everything goes very slowly. If you want to speed things up, I suggest these initial steps: - Send bug reports only to the maintainer, mirror them on a WWW-site. (A good example -- http://www.cogs.susx.ac.uk/cgi-bin/ltxbugs2html) Maybe also send them to packages that are related. Mirroring the bugs to debian-devel was a stupid idea from the beginning, IMHO. - Try to send comments to the maintainer, unless it's something that really concerns everyone. Dan -- Daniel Quinlan Member of the League for Programming Freedom [EMAIL PROTECTED]
