Bug#197835: [PROPOSAL]: integrated environments are allowed
Perhaps we should 1. Not ship with EDITOR/PAGER set to anything by default (well written old standalone programs should then default to vi and more, or get a bug report). 2. Always honor EDITOR/PAGER if they are set. 3. Make sure GNOME programs can be set up to launch a different editor than $EDITOR/$PAGER with user intervention. This approach translate as if I don't know whats going on, give me the upstream author's default, otherwise, give me my favorite editor unless I've already specified that it doesn't work well for this application. Britton Kerin __ GNU GPL: The Source will be with you... always. On Wed, 18 Jun 2003, Bill Allombert wrote: On Wed, Jun 18, 2003 at 01:28:06AM +0100, Colin Watson wrote: On Tue, Jun 17, 2003 at 07:51:00PM -0400, Colin Walters wrote: @@ -7349,11 +7352,13 @@ /p p - Thus, every program that launches an editor or pager must - use the EDITOR or PAGER environment variable to determine - the editor or pager the user wishes to use. If these - variables are not set, the programs file/usr/bin/editor/file - and file/usr/bin/pager/file should be used, respectively. + Thus, every program without an internal preference that + launches an editor or pager must use the EDITOR or PAGER + environment variable to determine the editor or pager the + user wishes to use. If these variables are not set, the + programs file/usr/bin/editor/file + and file/usr/bin/pager/file should be used, + respectively. /p p I think this is very bad. At the moment policy says that my EDITOR and PAGER variables have priority over what random programs think is a good idea, which I think is excellent. If programs get to pick a default that overrides my EDITOR and PAGER then it all degenerates into chaos. I concurr. This will be a massive step backward providing useful default. If what you really meant was that the order is as follows: * EDITOR/PAGER * program's preferred editor or pager * /usr/bin/editor or /usr/bin/pager ... then that would be slightly better; it dilutes the effectiveness of the editor and pager alternatives, but that might not be *too* bad. It's late here so I haven't fully thought it through. It will be broken: users will get random program lauched unless they set $EDITOR/$PAGER/$BROWSER. This is not a sane default, this is much better to consistantly launch the same editor, whatever it is. User will get used to it or will set EDITOR to their liking. Nothing is more confusing that getting presented with an different editor each time. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [devel-ref] author/homepage in description
On Mon, 9 Dec 2002, Denis Barbier wrote: On Mon, Dec 09, 2002 at 01:17:28PM -0600, Adam DiCarlo wrote: [...] Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. I don't like this. The pages listed will end up being wrong half the time and google can find homepages very well and everybody knows it, so what is the point in adding this? Britton Kerin
Re: Debian-Perl-Policy and .packlist?
I second or third this or whatever. There is a bit of duplication of
information but both dpkg -L and .packlist are generated automaticly so
who cares.
Probably somebody who knows how to make official policy proposals should
propose this.
Britton Kerin
__
GNU GPL: The Source will be with you... always.
On 4 Dec 2002, Ian Zimmerman wrote:
Josip IIRC, the .packlist files contained a list of files shipped
Josip with each module. dpkg -L already provides such information for
Josip packages.
Michael Actually, the packlist keeps track of what has been installed
Michael by Perl's build system - and ExtUtils::Installed is the
Michael official perl tool of choice to query that information.
Michael Falling back to calling 'dpkg -l' means calling an external
Michael program and hardwiring a perfectly system independend script
Michael to a Debian distro (not that I'd mind that much, but
Michael still...).
Josip How about filing a bug against the Debian package that includes
Josip ExtUtils::Installed asking for it not to use information in
Josip dpkg database on Debian systems, instead of the (nonexistent)
Josip .packlist information?
At the very least, you'd need to (potentially) use _both_. Using only
the debian package info would break asking about locally installed
modules. Are such complications worth it? I think not. I agree with
Michael, the .packlist files should be included.
--
Ian Zimmerman, Oakland, California, U.S.A.
if (sizeof(signed) sizeof(unsigned) + 4) { delete this; }
GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
I don't agree at all that a half-assed man page is better than undocumented, especially if upstream has taken the trouble to provide better documentation in some other form. A minimal man page, carefully maintained, might be worthwhile. But if Colin is willing to change man to somehow figure out that a page corresponding to a binary corresponding to an installed undocumented package has been requested, and respond with appropriate pointers, I guess there is no problem. Britton On Wed, 13 Nov 2002, Chris Waters wrote: On Wed, Nov 13, 2002 at 12:22:58PM -0900, Britton wrote: Along with potential false hopes during load time, the undocumented page provides pointers to places where documentation may be found. An actual man page would do a better job of that. The point of this proposal is that people should provide man pages! Lots of people seem to think that as soon as they make a link to undocumented(7), their job is done. Well it's not! If you can create a debian/control file, you can write a simple man page that (at least) explains EXACTLY where the full documentation for this program is to be found -- not just a list of possible places to start hunting. Even a half-assed man page is better than using undocumented(7), and I don't believe there's a person in this project who can't generate a half-assed man page in about 15 minutes, given some example man pages to start with. Does that answer your reservations? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
I have some reservations about this. Along with potential false hopes during load time, the undocumented page provides pointers to places where documentation may be found. It may be irritating to people in the know, but since man is still the most widely known unix documentation interface, new users may be helped by these pointers. Britton Kerin __ GNU GPL: The Source will be with you... always. On Wed, 13 Nov 2002, Branden Robinson wrote: On Wed, Nov 13, 2002 at 12:14:50AM -0600, Manoj Srivastava wrote: There is a proposal under consideration for changing the undocumented(7) man page. The current proposal is included below; it is not yet the final form; and input of the general community is solicited. I have brought this modification to the notice of the full developer list since I think that this may impact a number of people, including users, whose views should be taken into account. Well, no one appears to have really objected. Response on -devel has been neutral to positive. I say we go with it. As a newly appointed Policy editor, I have the power to enforce my will. /me pauses for a moment, watching the waves of horror break over debian-devel :) However, since Manoj took point on this issue I'll defer to his judgement as to when the comment period should end. Unless he wants to delegate the conclusion of this matter to one of the other editors (Julian, Josip, or me). (...ah, this post was worth it just for the wicked grin I had on my face while writing it. :) ) -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius
Re: Bug#131781: debian-policy: Proposed virtual packages: mixer and mixer-x
I have the same issue with my application. I second this. Britton Kerin __ GNU GPL: The Source will be with you... always. On Thu, 31 Jan 2002, David B Harris wrote: Package: debian-policy Version: 3.5.6.0 Severity: wishlist (I'm subscribed to [EMAIL PROTECTED], no need to CC: me; As posted to debian-devel@lists.debian.org): Hey ho :) I recently started maintaining the package gqmpeg, which was orphaned by Takuo KITAME. Looking it over, one thing strikes me as particularily ugly. Specifically: [ [EMAIL PROTECTED]: ~ ]$ acs gqmpeg | grep Recommends: Recommends: xmixer | gnome-media | gom-x | gamix | mixer.app | kmix | aumix-gtk | wmmixer | asmixer Not only is that ugly and difficult to maintain, it might not even be a complete list. It will be unpleasant confirming the latter, especially. So, in accordance with virtual-package-names-list.txt, I'm starting out by sending this letter to debian-devel@lists.debian.org (to which I am of course subscribed ;), and suggesting the creation of two new virtual packages, which I believe should be in the Graphics and Multimedia section of the list, though that has no relevance to packaging itself. mixer: Utility to control the input and output levels of a sound card. Either a command-line interface or a text/console interface is required. mixer-x: Utility to control the input and output levels of a sound card. An X11-based interface is required. Myself and a few others discussed the idea of just using mixer and mixer-gui, instead of mixer-x. But, at least for gqmpeg, if the package is going to have a relationship on a GUI mixer, it should be able to declare that relationship with a specific environment. In gqmpeg's case, X11. Using mixer-gui is too broad; at least with mixer-x we leave room for mixer-fb, mixer-berlin, etc.. I'll be filing the wishlist bug against debian-policy as soon as this email is off. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should debian policy require to use debconf for postinst scripts?
On Mon, 10 Dec 2001, Mark Brown wrote: On Mon, Dec 10, 2001 at 09:22:09PM +1000, Anthony Towns wrote: And thanks to this stupid MUST thing in policy everyone's wasting their time trying to figure out how to force people to do things, instead of making sure that there's absolutely no reason why they wouldn't want to. Trouble is, when the maintainer really is being wierd there's not much you can do about it so people wind up wanting to find a big stick to use to try to get through to them. Assuming people are going to do the sensible thing doesn't always work. Inasmuch as that is true, we're doomed anyway, policy or no policy. Britton
Re: Path modification
Ok. No need to get combative. If the admin saw the package, got interested, and installed it, the message *to the admin* seems potentially useful, since PATH is fundamental and mh requires an unusual change to work at all. Since debian ships things like mh-e, which usefully wrap and simplify nmh, the potential for confusion is significant. But perhaps this is an mh-e bug. If there is no way to deliver a message or it is considered not worthwhile, fine. On Fri, 12 Jan 2001, Chris Waters wrote: On Thu, Jan 11, 2001 at 01:29:04AM -0900, Britton wrote: I don't think it would be excessively interactive for nmh to somehow give a prompt notifying the user that the package requires something that debian packages normally never need in order to work And how is it supposed to notify the users? It could possibly notify the sysadmin when the sysadmin installs the package, but that still leaves the users in the dark. Perhaps you were unaware that Gnu/Linux is a multiuser system? Mh is designed to be installed on a multiuser system without being intrusive to the users that aren't interested in it. It's a good, clean, flexible design which only confuses those who don't read documentation. And those folks are pretty much hopeless in any case. Many debian nmh users will be trying nmh for the first time because they saw the description and got interested, and won't know about this peculiarity. Then those users should try reading the documentation, rather than complaining that a package which has been working fine for twenty years on a wide variety of *NIXen doesn't meet their limited and incorrect expectations. (And the ones using tcsh should switch to a shell that *isn't* the essence of pure evil! Frankly, I'd much rather add install-time warnings to csh and tcsh than to mh.) :-) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: cleaning up our task packages
Currently we've only had two real excuses for using empty packages: for handling splits, and for tasks. It seems a little like people want a third sort, just as a collection of related packages that you generally want to install at once. This might be just an artifact of recommends not doing anything anymore, or it might be a real valid use. That is the big concern I have with the quick invention of a hierarchical task system or the like is that it seems like it would likely end up redundant with what we already have. Britton
Re: cleaning up our task packages
This sounds good to me. Also, why should the user ever see a task like devel-common, shouldn't this be essentially depended on by all the dev tasks? And Debug should be pulled in for any languages for which it includes debugging tools. In at lease some cases (SGML at least) it would seem to me to make sense to merge the dev and the use tasks. Speaking for myself, if am being lazy and want to 'do some Tcltk tasks' I want both the use and development packages by default. Britton On Thu, 7 Dec 2000, Joey Hess wrote: [ I'm dropping the -devel cc in the hope of having a useful discussion instead of 10 non-useful offtopic discussions. Blah. ] Chris Waters wrote: Ok, here's a slightly better proposal: why not simply handle the task- package namespace the same way we do virtual packages and menu entries. That way the actual text to go into policy almost writes itself, and the only challenging part of the job would be deciding on the initial tasks to seed the official list. The problem I have with this is illistrated pretty clearly by most of this thread. We introduced the concept of task packages less than a year ago. At that point everyone who was contributing had a basic idea of the purpose of task packages and how they were meant to be used, and what was appropriate for task packages. Fast forward 8 months to the present, and I'm seeing a huge number of people who don't have the slightest clue about task packages. Did they forget so soon? Did they not pay attention last winter? I don't know.. But if we just make it policy that task-foo has to be approved by debian-devel before it is allowed into debian, I have fears that in another 8 months everyone is again going to have forgotten what task packages are for, and this mailing list may be unable to approve/disapprove packages with any consistency. All right, call me pessamistic, but policy is supposed to be there to help us remember why we do things the way we do, so even if people forget, the document is there for those who remember to cluebat others with. :-) That's why I think we need at least a clear statement of what task packages are for, what is and what is not allowable, put into policy. I don't object to requiring new task packages to be approved by the debian-devel list like virtual packages, but the list will need something on which to base its decisions. So how's this: Task Packages - Any package whose name begins with `task-' is known as a task package. Task packages are intended to help a new user install a set of packages which they need to perform a specific task. Since a list of all task packages is presented during new Debian installations, task packages should only exist for common tasks for which a user may plausibly want to use a newly installed Debian system. Before a new task package is added to Debian, the new package must be discussed on the debian-devel mailing list to ensure that it meets these guidelines. The current list of approved task packages follows: ... (If we accepted this, then we'd use its procedure to discuss each of the existing task packages, add those that were accepted to the list, and file bugs on the rest.) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Origin and Bugs support
In other words, we have no way to control what baddies do with Debian. The best we can do is make it easy and convenient for goodies to do the right thing (whatever that may be). The entire discussion about trying to prevent bug report hoarding is futile and moot -- we have no control over that, and it's pointless to pretend we do. This is more likely to happen by accident, and that might be prevented.
Re: [PROPOSAL] Origin and Bugs support
Origin: Debian Bugs-To: mailto:[EMAIL PROTECTED] Which is clearly entirely reasonable and legitimate. No, it's not. If you want to make a package special instead of making it an integral part of Debian change the Origin tag. What? It comes from Debian and has an alternate bug location. What exactly is wrong with that? So what should I use for an origin tag in this case? Wouldn't having reports go to an alternate location prevent the report from going into the official bts? This happening seems to be what you are arguing against here: This was brought up before too -- Debian packages probably should not be tagged at all. Otherwise derived distributions will have to go and unset/reset this which means a full dist recompile! They can just change the /etc/dpkg/origins/debian file. Screw those packages that are actually from Debian eh? Nice hack. which I agree is a serious problem. Britton
Re: [PROPOSAL] Origin and Bugs support
On Sun, 26 Nov 2000, Chris Waters wrote: On Sun, Nov 26, 2000 at 07:39:13PM -0500, Eric Gillespie, Jr. wrote: If Debian decides that bug reports should go to Debian unless we've modified the package, that's what we'll do. We have no control over it. If evil-third-party Debian reseller decides they want the bug reports, they hack the bug reporting tools to override the fields in the packages, and viola, they hoard all the bug-reports they want. Yes, but a good system would hopefully leave them with no incentive to do so. It seems the big argument here is really over where bug reports should go first, whether the fact that modifications in some packages may cause apparent bugs in unmodified packages should cause all bug report from dists that used modified packages to be kept out of the main bts, or not, etc. Personally, I want all bugs that get filed against my packages on any debian derived system to go to the main line bts. If the reports themselves can get tagged with a 'comes-from-derived-system' flag that is great, it gives more information to bts users and helps me. In theory I will be looking at these bugs regularly, and if I can't duplicate the problem I can communicate with the vendor of the derived system. Now, if the report also automaticly goes to the vendor, I have absolutely no problem with that. In fact I would prefer it to go both places. Why should anyone have to be left out? The only problem then is that bugs may be fixed in one system, but still linger on in other tracking systems, potentially causing work duplication. The solution is to include with the report a list of all the places the problem has been reported to, so the people ultimately responsible for the package in their derived distributions know where to look to see if the problem has already been fixed. Or is the whole idea of forking bug reports considered heresy? Britton
Re: Preparing Debian for using capabilities: file ownership.
But anyway, capabilities are useable without fs support. Definitely. Some daemons like proftpd already use them. Also, keep in mind that the set of capilities differs between 2.2 and 2.4 kernels if memory serves me correctly, and people are still looking at making sure the current set is an optimal one. (Fun assignment: see which capabilities can lead to root access. It turns out to be a surprisingly large set). Well said. Capabilities add a bunch of complexity and granularity of dubious usefulness, and will almost certainly turn out to introduce masses of security holes as they get used and misused. The traditional model has the great advantages of simplicity and not offering more than it can really deliver. Also keep in mind that capabilities are based on a now-dead POSIX standard from a commitee which couldn't decide in over 10 years of work what unix security meant. I won't bother with capabilities until they get rammed down my throat, and I kind of hope debian isn't the first to do the ramming. Britton
Re: Preparing Debian for using capabilities
http://www.kernel.org/pub/linux/libs/security/linux-privs/ has some info, the README has some pointers as well. /usr/include/linux/capability.h is well commented and tells you the different capabilities that are available. Britton Kerin On Fri, 22 Sep 2000, Jonathan D. Proulx wrote: Hi, I usually just lurk here, but this discussion has peaked my curiosity... Anyone have a pointer to good info on linux and capabilities? My initial reaction to this new (to me) idea is that layering capabilities on top of ACLs is just a mess... Debian GNU/EROS anyone :) TIA, Jon -- ps http://www.eros-os.org for anyone who didn't get the last reference -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Bruce Perens and Dave Cinege, etc.
On 28 Oct 1997, Manoj Srivastava wrote: Hi, Britton == Britton [EMAIL PROTECTED] writes: Britton Good individuals will almost invariably harbor a few bad Britton individual ideas, for whatever reason. This is especially Britton true in the technical fields. The process appears to be Britton sufficiently democratic that this doesn't matter, but Britton rotation would ensure that it wouldn't. I think you may be right n the first count: the process appears to be sufficiently democratic that this doesn't matter, and we do not need to add bureaucratic overhead to aid that (what ain't broke ...) I guess the question is how much overhead would really be imposed. It does not seem to me like changing from one competent and fully informed leader (eg Bruce) to another (eg Ian) every 2 years would be too hard. The recent talk about the filesystem standard is a good examle. Ian doesn't want to go along with it in some places. I don't really know enough to say if this is good or bad, but it looks almost certain to be a sticking point, with some potential outcomes being bad (years of failure to conform, or years of living with a bad standard). Britton [...] in a way I think was bad for Debian. Dave got his back Britton up. Mayby he wouldn't have stayed anyway, but I think it was Britton a shame to lose him. He made CDs, he presumably told his Britton friends abou Debian, brought them CDs the next day, etc. There are some things I would not subject myself to just for the sake of Debian's popularity. I prefer to have a group of people Fair enough, but the reaction didn't exactly stop Dave, just the opposite in fact. And of course popularity is synonymous with survival in the end. I should note that I don't recall seeing anything particularly insulting from you Manoj, your debate has always been conducted respectfully. around that work together well enough to be conducive to the synergy that is Debian. manoj -- We Americans, we're a simple people... but piss us off, and we'll bomb your cities. Robin Williams, _Good Morning Vietnam_ Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: On Bruce Perens and Dave Cinege, etc.
On Mon, 27 Oct 1997, Glenn Amerine wrote: M == M W Blunier [EMAIL PROTECTED] writes: M On 27 Oct 1997, Manoj Srivastava wrote: What problems are term limits supposed to solve, exactly? M They prevent the voters from re-electing someone that due to M his entrenchment in the system, has more power than a freshman M would have. Greedy and self serving voters vote for the M incumbant not because is better for the larger comunity, but M because he can use the power for the people that voted for M them. What power does Bruce have that someone running against him wouldn't have? M This is especially prevelant in US politics. For example, it M would be very difficult to beat Ted Kennedy in an election, as M he has enough power from the committees he chairs and the votes M he can trade with his other cronies that it would cost his M state a lot of money if he were replaced by someone else. You just made a HUGE leap my friend. US Government and Debian are more than a tad different. (Hey Bruce, I'll vote for you if you make sure jobs get generated in my district from that Debian powered power plant ;-}). Heck, I'd vote for Bruce if he ran for President. Mayby this isn't what you were saying though. M Hopefully the members of the Debian board is not motivated by M self serving reasons, and are smarter that the typical M American. Most Americans realize they all ready have term limits. They are called elections. When it comes to US positions, sure the Incumbents have an advantage due to the money and influence they can shift around during election time. You have a pretty weak argument if you are saying this applies to Debian like it does in the US Government. What I like about the term limits idea is that they permit authority to be rotated around regularly with no hard feelings anywhere. I would feel bad voting Bruce out of office after all the work he has done. Term limits make change automatic, which is perhaps good. This is not a yes or no on Ted Kennedy, but if he was doing that bad of a job wouldn't he have been out of office a long time ago? To buy So I take it you are from Vladivodstock or some such place? your argument, the Republicans would have to be under-funded and never have been in a position of power during Ted's office. Think about it. Sorry for being off-topic, but I couldn't help it. Bruce has done a hell of a job and is now getting smashed on the Net for doing so. Look at your screen and decide if you want to be reaping the benefits of Bruce and all the other Debian developers or Bill Gates's work. If you want term limits, think about Bill, not Bruce. I don't mean it to be unpleasant or ungrateful to Bruce, just the opposite in fact. I don't like to think of any Debian volunteer stepping down after being voted out, term limits seem to me like a better idea for this reason and others. Glenn -- Glenn Amerine Inet: [EMAIL PROTECTED] Computer Systems Analyst Voice: (614)224-1336 Metropolitan Human Services CommissionFax: (614)224-6472
Re: abandoning the rules of discourse
I think you are right there is not much left to be said. However, it is comforting to note that this one ugly thread is the only I have seen in all my time on the Debian lists. Looked at in that light it's sort of reassuring. If bad threads are so incidental, I can comfortably ignore them. And while the lists are certainly not under the same protection as the press, I think censoring or limiting the availability of them is still not a good idea. If communication lines are open, you will get some odd balls, it's to be expected. Knowing that, you can account for them. On 26 Oct 1997, Manoj Srivastava wrote: Hi, I think that this topic has reached the end of it's utility (much as I like the discourse). I think we are beginning to repeat ourselves. In concluding my participation on this thread, I have this to add: a) The list is not a place where the first amendment to the US constitution holds sway; as there are other means of offering one opinion (the dissent list?). You do not, for example, have a right to be rointed on the front page of the New York times (or of any other newspaper), this is not seen as violating your first amendment rights. b) This is a group of people who have gotten together to put up the best free Linux distribution. This is a co-operative effort. Disruptive behavior prevents (or at least militates against) the primary purpose of this activity. The group has a right to insist on a modicum of civility. c) I refuse to admit that intelligent discourse is impossible without resorting to ad hominem attacks or crude language. The ill will it causes is also (in my opinion) detrimental to the espirit de corps of the project in general. d) I also think that people *are* hurt by rudeness, and worse, the whle project suffers even more from the resultant ill will. We are heer not because this is our job, we are here because we like doing so. Abuse generally is not considered to be fun. There is a threshold, and abuse me more than that, and participation shall no longer be fun. Some one remarked that Debian lost when Lars left, and yet are unwilling to do anything to prevent others from leaving because they have been insulted in this forum. How many have we lost, turned off by all the rottenness that seems to permeate the lists of late? d) If the rules of discourse mean that some freedom is lost, then chalk that up to requisite discipline. No work of any worth can be accomplished without discipline, *any* discipline is a loss of freedom; albeit 'tis often voluntary. Such limitations on the debian are not likely to destroy the freedom of speech of the free world. I would accept any loss of freedom I felt to be amply rewarded by the resulting peace and amicability ;-). If people want to practice free speech, they can write to the washington post ;-). manoj -- Wild swans take the path of the sun. Men with powers travel through space, but the wise step right out of the world, by conquering Mara and his host. 175 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: On Bruce Perens and Dave Cinege, etc.
On Mon, 27 Oct 1997, Syrus Nemat-Nasser wrote: On Mon, 27 Oct 1997, Richard G. Roberto wrote: [snip] PROPOSAL FOR TERM LIMITS I propose that all elected posts in the Debian organization be subject to the following term limits: I actually like this proposal. I have no problem with Bruce, he has done a gret job. I just don't see the point in making the process of succession so competitive. The limits need not be short. Richards other points were quite good also. So, Richard. Are you ready to commit a lot of your private time to becoming project leader for a year? Will you step to the plate and pledge away a significant portion of your life to Debian? If not, then I suggest that you retract your proposal. I don't have the time or expertise required to do Bruce's job. Do you? When and if there is a viable candidate that shows the same dedication and resposibility to the project as Bruce, then I will gladly support him or her. Until then, a proposal like this is meaningless IMHO. Well, there is Ian Jackson. I don't really know enough to decide between them myself. Thanks. Syrus. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Syrus Nemat-Nasser [EMAIL PROTECTED]UCSD Physics Dept.
Re: abandoning the rules of discourse
On 24 Oct 1997, Manoj Srivastava wrote: Hi, Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai So then here's a proposal for a policy: Kai If a list participant (who is otherwise eligible for the list, Kai like being a project member if the list is debian-private) Kai undertakes an action that seriously endangers the existence or Kai use of the list, then as an emergency measure, that individual Kai can be blocked from the list until the matter is resolved. With you so far. Kai Such an action might be posting X11 to the list, but not being Kai rude. You lost me on the last clause. Kai Yet we still want freedom of the press, don't we? Even the freedom of press has limitations put on it. One specific limitation is libel (or slander -- I can't keep them apart). Yes, but the press is free to print the opinions of radical parties. 'Animal experimentation is abhorent and should be illegal, since it is completely unethical. I hate the a-- holes who perform the experiments.' is an example of a legitimate press quote. Some people seem to feel about as strongly about the version numbering change. (Note that the above quote does not completely accurately represent my position on that particular issue.) Kai I think I accidentally stumbled upon the right word here. You Kai can't have freedom without the freedom to insult. Kai There's always a price you pay for freedom. This is part of the Kai price for free speech. Sorry, no. I do not have the freedom to kill. I do not have the freedom to punch people on the nose. I do not have freedom for assault and battery. I merely wish to extend this to verbal assault and battery on the Debian list. Of course freedom in the real world requires qualification with many social contracts. The extent of the freedom of speech is an example of debate over a particular one of these contracts. There are certainly situations in which I would prefer to be allowed to insult someone, though it certainly wouldn't be over a numbering scheme. If you deny someone freedom of expression you yourself would prefer to have under other circumstances, you are exercising censorship, which since not a mutual power is never democratic. Of course the Debian mailing lists can establish their own rules, but I for one don't think it's likely to be worth it. By your argument freedom is defined as freedom frm all laws. Thus spake Nietze. In everything, price moderation, my friend. Even for freedom. Your rights ends where my nose starts. manoj -- Remember: Silly is a state of Mind, Stupid is a way of Life. Dave Butler Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E __ I like six eggs when starting on a journey. Fried - not poached. And mind you don't break 'em. I won't eat a broken egg. -- Thorin Oakenshield
Re: * Formal call for the removal of Bruce Perens *
I would like to commend the below post as being the only one so far to adopt a peaceful tone. The other responses I've seen are vicious. As for just ignoring Dave's posts, as someone proposed after bashing Dave again, it's too late for that folks. The feedeing frezy has already happened. Dave: Although your original public complaint was certainly inflammatory, you were the first one to be insulted personnaly on the debian-user list. I think you got pretty defensive after that, which is hardly suprising. some of what you said made sense to me at least, and I think you had the good of the project at heart for all of it. I can't credit your dislike of Bruce, since I don't know much about the situation and can really only judge Bruce by what he has helped to produce, which we all like. I would hate to see you give up on Debian. Though it is perhaps unlikely now, I still hope to see reconcilliation of one sort or another delete this ugly and in my experience unique blot on the Debian project. On Sun, 26 Oct 1997, Civ Kevin F. Havener wrote: Dave, I can appreciate the fact that you don't like Bruce's handling of the project. I do like the job that Bruce is doing, however. I'll stick with Bruce until the normal time for succession comes, and probably even after that. But please, by all means continue with your plan to release an alternate distribution. It should be an interesting product. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: abandoning the rules of discourse
To the rest of the list: We've been seeing a fair amount of noise recently, whether of the kind quoted above, or miscellaneous user questions to debian-devel (of which we've had a couple recently), or whatever. I propose that if we get much more we close the debian-policy and debian-devel lists to postings from non-developers. If there is demand we can create a new list where non-developers can discuss things, but I think the project needs us to be able to talk to each other in (relative) peace and quiet. I disagree strongly with this proposition. Since there is a good chance you have all read my previous posts on closed lists, you probably alredy know why, and I won't repeat myself unless someone is interested. Ok mayby I will, in principal at least: the idae of closed lists run contrary to the very nature of free, open software. If the source is accesable, should not the discussion that went into it's creation be also? Closing lists makes it harder for people to take initiative themselves and become involved, which is what Debian and other free software projects depend on. If there should ever be a conflict of interest between developers and users (I havn't seen a clear example of this yet, and don't expect to, I'm delighted with the work the devopers have done so far), it may allow the situation to deteriorate significantly before reconcilliation can be achieved. Closed lists fuel the fears of the last item in the paranoid (or over-cautios). Britton Kerin Ian.
