Bug#139957: period at the end of short description?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony On Fri, Mar 29, 2002 at 10:28:50AM -0600, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Personally, I don't see putting stuff in policy as removing Anthony lattitude. See also http://bugs.debian.org/102213 . That has other problems. What may happen then, since policy becomes optional with a note in a README, Anthony No, policy does not become optional with a note in the Anthony README. Policy becomes optional only when what it suggests Anthony is technically wrong in the given situation. We're not here Anthony to codify random opinions, we're here to document ways of Anthony packaging that are technically _better_. Is there a difference? Who decides that the policy is wrong? If I can unilaterally decide policy is technically wrong, and say so in the README, and proceed to ignore policy, then policy is indeed optional. If, however, there are procedures in place to ensure that the opinion about the policy being technically wrong are widely held, then it would be easy enough to list the error in an non-normative errata document in the policy package/web page somewhere. What are the checks and balances proposed? Anthony If it turns out one of things we put in policy _isn't_ Anthony technically better, well, it's much better that developers Anthony do what _is_ technically better than blindly follow rules Anthony like brainless automatons. Well, I still see no reason here that contradicts the statement that this makes policy optional, and largely irrelevant when it comes to tough or controversial decisions, since no decision is likely to convince everyone, and if people can just ignore policy when they disagree with it, the cooperative infrastructure is damaged. Making policy optional,and using that to include non-technical, trivial, and unnecesary detials into policy is a stupendously bad idea. Anthony Good thing that's not the idea being talked about then, isn't it? I think it is. Anthony But by the looks of things you've already gone into Anthony defensive rhetoric mode, so there's probably still no chance Anthony of actually discussing this, so just forget I said Anthony anything. Geez. Interesting cop out. manoj -- Semper Fi, dude. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
On Sun, Mar 31, 2002 at 09:40:42AM -0600, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony No, policy does not become optional with a note in the Anthony README. Policy becomes optional only when what it suggests Anthony is technically wrong in the given situation. We're not here Anthony to codify random opinions, we're here to document ways of Anthony packaging that are technically _better_. Is there a difference? Who decides that the policy is wrong? Who decides policy's wrong right now? If I can unilaterally decide policy is technically wrong, and say so in the README, and proceed to ignore policy, then policy is indeed optional. Can you do this right now? What happens if you try? What are the checks and balances proposed? What checks and balances already exist? You do realise that saying something in policy doesn't automatically mean everyone understands it and gets it right, don't you? Take lmbench, for example, which managed to get into main in spite of a maintainer who should've noticed that its license wasn't free, and an ftpmaster who should've done likewise. It got in anyway. Now a bug report's been filed on it. If that doesn't get the appropriate resolution, we can educate the appropriate people. If that doesn't work, we can forward it to the mailing lists to get a second or third opinion. If that doesn't work, the technical committee or ftpmaster can do something about it. None of this changes. Well, I still see no reason here that contradicts the statement that this makes policy optional, and largely irrelevant when it comes to tough or controversial decisions, since no decision is likely to convince everyone, and if people can just ignore policy when they disagree with it, the cooperative infrastructure is damaged. Cooperative? There seems to be very little cooperation to be damaged. Everyone must read policy and do what it says. If they disagree with policy, rather than just doing the right thing, they must come to the policy mailing list, convince everyone that they're right, make a patch against policy that's not too specific nor too general and get some seconds, then wait a couple of weeks for it to be approved, then however much longer until a new release of policy comes out, then they can go ahead and upload their package. That sounds more like policy wonks dictating the law, and everyone else obeying. Having the policy group put in the effort to browse packages and look for exceptions, and take responsibility for fixing mistakes in policy themselves seems a lot more cooperative and in the spirit of things to me. Expecting developers to participate in the policy formulation process isn't particularly reasonable. Policy doesn't gain it's authority because it's called policy. It doesn't gain its authority because it's backed by the moral righteousness of the mighty Manoj. It doesn't even gain its authority because the DPL or release manager says so. It's authoritative because it's full of good solutions to packaging problems, and good advice on packaging issues. If one of its solutions isn't right for a particular package, or some of its advice isn't so good in some situation, that's a shame, but it's not a bug in the package. And if you want to consider it a bug in policy and go about fixing it, that's fine, but it's *your* job to go and do it, not anyone else's. Anyway. There's no chance I'm going to get through to you on this, so I should stop wasting your time or mine. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108416: Bug#139957: period at the end of short description?
[ No need to CC me, since I read -policy ] On Sat, 2002-03-30 at 17:34, Chris Waters wrote: I am uncomfortable with this view. A title (or subtitle) is capitalized the way it is because it is, more or less, a proper name. A name may be descriptive, or it may be merely evocative or suggestive, or none of the above. We want descriptive, not merely evocative or suggestive, and certainly not none of the above. I'm thinking of subtitles for technical works, not works of fiction. Taking one example from my bookshelf: Fluid Concepts and Creative Analogies: Computer Models of the Fundamental Mechanisms of Thought That's what I think of as a good, explanatory subtitle (and a creative title) for a nonfiction work. Doctor Strangelove or: How I Learned to Stop Worrying and Love the Bomb: Gentlemen, there is no fighting in the War Room! here the subtitle is definitely evocative, but not very descriptive. Right; Doctor Strangelove is a fictional work...we think ;) A package might have an official upstream subtitle (something like, Pathologically Eclectic Rubbish Lister), Well, in this case I don't think of that as a subtitle at all, but just the expansion of the acronym, which for a lot of acronyms isn't very enlightening at all. and that's probably not what we want. We want a short description. Really we do. So, I think that's what we should ask for. I think we're talking about the same thing, really. A subtitle for a technical work should fit your (short) description of a short description¹. More practically, as Branden points out, it's easier to add capitalization in a display program than it is to take it away. To add capitalization, you merely need to filter a handful of small words that don't get capitalized. To take away capitalization, you need to know every proper name and every acronym that might be used in a description (because these shouldn't get de-capitalized). Well, I guess it looks like we've come to a rough consensus on the matter of the period, but not on the capitalization. I guess this is to be expected, looking at the statistics from the Packages file. Maybe we should just defer this question until someone can come up with a new argument. Personally, if it was clear that there was a 50% majority either way, I would just go with the majority. Thinking about this has inspired me to come up with an official subtitle for WMRack (which I'm currently upstream for): The Wonderful, Magical Rack of Sound Bytes. I think it's a fine subtitle, but I do not think it would be an appropriate short description. I hope you all agree. I agree that it would not be an appropriate short description, but I don't think it fulfills the explanatory role of a subtitle very well. Actually, you aren't too far from making it the expansion of WMRack as an acronym; e.g. Wonderful, Magical, Real Accoustic CD Kit. ¹ :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108416: Bug#139957: period at the end of short description?
On Sun, Mar 31, 2002 at 01:39:22AM -0500, Colin Walters wrote: I'm thinking of subtitles for technical works, not works of fiction. I'm not sure programs necessarily fit in the former category. What about games? I've been messing with dosemu lately, trying to get some old games up, so I've got on my desk here: Masters of Orion II: Battle at Antares, and Dune II: The Building of A Dynasty. Taking one example from my bookshelf: I'm not saying that subtitles can't be descriptive, I'm saying that they're not necessarily descriptive. That's not their primary role. Consider: Homicide for Dummies: A Reference for the Rest of Us. Anyway, as the Dune II example shows, even professional commercial publishers don't always follow the rules for capitalization in subtitles. :) Anyway, I have the feeling that this dead horse has learned all he's gonna, so I guess I'll stop flogging him now. cheers -- 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#108416: Bug#139957: period at the end of short description?
On Sat, Mar 30, 2002 at 02:26:21AM -0500, Colin Walters wrote: [1] Interestingly enough, '-' was chosen for Debian package names instead of '_'; I would guess this is becuase a number of Debian's original founders and policy writers had some influence from Lisp. Or maybe they just realized it's easier to type :) I suspect it's just to free up '_' as a stronger separator, for example in package filenames. I personally always prefer '-' over '_' if it is available, and this might be the majority view. All languages I can think of that use '_' as a separator do so because '-' is already taken as an operator. I guess a statistical analysis of unix filenames might show which separator is the most popular :-) Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
On Fri, 2002-03-29 at 11:51, Manoj Srivastava wrote: Chris == Chris Waters [EMAIL PROTECTED] writes: Chris I'd rather have this be a guideline than a rule. So, I'm not sure Chris policy is the right place. (Sure wish we had someplace else where Chris guidelines could go.) But if it does go in policy, I think should Chris might be too strong. I would have less objection were this couched as a ``recommends'' rather than a should rule, Ok, how about the attached patch? I didn't couch it as a footnote because I think it fits in with the rest of the recommendations there. Personally, I'm still relatively undecided on the capitalization issue. But after manually reading about 50 entries in the Packages file, things definitely seem to be in favor of capitalizing, so I went that way. And it does fit in with the subtitle analogy. given that this is a purely subjective, aesthetic view, with little technical relevance. Even if all those were true (I disagree that it's purely subjective), it is still one of those things (however minor) which reflect on the quality of Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#108416: Bug#139957: period at the end of short description?
On Fri, 2002-03-29 at 14:18, Joey Hess wrote: But, we don't upper-case a package title either so this analogy doesn't hold up well for capitalization. I would argue that this is because our package names have a dual role; they are processed by both machine and by humans. They're a lot like program filenames; Unix culture says they should be lowercase, should use a separator[1] character instead of a space, etc. But just because our titles are constrained doesn't mean our subtitles should be. [1] Interestingly enough, '-' was chosen for Debian package names instead of '_'; I would guess this is becuase a number of Debian's original founders and policy writers had some influence from Lisp. Or maybe they just realized it's easier to type :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
On Sat, 2002-03-30 at 01:52, Colin Walters wrote: On Fri, 2002-03-29 at 11:51, Manoj Srivastava wrote: Chris == Chris Waters [EMAIL PROTECTED] writes: Chris I'd rather have this be a guideline than a rule. So, I'm not sure Chris policy is the right place. (Sure wish we had someplace else where Chris guidelines could go.) But if it does go in policy, I think should Chris might be too strong. I would have less objection were this couched as a ``recommends'' rather than a should rule, Ok, how about the attached patch? Siigh. cd /tmp/ diff -u -L /usr/share/doc/debian-policy/policy.sgml.gz -L /tmp/policy.new.sgml /tmp/jka-com14265Qx /tmp/policy.new.sgml --- /usr/share/doc/debian-policy/policy.sgml.gz +++ /tmp/policy.new.sgml @@ -2392,12 +2392,17 @@ conflicts have been declared. /p - sect1headingNotes about writing descriptions + sect1headingRecommendations for writing descriptions /heading - + p - The single line synopsis should be kept brief - certainly - under 80 characters. + The description begins with a single line synopsis. The + purpose of this line is much like that of a subtitle for a + book; it should concisely describe (in under 80 + characters) what the package is. It is recommended that + the first letter in the synopsis not be capitalized, and + that it not end in a period, unless this would occur + naturally because of the presence of e.g. acronyms. /p p Diff finished at Sat Mar 30 01:40:02
Bug#108416: Bug#139957: period at the end of short description?
Note that whatever we decide on, I'll probably have to change something, as most of my packages are adopted, and have little or no consistency in how their descriptions are written. I think this allows me to be fairly unbiased, as I can't really argue for the way my packages currently are, just in order to avoid the need to change them. On Thu, Mar 28, 2002 at 09:06:04PM -0500, Colin Walters wrote: To make up for this (in addition to the fact that I'm working on #134106 at the moment :) ), I'd like to add something new to the discussion. I assert that the short descriptions are not titles nor sentence fragments per se; rather they are subtitles, like for a book. I am uncomfortable with this view. A title (or subtitle) is capitalized the way it is because it is, more or less, a proper name. A name may be descriptive, or it may be merely evocative or suggestive, or none of the above. We want descriptive, not merely evocative or suggestive, and certainly not none of the above. Doctor Strangelove or: How I Learned to Stop Worrying and Love the Bomb: here the subtitle is definitely evocative, but not very descriptive. A package might have an official upstream subtitle (something like, Pathologically Eclectic Rubbish Lister), and that's probably not what we want. We want a short description. Really we do. So, I think that's what we should ask for. Most short descriptions follow the template: packagename is a(n) short-description That's not the rule subtitles follow, because titles (sub or otherwise) are names, not (necessarily) descriptions. More practically, as Branden points out, it's easier to add capitalization in a display program than it is to take it away. To add capitalization, you merely need to filter a handful of small words that don't get capitalized. To take away capitalization, you need to know every proper name and every acronym that might be used in a description (because these shouldn't get de-capitalized). So, to summarize, treating the short description as a sentence fragment (or, my preference, as a noun clause) is both more correct (IMO), and results in a more flexible system. Thinking about this has inspired me to come up with an official subtitle for WMRack (which I'm currently upstream for): The Wonderful, Magical Rack of Sound Bytes. I think it's a fine subtitle, but I do not think it would be an appropriate short description. I hope you all agree. cheers -- 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]
Bug#108416: Bug#139957: period at the end of short description?
severity 139957 wishlist merge 108416 139957 thanks On Thu, 2002-03-28 at 12:49, Branden Robinson wrote: We went over this in the list archives the last time the issue came up and Manoj planted his feet. Erk. I apologize for not searching the list archives and seeing #108416. To make up for this (in addition to the fact that I'm working on #134106 at the moment :) ), I'd like to add something new to the discussion. I assert that the short descriptions are not titles nor sentence fragments per se; rather they are subtitles, like for a book. A package name itself is analogous to a book title. Titles often have clever and/or obscure names, and it might not be obvious at first glance what the package does merely from its title (name); e.g. arch or emacs. The point of a book subtitle is to clarify exactly what the subject matter of the book is. Analogously, for programs the subtitle should clarify exactly what it is that the program does. And if one looks at book subtitles, they don't end in a period. Also, the first letter is usually captialized. 2) It's possible to give the ucfirst and period at end crowd what they want via a package browsing interface. This argument is somewhat convincing, but the synopsis line is meant for human consumption in the first place; if it's failing in that, even in a small way, then I think something is wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 01:10:14AM -0500, Colin Walters wrote: + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). I'd rather have this be a guideline than a rule. So, I'm not sure policy is the right place. (Sure wish we had someplace else where guidelines could go.) But if it does go in policy, I think should might be too strong. I'd rather have it specify a noun clause instead of a sentence fragment (if we're going to specify anything). I agree about the full stop. (Although I still think should might be too strong.) If we're going to discuss leading caps or not, I agree with Branden: not unless it would be capitalized for other reasons (i.e. GNOME). Maybe we can make it a footnote. (Footnotes aren't normative, are they?) -- 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]
Bug#139957: period at the end of short description?
Chris == Chris Waters [EMAIL PROTECTED] writes: Chris I'd rather have this be a guideline than a rule. So, I'm not sure Chris policy is the right place. (Sure wish we had someplace else where Chris guidelines could go.) But if it does go in policy, I think should Chris might be too strong. I would have less objection were this couched as a ``recommends'' rather than a should rule, given that this is a purely subjective, aesthetic view, with little technical relevance. Chris If we're going to discuss leading caps or not, I agree with Branden: Chris not unless it would be capitalized for other reasons (i.e. GNOME). If we are going to bloat policy like this, the subtitle analogy that Colin used, in my _opinion_, is convincing. Chris Maybe we can make it a footnote. (Footnotes aren't normative, are Chris they?) They are not part of policy, no. I would actually be in favour of adding the convention about capitalization and periods as a footnote, complete with the sub title analogy. manoj -- Well, it's garish, ugly, and derelicts have used it for a toilet. The rides are dilapidated to the point of being lethal, and could easily maim or kill innocent little children. Oh, so you don't like it? Don't like it? I'm CRAZY for it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Fri, Mar 29, 2002 at 10:28:50AM -0600, Manoj Srivastava wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Personally, I don't see putting stuff in policy as removing Anthony lattitude. See also http://bugs.debian.org/102213 . That has other problems. What may happen then, since policy becomes optional with a note in a README, No, policy does not become optional with a note in the README. Policy becomes optional only when what it suggests is technically wrong in the given situation. We're not here to codify random opinions, we're here to document ways of packaging that are technically _better_. If it turns out one of things we put in policy _isn't_ technically better, well, it's much better that developers do what _is_ technically better than blindly follow rules like brainless automatons. Making policy optional,and using that to include non-technical, trivial, and unnecesary detials into policy is a stupendously bad idea. Good thing that's not the idea being talked about then, isn't it? Anthony Good advice on packaging issues is always helpful, and Anthony afaict, policy is the best place for it. The I beg to differ. Policy is not a HOWTO manual. Policy is a set of rules that we need to follow to allow integration. Actually, it's the policy requirements for the Debian GNU/Linux distribution, and includes design issues, and technical requirements of packages. Integration issues aren't the sole or even necessarily the primary subject matter. The contents of /usr/share/doc/foo/copyright aren't integration issues, eg, but they are policy issues. Why not go ahead and put into policy indentation rules? Because indentation style doesn't affect users. How about variable naming conventions? Or insisting on everyone using dbs+debhelper, since it is evident that debhelper at least is wildly popular and debhelper+dbs cover vast majority of packages? Likewise. Short descriptions, on the other hand, do affect users. But by the looks of things you've already gone into defensive rhetoric mode, so there's probably still no chance of actually discussing this, so just forget I said anything. Geez. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Vote [1] Bdale! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#108416: Bug#139957: period at the end of short description?
Colin Walters wrote: And if one looks at book subtitles, they don't end in a period. Also, the first letter is usually captialized. They generally follow the same capitalization conventions used for book titles, yes[1] (all words except the unimportant ones). But, we don't upper-case a package title either so this analogy doesn't hold up well for capitalization. -- see shy jo [1] Random sampling of all books I've read with subtitles that I bothered to record in the past 5 years, anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
Hmm. I seem to be a minority of one when it comes to thinking that some latitude could be left to developer in deciding about periods in short descriptions. But loot at the people for the idea of greater control: the luminaries list: Josip Rodin, Joey Hess, Colin Walters, Anthony Towns, Branden Robinson. Who am I, then, to stand in the way of greater control? I hereby withdraw the formal objection, though I am still opposed to adding what I consider to be unnecesary implemetation details to policy. manoj -- If you weren't my teacher, I'd think you just deleted all my files. an anonymous UCB CS student, to an instructor who had typed rm -i * to get rid of a file named -f on a Unix system. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
On Wed, 2002-03-27 at 21:19, Joey Hess wrote: I think the main case would be a short description where someone has managed to cram two complete sentences in. No I cannot think of one offhand. Do we really want to allow people to do such things? Here is my annotated grep: [EMAIL PROTECTED] egrep '^Description.+\. .+\.' /var/lib/dpkg/available Description: mysql database common files (e.g. /etc/mysql/my.cnf) False positive. Description: The GNU wdiff utility. Compares two files word by word. This package already violates policy because it has its name in the synopsis line. I would instead write: The GNU utility for comparing two files word by word Description: XForms mail user agent. Is transitioning into Archimedes currently. An XForms-based mail user agent, soon to be named Archimedes Description: ad! BBS. A perl based bbs or easy menu system. Again, just remove the name (and the trailing period). Description: Chess In Lisp. A library for cmucl. A Lisp chess library for cmucl Description: Spanish fortune cookies. Offensive section. Spanish fortune cookies (offensive) Description: The perl data language. Perl extensions for numerics. Perl extensions for numeric calculation Description: Sound module editor/player. Supports .xm modules, .xi instruments. Sound module editor/player which supports .xm modules and .xi instruments Description: Perl interface to the uulib library (a.k.a. uudeview/uuenview). False positive. Description: /bin/login replacement with RADIUS. Header file and link lib. What to do about library packages is still somewhat up in the air, I think. I personally like the approach of adding a parenthetical. /bin/login replacement with RADIUS authentication (development files) Description: Control ieee1394 audio/video devices. (Development files.) Control ieee1394 audio/video devices (development files) Description: Transitional package. Can be removed. A transitional package, which can be safely removed Description: Command line image gallery generator. It also makes thumbnails. Command line image gallery generator; can also make thumbnails Description: Maps for the crossfire game. Needed only with the server. Maps for the crossfire game; needed for the server only Or just drop the needed for the server only part; this is something that should really be part of the long description. Description: /bin/login replacement with RADIUS. Shared lib to used by programs. /bin/login replacement with RADIUS authentication (shared library) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Thu, Mar 28, 2002 at 12:06:40AM -0600, Manoj Srivastava wrote: I seem to be a minority of one when it comes to thinking that some latitude could be left to developer in deciding about periods in short descriptions. Personally, I don't see putting stuff in policy as removing lattitude. See also http://bugs.debian.org/102213 . I hereby withdraw the formal objection, though I am still opposed to adding what I consider to be unnecesary implemetation details to policy. Good advice on packaging issues is always helpful, and afaict, policy is the best place for it. The developers-reference subject matter is broader Debian issues beyond package contents (eg, mailing lists, how to upload, when to NMU, etc); the packaging-manual used to be detailed low-level documentation on what will be accepted by dpkg, rather than Debian. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey pgpZAoEeAx5rg.pgp Description: PGP signature
Bug#139957: period at the end of short description?
On Wed, Mar 27, 2002 at 10:51:24PM -0500, Colin Walters wrote: Branden, do you have an argument for why capitalization should be discouraged? We went over this in the list archives the last time the issue came up and Manoj planted his feet. My reasons are two: 1) I think it's bad style to capitalize something that isn't a title or a sentence. 2) It's possible to give the ucfirst and period at end crowd what they want via a package browsing interface. You just manipulate the package description string that you are given. The reverse transformation is not reliably possible. Consider the following hypothetical package description: Description: GNOME-based game; you're an ambulance driver and you've got to keep your patients from arriving at the hospital D.O.A. Now, needless to say, the above example is way too long, but you get the idea. Would you want this to end up as: Description: gNOME-based game; you're an ambulance driver and you've got to keep your patients from arriving at the hospital D.O.A? The leading mandatory capital letter and trailing period are noise, not signal. Thus, they should be added where noise isn't a problem. -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpgPZ6jnDmBb.pgp Description: PGP signature
Re: Bug#139957: period at the end of short description?
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey I can't second this because I think there can be cases where it makes Joey sense to put a complete sentence in a short description, and there is no Joey reason to outright prohibit those cases. I would be much happier with Joey something that said, If your short description is not a complete Joey sentence, do not end it with a period.. Does every little picayune detail have to have the weight6 of policy? manoj -- Live long and prosper. Spock, Amok Time, stardate 3372.7 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Why should the short description not be a full sentence? Anthony Because making it just a phrase is briefer and conveys the Anthony same information. There's a lot of stuff to read through Anthony when looking through dselect, and the more we can minimise Anthony that the better. And a period somehow fogs up your brain? Anthony IMO, what policy is is a means of recording the current Anthony consensus on packaging issues amongst developers. It's Anthony necessary to have that written down somewhere rather than in Anthony everyone's heads, since there's so much of it and it's too Anthony easy to forget. Nearly 20% of the packages do not conform to this so called consensus. And the developers reference is a far better place to put these kinds of things than policy itself. Policy is also not a stick to shake at developers after they close bugs that you reported on the issue. Anthony No, it's a tool to resolve confusion amongst developers: Anthony Descriptions should be short and not include useless words Anthony or Descriptions should make grammatically correct Anthony sentences. I doubt that a period causes much confusion. We leave trivial things not required for integration up to the individual developer. Making policy a strait jacket by constraining developers to every little detail of packaging is just making the task more onerous, for little return. Anthony You want to inflate this to GR? Don't you have more useful Anthony things you could be doing? Quite so. Responding to silly policy proposals comes low in the list. Don't you have better things to do than make it possible to file 2000 serious bugs against packages? manoj -- Perl will always provide the null. Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Wed, Mar 27, 2002 at 11:58:48AM -0600, Manoj Srivastava wrote: make it possible to file 2000 serious bugs against packages? The patch in the bug said should and should not only... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Wed, Mar 27, 2002 at 11:58:48AM -0600, Manoj Srivastava wrote: Anthony IMO, what policy is is a means of recording the current Anthony consensus on packaging issues amongst developers. It's Anthony necessary to have that written down somewhere rather than in Anthony everyone's heads, since there's so much of it and it's too Anthony easy to forget. Nearly 20% of the packages do not conform to this so called consensus. Ah, so over 80% do. If that's not a consensus, then my grounds for fearing that you will attempt to impose some sort of insanely high supermajority requirement upon amendment of the Social Contract or DFSG are, perhaps, not so ill-founded. Even a 4:1 supermajority is too low. Amazing. -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | pgpLfY0lkWcbU.pgp Description: PGP signature
Re: Bug#139957: period at the end of short description?
On Wed, 2002-03-27 at 00:41, Joey Hess wrote: I can't second this because I think there can be cases where it makes sense to put a complete sentence in a short description, and there is no reason to outright prohibit those cases. I would be much happier with something that said, If your short description is not a complete sentence, do not end it with a period.. Can you give some examples? I think you're probably right, but if we can restructure those cases such that they don't need to be a full sentence, then all the better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
Colin Walters wrote: On Wed, 2002-03-27 at 00:41, Joey Hess wrote: I can't second this because I think there can be cases where it makes sense to put a complete sentence in a short description, and there is no reason to outright prohibit those cases. I would be much happier with something that said, If your short description is not a complete sentence, do not end it with a period.. Can you give some examples? I think you're probably right, but if we can restructure those cases such that they don't need to be a full sentence, then all the better. I think the main case would be a short description where someone has managed to cram two complete sentences in. No I cannot think of one offhand. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#139957: period at the end of short description?
On Tue, 2002-03-26 at 11:41, Branden Robinson wrote:
I second this.
Thanks (and to Josip as well).
We should also discourage capitalization of the first
letter in a package description. (I.e., don't make it a capital letter
if it wouldn't be one in the middle of a sentence.)
I am rather neutral on this one. And from a somewhat brute-force
analysis of the Packages file on my system, there isn't a clear
consensus:
[EMAIL PROTECTED] perl -le '$|=1; open(F, q(/usr/share/dict/words)); my
@words = map {chomp $_; $_} F; while () { if (/^Description: (\w+)/) { my
$word = $1; if ($word =~ /^[A-Z]/ and grep {$_ eq lc($word)} @words) { print
qq($word);}}};' /var/lib/dpkg/available /tmp/capitalized-words
[EMAIL PROTECTED] wc /tmp/capitalized-words =(egrep '^Description'
/var/lib/dpkg/available)
47144714 28867 /tmp/capitalized-words
8596 60773 465658 /tmp/zshhwOH43
Granted, this is not a very scientific statistical sampling, as a lot of
the words which begin with a capital letter are also an acronym or a
proper noun; e.g. GNU, GNOME, X, LaTeX...
Branden, do you have an argument for why capitalization should be
discouraged?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
Package: debian-policy Severity: minor Tags: patch Hi, this is not a major problem, but I'd like to see a bit more consistency among the package descriptions. The attached patch should be self-explanatory. A quick analysis of the Packages file suggests there is already a rough consensus in agreement. This is obviously a post-woody thing; we should put it off until then. cd /tmp/ diff -u -L /usr/share/doc/debian-policy/policy.sgml.gz -L /tmp/policy.sgml.new /tmp/jka-com6962AcG /tmp/policy.sgml.new --- /usr/share/doc/debian-policy/policy.sgml.gz +++ /tmp/policy.sgml.new @@ -2397,7 +2397,9 @@ p The single line synopsis should be kept brief - certainly - under 80 characters. + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). /p p Diff finished at Tue Mar 26 01:07:12
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 01:10:14AM -0500, Colin Walters wrote: Package: debian-policy Severity: minor Tags: patch Hi, this is not a major problem, but I'd like to see a bit more consistency among the package descriptions. The attached patch should be self-explanatory. A quick analysis of the Packages file suggests there is already a rough consensus in agreement. --- /usr/share/doc/debian-policy/policy.sgml.gz +++ /tmp/policy.sgml.new The single line synopsis should be kept brief - certainly - under 80 characters. + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). I second this. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
Colin == Colin Walters [EMAIL PROTECTED] writes: Colin Hi, this is not a major problem, but I'd like to see a bit more Colin consistency among the package descriptions. The attached patch should Colin be self-explanatory. A quick analysis of the Packages file suggests Colin there is already a rough consensus in agreement. I formally object to this. Why should the short description not be a full sentence? Why are we adding useless bloat to policy? This does not seem appropriate for policy anyway (there is no technical reason for not including a period, nor has there been any justification for doing it this way). Even if it were justified (I fail to see how), policy is not a best practices document. Policy is also not a stick to shake at developers after they close bugs that you reported on the issue. It is equally likely that the better thing to do would be to require all short descriptions to have a ending period (indeed, this shall be my counter GR). manoj irritated -- Your aim is high and to the right. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 01:10:14AM -0500, Colin Walters wrote: cd /tmp/ diff -u -L /usr/share/doc/debian-policy/policy.sgml.gz -L /tmp/policy.sgml.new /tmp/jka-com6962AcG /tmp/policy.sgml.new --- /usr/share/doc/debian-policy/policy.sgml.gz +++ /tmp/policy.sgml.new @@ -2397,7 +2397,9 @@ p The single line synopsis should be kept brief - certainly - under 80 characters. + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). /p p I second this. We should also discourage capitalization of the first letter in a package description. (I.e., don't make it a capital letter if it wouldn't be one in the middle of a sentence.) -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | pgpH4QjJI4nE3.pgp Description: PGP signature
Bug#139957: period at the end of short description?
On Tue, Mar 26, 2002 at 08:43:02AM -0600, Manoj Srivastava wrote: Colin == Colin Walters [EMAIL PROTECTED] writes: Colin Hi, this is not a major problem, but I'd like to see a bit more Colin consistency among the package descriptions. The attached patch should Colin be self-explanatory. A quick analysis of the Packages file suggests Colin there is already a rough consensus in agreement. I formally object to this. Yay. Woo. Why should the short description not be a full sentence? Because making it just a phrase is briefer and conveys the same information. There's a lot of stuff to read through when looking through dselect, and the more we can minimise that the better. Why are we adding useless bloat to policy? This does not seem appropriate for policy anyway (there is no technical reason for not including a period, nor has there been any justification for doing it this way). Even if it were justified (I fail to see how), policy is not a best practices document. Says who? Section 5.7.1 seems pretty much `best practices for writing descriptions', eg. IMO, what policy is is a means of recording the current consensus on packaging issues amongst developers. It's necessary to have that written down somewhere rather than in everyone's heads, since there's so much of it and it's too easy to forget. Policy is also not a stick to shake at developers after they close bugs that you reported on the issue. No, it's a tool to resolve confusion amongst developers: Descriptions should be short and not include useless words or Descriptions should make grammatically correct sentences. It is equally likely that the better thing to do would be to require all short descriptions to have a ending period (indeed, this shall be my counter GR). You want to inflate this to GR? Don't you have more useful things you could be doing? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey pgpmPozu62wGF.pgp Description: PGP signature
Bug#139957: period at the end of short description?
Colin Walters wrote: p The single line synopsis should be kept brief - certainly - under 80 characters. + under 80 characters. This should be a sentence fragment + which summarizes the key features provided by the package. + It should not end in a full stop (`.'). /p I can't second this because I think there can be cases where it makes sense to put a complete sentence in a short description, and there is no reason to outright prohibit those cases. I would be much happier with something that said, If your short description is not a complete sentence, do not end it with a period.. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
