Re: Must and should again
On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote: On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote: So we no longer accept uploads of packages that don't have manpages for all their binaries? OK, let's take this example then. At the moment it's only a should. Why can't we say that, from now on, we will not accept uploads which fail this? My suggestion is: change should to must in policy, and give packages some time to migrate (eg., one year) before starting to do NMUs. Suppose we do. First, what benefit does this provide to the user who gets a copy of the new woody release in, say, six months on CD. Can they rely on every binary having a manpage? No, because it's not a real must. Second, what happens to, say, security NMUs of packages without manpages? Do they get rejected out of hand, because of RC bugs? Or do the security team have to write manpages as well as do the fix and release advisories? What about NMUs to fix real RC bugs, like the app-defaults thing? Do they have to write manpages as well as fix the bugs as well? What about maintainers who just want to fix normal bugs promptly? Do I have to, say, write manpages for ping6 and traceroute6 and tracepath and tracepath6 when I make an upload of iputils.dsc to set its Maintainer: to debian-qa? This sort of requirement seems to erect more barriers in the way of improving a package's quality, without even offering any assurance that the overall quality of packages will particularly improve. In order to fix the typo in this bug, you must read the current policy document, add a manpage, move to /usr/share/doc, add a symlink from /usr/doc, update your description, contact the translation team to make sure your package's description and manpages are translated into French, German and Japanese, register all your documents with doc-base, register your programs with update-menus, ensure lintian doesn't register any errors, and then you may upload. You can't dictate that maintainers will be motivated to fix their packages no matter how much you might want them to. It's a mistake to try. This is probably a highly effective way of doing away with undocumented.7 and ensuring that all binaries have proper manpages without imposing the burden of either large scale NMUs or pulling lots of packages. It seems more like a highly effective way to make maintainers get sick of bothering, and leave lots of packages unorphaned but also unmaintained, to me. If you want a truly effective way of doing away with undocumented.7, get people to right manpages and submit them to the BTS. Someone has to do the work. The maintainer's already indicated s/he isn't that interested in writing manpages by the very fact that s/he hasn't written any. If you want manpages as badly as you seem to: *you* write them. Recently there's been a flamewar in a newsgroup I like to read about welfare and government mandated minimum standards of living. In it, one of the participants (who was against it) accused another (who was for, obviously) of being in it for the power, the argument was something like whoever is in control of ensuring a minimum standard of living gets to control both the poor (by being their major source of income) and the rich (by controlling most of their income). There seems to be something similar going on here: policy wonks grabing power over maintainers by arbitrarily deciding whether their packages are acceptable or not, and using that power to satisfy their own goals whether anyone else likes it or not. Sure, they're doing it for their own good, but that doesn't make it right. Maybe the entire idea of MUST is wrong, and -policy can't be trusted with fairly and reasonably deciding what's acceptable for release and what's not. - we don't file RC bugs on new requirements until we decide that it is necessary and that we are realistically able to fix any packages with the issue outstanding in a reasonable length of time Indeed. We can do this right now by making them recommendations (should) instead of requirements (must), and update them later if it's appropriate. So one day you have a minor bug report against your package, the next day it becomes an RC bug report with the threat of your package being pulled. the next day ? One day you have a minor bug report against your package. Three months later, while every other maintainer except you has gone and done stuff about it, and a policy proposal listing the packages still violating the guideline (yours and a handful of others), and saying why consistency in this area is crucially important, passes, the bug gets upgraded to serious, and someone offers to NMU for you. I have another suggestion. Let's get rid of the Standards-Version field in debian/control and insist all packages must match current policy. No and yes. I think the Standards-Version is good when we look at a package to determine what the state of policy was when it was last
Re: .text or .txt
On Thu, 12 Apr 2001 14:06:22 -0500 Branden Robinson [EMAIL PROTECTED] wrote: On Thu, Apr 12, 2001 at 11:55:51AM +0100, Julian Gilbey wrote: Most of the text versions of manuals on the ftp site seem to use the .txt suffix. All files generated from the policy package use .text, though. Would there be any objections to moving from .text to .txt for policy? I anti-object. .txt, while evocative of a well-known old operating system's extremely limited filesystem, is about as close to a universal signifier for a plain text file as exists. Deviating from that seems a bit silly. I'd frankly prefer some sort of strong typing mechanism on the filesystem (like in MacOS), but that wouldn't be altogether helpful here. Just a thought I had when I read this... Regards, Alex.
Re: .text or .txt
* Alexander Hvostov [EMAIL PROTECTED] [010412 22:47]: I'd frankly prefer some sort of strong typing mechanism on the filesystem (like in MacOS), but that wouldn't be altogether helpful here. Just a thought I had when I read this... jerk Why don't you compile a list of the worst features of all operating systems and request them as features? /jerk :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: .text or .txt
On Thu, 12 Apr 2001 23:00:22 -0700 Seth Arnold [EMAIL PROTECTED] wrote: * Alexander Hvostov [EMAIL PROTECTED] [010412 22:47]: I'd frankly prefer some sort of strong typing mechanism on the filesystem (like in MacOS), but that wouldn't be altogether helpful here. Just a thought I had when I read this... jerk Why don't you compile a list of the worst features of all operating systems and request them as features? /jerk :) Filesystem-level strong typing is bad? Please explain! This is something I probably ought to know. Regards, Alex.
Re: Must and should again
On Fri, Apr 13, 2001 at 03:20:50PM +1000, Anthony Towns wrote: So we no longer accept uploads of packages that don't have manpages for all their binaries? OK, let's take this example then. At the moment it's only a should. Why can't we say that, from now on, we will not accept uploads which fail this? My suggestion is: change should to must in policy, and give packages some time to migrate (eg., one year) before starting to do NMUs. Suppose we do. First, what benefit does this provide to the user who gets a copy of the new woody release in, say, six months on CD. Can they rely on every binary having a manpage? No, because it's not a real must. The problem you seem to see is that users will not realise that the meaning of policy directives has changed. I think this is an issue that could be fairly easily resolved by explaining the new system in the policy document itself. Then anyone who actually reads policy would see that the system has changed. This will not have any effect on woody; I'm looking at woody+1 to be realistic. So let's say we implement this after woody is released. Can a user rely on every binary in woody+1 having a manpage? No, but they can't now either because it's only a should. At present, lots of binaries don't have manpages. My suggestion would ensure that by the time woody+1 is released, *almost* every binary will have a manpage. And by the time woody+2 is released, *every* binary will (and RC bug if it doesn't). That means that most users will be significantly better off, even by the time woody+1 is released. At present, there is no incentive for maintainers to add missing manpages; with this system, there would be a very big incentive (your package update doesn't get into unstable otherwise). Second, what happens to, say, security NMUs of packages without manpages? Do they get rejected out of hand, because of RC bugs? Or do the security team have to write manpages as well as do the fix and release advisories? What about NMUs to fix real RC bugs, like the app-defaults thing? Do they have to write manpages as well as fix the bugs as well? What about maintainers who just want to fix normal bugs promptly? Do I have to, say, write manpages for ping6 and traceroute6 and tracepath and tracepath6 when I make an upload of iputils.dsc to set its Maintainer: to debian-qa? As I said when discussing this originally: (1) NMUs may be exempt from these rules for the very reasons you point out. (2) Setting its maintainer to [EMAIL PROTECTED] would be an example of an NMU. (3) Maintainers who just want to fix normal bugs promptly *will* have to also make sure that their packages are policy-compliant before they upload them. Otherwise we are back to the current setup where policy is ignored by a significant number of maintainers. This sort of requirement seems to erect more barriers in the way of improving a package's quality, without even offering any assurance that the overall quality of packages will particularly improve. This sort of requirement means that packages will overall tend to be relatively up-to-date with respect to policy and that policy will have to be noted by maintainers. I certainly agree with you that policy compliance makes no assurances of package quality. That is not the job of policy. Policy's primary job is to ensure that the packages themselves have a consistent interface and design, and that they work well together. It does not particularly try to do anything about the quality of the software itself. Either policy is being written by a small group of maintainers sitting in an ivory tower with nothing better to do with their time, and has no relevance to the rest of the project, or policy is an important tool for ensuring that there is a modicum of consistency between packages. The latter is the reason why Debian is so much better than many other distros, as Chris Rutter once told a visitor to our stand: we require packages to comply to quite well defined specs. Only the truth is that we don't, really. Maintainers who want to follow policy do, and those who don't, don't. And there's nothing encouraging them to do so. Incidentally, the reason that app-defaults required RC bugs and NMUs was not because policy said so, but because things would badly break otherwise. That's why policy had to be modified so rapidly on this point. In order to fix the typo in this bug, you must read the current policy document, add a manpage, move to /usr/share/doc, add a symlink from /usr/doc, update your description, contact the translation team to make sure your package's description and manpages are translated into French, German and Japanese, register all your documents with doc-base, register your programs with update-menus, ensure lintian doesn't register any errors, and then you may upload. - You must check the current upgrading-checklist to check whether there's anything which might
Re: Must and should again
On Fri, Apr 13, 2001 at 11:29:54AM +0100, Julian Gilbey wrote: On Fri, Apr 13, 2001 at 03:20:50PM +1000, Anthony Towns wrote: Suppose we do. First, what benefit does this provide to the user who gets a copy of the new woody release in, say, six months on CD. Can they rely on every binary having a manpage? No, because it's not a real must. The problem you seem to see is that users will not realise that the meaning of policy directives has changed. No, the problem is that it doesn't provide any benefits to the user over having a should. A user buys a Debian woody (or woody+1, or whatever) CD at some point after it's released. Can he rely on every binary having a manpage? No. Can he rely on most binaries having manpages? Yes. Can he file bugs about this? Yes. Can he submit a manpage of his own and have it included? Yes. None of these answers are any different to how it is now. Changing policy in this manner has no benefit to users. No, but they can't now either because it's only a should. At present, lots of binaries don't have manpages. My suggestion would ensure that by the time woody+1 is released, *almost* every binary will have a manpage. Or it'd ensure that ftpmaster and the release manager would ignore policy, along with more maintainers. In any event, most binaries have manpages already. At present, there is no incentive for maintainers to add missing manpages; I'm sorry? There's no incentive for maintainers to fix bugs or improve their packages? Are you deluded? And you're not adding incentives, you're adding *disincentives*. Carrots are all very well, but we're talking about sticks here. Punishment for not doing what ever we want them to do. If there's not a clear and obvious reason why it's better to do what policy says than not independently of policy saying it, it shouldn't be in policy. If there is a clear and obvious reason, then that's the incentive you're looking for. Second, what happens to, say, security NMUs of packages without manpages? Do they get rejected out of hand, because of RC bugs? Or do the security team have to write manpages as well as do the fix and release advisories? What about NMUs to fix real RC bugs, like the app-defaults thing? Do they have to write manpages as well as fix the bugs as well? What about maintainers who just want to fix normal bugs promptly? Do I have to, say, write manpages for ping6 and traceroute6 and tracepath and tracepath6 when I make an upload of iputils.dsc to set its Maintainer: to debian-qa? As I said when discussing this originally: (1) NMUs may be exempt from these rules for the very reasons you point out. So I should orphan all my packages and maintain them by NMU. What a pain. (3) Maintainers who just want to fix normal bugs promptly *will* have to also make sure that their packages are policy-compliant before they upload them. Otherwise we are back to the current setup where policy is ignored by a significant number of maintainers. So if I don't have the time or interest to write a manpage for some stupid program, you'd rather just ignore the cute patch for case insensitive searching or the new upstream update that I've packaged, or whatever it might be. Either policy is being written by a small group of maintainers sitting in an ivory tower with nothing better to do with their time, and has no relevance to the rest of the project, or policy is an important tool for ensuring that there is a modicum of consistency between packages. The latter is the reason why Debian is so much better than many other distros, as Chris Rutter once told a visitor to our stand: we require packages to comply to quite well defined specs. Well, quite frankly it looks more like the former to me these days. What's it mean to be in an ivory tower? That you're not getting down into the muck and helping with real problems. That you're not listening to the people you're trying to order around. That you're distanced from them. That you think you're superior to them. How does saying you can't upload packages anymore if you don't write manpages for all your binaries help those manpages get written? It doesn't. It either takes time away from volunteers who'd rather be doing other things, or it makes volunteers decide not to waste time on improving their packages because they're not willing to do what you dictate. As I said in my previous message, -policy seems to be uninterested in bothering to actually investiage the issues they're talking about: actually working out which packages would be removed from the distro after a policy proposal is accepted is just Too Hard, and looking at packages themselves isn't worth the effort when there's a Standards-Version field that policy declares should be correct, and therefore clearly must be. Only the truth is that we don't, really. Maintainers who want to follow policy do, and those who don't, don't. And there's nothing encouraging them
Re: Must and should again
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Every package must comply with the MUST directives of the Anthony current policy, or it doesn't get released. Packages that Anthony don't comply with the current policy's SHOULD directives Anthony are buggy. First I believe your reading of should is inconsistent with current policy. In this manual, the words _must_, _should_ and _may_, and the adjectives _required_, _recommended_ and _optional_, are used to distinguish the significance of the various guidelines in this policy document. Packages that do not conform the the guidelines denoted by _must_ (or _required_) will generally not be considered acceptable for the Debian distribution. Non-conformance with guidelines denoted by _should_ (or _recommended_) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. I believe it is consistent with that text for me as a maintainer to close a normal bug opened against my package because I violate a should guideline explaining why I had a good reason for doing what I did. While generally a bug, it might not be a bug in my case. Second, let me explain what I want out of the should/must terms in policy as a user and maintainer and then try and describe how the current system fails. * I want a term corresponding to RFC MUST--violating that guideline is always RC. As a maintainer I know that I need to change policy before violating that guideline, and I better have so really good reasons before bringing forward a proposal to change the guideline. As a user, I have a big stick (RC bugs) to hit people with when they violate the guideline. * A term corresponding to RFC SHOULD. As a maintainer, I need to think hard about violating the guideline and know why my case is not the same as the general case that caused the guideline to be created. Often, there may be text along with a should indicating circumstances where the policy authors knew the guideline would be inappropriate, but in other cases they realized flexibility was needed and could not enumerate the cases where you might reasonably want to violate the guideline. As a user, I still want a big stick (RC bugs) to hit people with if they unreasonably violate the guideline. Yes, this means the maintainer could simply assert that their reason was sufficient, but really most maintainers try to be honest about the handling of their bugs. A normal bug is not a big enough stick; some should guidelines might be a significant problem if violated for the wrong reasons. * As a maintainer I want to have a general idea what guidelines are shoulds simply because not all packages implement them and will become musts.That gives me information about what I need to do in the future. If Debian-policy has already decided that they would like to eventually turn a certain guideline into a must and I believe that I have a good reason (other than not getting around to it) for violating that guideline that I should talk to Debian-policy now. If I don't convince the list that my reason is sufficient then I better think of something to do before the guideline becomes a must. My problems with the current policy are that it's not clear it acknowledges the existence of the class of guidelines that have exceptions other than not being implemented by enough packages. Also, it's not clear to me that I have recourse as a user if a package is violating a should in a way that creates a significant problem for users of that packages. In some cases I might be able to open grave (although not serious) bugs because the definition of grave only requires that the release would be improved by removing the package where as serious requires a specific policy violation--this might actually be sufficient. Finally, the current policy does not convey future intent of debian-policy to me as a maintainer. For example, I believe this list has reached a consensus that it would like to turn build-depends into a MUST and the only thing holding us back is the number of packages that do not have build-depends currently. It would be nice if the wording of policy let me know that the only reason the guideline was not mandatory was existing packages.
Re: Must and should again
On Fri, Apr 13, 2001 at 01:11:31PM -0400, Sam Hartman wrote: I believe it is consistent with that text for me as a maintainer to close a normal bug opened against my package because I violate a should guideline explaining why I had a good reason for doing what I did. While generally a bug, it might not be a bug in my case. Sure. *Everything* in policy is just a guideline, and there can always be special cases. That's why we have maintainers with good judgement. My problems with the current policy are that it's not clear it acknowledges the existence of the class of guidelines that have exceptions other than not being implemented by enough packages. If you don't have any common sense or good judgement, please go away. If you do: use it. It's almost always clear whether a policy violation is a mistake, or if it's deliberate and desirable. If it's not, it's probably worth talking about it, and either updating policy to mention the exception, or noting it in README.Debian, or doing otherwise. Also, it's not clear to me that I have recourse as a user if a package is violating a should in a way that creates a significant problem for users of that packages. File an important bug if something about a package causes significant problems for significant numbers of users. Submit a patch as well. Talk to the maintainer and make sure your patch doesn't have any ill effects for others. This is free software: you don't need threats and sticks to get things done. You're all insane, btw. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpe4v2zGhsTk.pgp Description: PGP signature
Re: Must and should again
Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian Must == have to do this, RC bug if don't Julian Should == we recommend you do this, normal bug if don't May == recommended. Julian I would much prefer to move to the RFC version with some sort of flag: Julian Must == absolute requirement Julian Should == requirement except in special circumstances, or: Julian highly encouraged Julian May == truly optional Julian Then there is an indication on each must and should directive whether Julian it is yet considered RC. No. This brings a time factor into the policy; and has been something we have avoided so far. Julian One of the issues is this: it is very hard in the current setup to Julian introduce a must, as it is likely to break a lot of existing Julian packages. There are different types of requirements. Policy should not be used as a stick. If things must be done this way, they should be done whether or not there is a policy directive telling us to do the right thing. When packages are changed over, policy shall be changed to document that. Julian Example 1: New X app-defaults location JulianThis has to be implemented in all affected packages *now*, else Julianlots of stuff will break. Policy is not a catchall for correct methods; we can file bugs against packages now for not working *right now*. Adding the stick of policy does not add much -- all you would have is that you could file policy-violation bugs rather than package breaks bugs. Julian Example 2: FHS transition JulianOnce the tech ctte had decided upon the transition plan, all Julianpackages should start transitioning. However, there was no need Julianfor all packages to transition right away. But it would have been Julianreally good to say: every new upload (NMUs possibly excepted) must Julianimplement the /usr/doc - /usr/share/doc transition plan, while Juliannot filing RC bugs against existing packages. So there are different rules for different packages? I am not sure I like the ramifications of this idea. Julian - uploads are required to conform to the latest version of policy Julian(NMUs excepted?); many aspects of this can be checked using an Julianup-to-date version of lintian (but see variant suggestions below) Julian - we don't file RC bugs on new requirements until we decide that it Julianis necessary and that we are realistically able to fix any packages Julianwith the issue outstanding in a reasonable length of time That a) introduces a time component into policy b) makes it harder to determine whther something is an RC bug (not all people follow -policy) Julian - When introducing a new requirement, there must be sufficient testing Julian or code or experience or something to ensure that we're not barking Julian up the wrong tree. That would cause a lot of headache. (Consider Julian the abortive /var/cache - /var/state move.) It may thus be wise in Julian certain circumstances to introduce these requirements initially as Julian recommendations, so that people are not forced to convert their Julian packages immediately. We do that now as a default, so that is no change. You are trying to shoe horn policy into an enforcement scheme, and I think this is a bad idea. manoj -- I don't know what their gripe is. A critic is simply someone paid to render opinions glibly. Critics are grinks and groinks. Baron and Badger, from Badger comics 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
Re: Bug#93620: ftp.debian.org: debian-policy recommends a nonexistent package
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony On Tue, Apr 10, 2001 at 09:37:20PM -0700, [EMAIL PROTECTED] kwrote: debian-policy 3.5.2.0 in woody and unstable recommends packaging-manual but packaging-manual only exists in stable. Either debian-policy should not recommend packaging-manual, or packaging-manual should be installed. Anthony This is clearly a bug in policy, and there's even already a Anthony bug filed about this there. The packaging manual is supposed to be a part of dpkg documentation, and should be re-uploaded soon. The problem is that the new dpkg containing the packaging manual has not been uploaded; and the manual was removed from the archive (well, since there is still sources for the packaging manual in the pool, we could have left it in an technically not violated the GPL) When packaging manual re-emerges, the recommendation should come back again. manoj -- You don't just go to the Black Lodge and walk out with your girlfriend. Karl, explaining the last episode of Twin Peaks 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
Re: Must and should again
I've had a thought about my ideas. I suggest that we all try doing a 'PMI' on them (I will not have a chance now until early next week, though). It's a three minute task, and you should be strict about timing, and works like this: For one minute, come up with as many Positive thoughts and ideas as you can about the proposal I've made; note them quickly as you go. For one minute, come up with as many Negative thoughts and ideas as you can about the proposal I've made; note them quickly as you go. For one minute, come up with as many Interesting thought and ideas as you can about the proposal I've made; note them quickly as you go. These are things like: here's something it's made me realise; how about doing it like this; is X really an issue; issue Y has been ignored. Then early next week, we can all share what we've come up with. I'm sure I've overlooked issues and that this can be improved, but arguing in the way we have isn't going to do that. It may even be that someone will come up with something which will make us think of a completely different way of handling this, or leaving it as is. Once again, here was what I wrote: On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote: Problems: (1) Many maintainers ignore policy changes and don't apply them to their packages. The above statistics give some indication of the extent of this problem. (2) We don't enforce policy dictates except by filing RC bugs at a very late stage in the process, once we've decided that the requirement should be an absolute. (3) The above two points mean that it is hard to maintain a high quality of packages in any automated fashion, and that a large burden is put on a small number of developers who try to fix the problems thereby caused, for example the /usr/doc - /usr/share/doc transition is still not complete. (4) It also means that we are often afraid to do the right thing and demand that packages satisfy certain criteria (all binaries to have manpages) because too many packages will then receive RC bugs, even though we should demand this of all packages and it really isn't an RC issue. (5) There is only language in policy for this is an RC requirement and this is a requirement, but not RC. Both indicate bugs if there is a failure to comply. There is no language for: except in unusual circumstances, you must do this, which would not necessarily indicate a bug for lack of compliance. (For example, the update-rc.d binary in file-rc need not have a manpage, as it depends on sysvinit which does. So maybe the manpage requirement really ought to be a should or needs to explicitly exclude this type of case.) Proposal: (a) Package uploads into unstable must comply with the latest version of policy (or be no more than, say, one month out of date). Suggested implementation: lintian could be used to do this, with a strict check on the Standards-Version. It would probably be a slightly rough ride to begin with, but worth it in the long term. We'd need to figure out what to do with lintian overrides though: perhaps musts could not be overridden but shoulds could be? (b) The release manager decides upon a minimum acceptable Standards-Version for each release once (a) has been implemented. Most packages will automatically satisfy this requirement due to the enforcement in (a), especially if the minimum version is no later that that of the previous released version; I would guess that 90% of packages are uploaded at least once per year. (c) Urgent requirements could be dealt with using the current RC bug method after being discussed on -policy. Then, as a *corollary* of the above, must and should would need to change their meanings, as we would have a different way of determining which policy bugs are RC, given in (b). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Must and should again
On Fri, Apr 13, 2001 at 06:41:55PM +0100, Julian Gilbey wrote: I've had a thought about my ideas. I suggest that we all try doing a 'PMI' on them (I will not have a chance now until early next week, though). It's a three minute task, and you should be strict about timing, and works like this: [...] Then I'd ask you to do the same thing with: * Don't use the policy's newly found ability to declare packages unreleasable except in the most extreme cases. Indeed, don't even attempt to enforce policy. Just make it so that packages that follow policy are clearly better than ones that don't. * Keep in mind that all of policy is just guidelines, and that if a maintainer truly does know better than policy, then it's not a bad thing for him to just ignore policy and do what's right. See you Tuesday. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
