Re: Policy rewrite: chs 1 2
On Tue, Feb 20, 2001 at 12:10:38AM +, Julian Gilbey wrote: But surely there are lots of other such obsolete constructs and libraries; we really need a programmer's guide for such things rather than policy. Manoj once volunteered to write a Debian programmer's guide :-) (This was when the issue of the proper way to write a daemon came up.) Still, I see nothing wrong with discouraging specific practices in policy. Richard Braakman
Re: Policy rewrite: chs 1 2
On Tue, Feb 20, 2001 at 11:59:20AM +0200, Richard Braakman wrote: On Tue, Feb 20, 2001 at 12:10:38AM +, Julian Gilbey wrote: But surely there are lots of other such obsolete constructs and libraries; we really need a programmer's guide for such things rather than policy. Manoj once volunteered to write a Debian programmer's guide :-) (This was when the issue of the proper way to write a daemon came up.) Still, I see nothing wrong with discouraging specific practices in policy. Shall we have the programmer's guide as an appendix to policy, then, until it becomes its own package? 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/
Bug#83977: PROPOSED] include Perl Policy
On Tue, Feb 20, 2001 at 01:44:42PM +1100, Brendan O'Dea wrote: Update to specify build-depends for perl. Current version is at http://people.debian.org/~bod/perl-policy/perl-policy.sgml You've got loads of examples of things like tt/.../ in your sgml file instead of tt ... /tt. That's not valid sgml, is it? 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/
Bug#83977: PROPOSED] include Perl Policy
On Tue, Feb 20, 2001 at 11:28:36AM +, Julian Gilbey wrote: On Tue, Feb 20, 2001 at 01:44:42PM +1100, Brendan O'Dea wrote: Update to specify build-depends for perl. Current version is at http://people.debian.org/~bod/perl-policy/perl-policy.sgml You've got loads of examples of things like tt/.../ in your sgml file instead of tt ... /tt. That's not valid sgml, is it? It is. Referred to as a NET tag. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: [PROPOSAL] Allowing crypto in the main archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: Okay, hopefully the final language change: Proposal is to change section 2.1.5 of the Debian policy to say: Non-free programs with cryptographic program code must be stored on the non-us server because of export restrictions of the U.S. Programs which use patented algorithms that have a restrictied license must also be stored on non-us, since that is located in a country where it is not allowed to patent algorithms. A package that depends on another package which is distributed via the non-us server must to be stored on the non-us server as well. Wichert. Ok, I know I am a bit late, but since I recently got my Debian developer status and this is exactly what I asked for in my mail on 2001-01-01, I second this. Are 2 seconds (this should be the 2. second on this phrasing if I have not missed any) enough to make it official ? Rene -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.3 for non-commercial use http://www.pgp.com iQA/AwUBOpJnv6u0jw3DwkveEQIfuQCguuMOB/AJsy/AFfnbxrwA4wcAnFYAoLpD YJDE4tHumwA8bhfen70tu1Q5 =loND -END PGP SIGNATURE-
Re: [PROPOSAL] cron.* scripts should be quiet
On Fri, Feb 16, 2001 at 09:15:09AM +0100, Arthur Korn wrote: Joey Hess schrieb: Julian Gilbey wrote: On Fri, Oct 06, 2000 at 10:43:09AM +0200, Arthur Korn wrote: Probably it should be clearly stated in policy that the cron.* scripts may be quiet if no errors are encountered. What do people think of this suggestion (s/may/MUST/)? I dislike it. It's possible some package will exist that is _designed_ to fire off daily status reports by cron. We shouldn't prohibit such things without reason. I suggested this to be a should. Good. How about something like cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to root. 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: [PROPOSAL] cron.* scripts should be quiet
* Julian Gilbey [EMAIL PROTECTED] [010220 07:29]: Good. How about something like cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to root. Why specifically root? I could imagine situations where a cron script may be setup to mail to some other user and yet still want to be installed through the Debian system. I'd like to suggest deleting to root. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Bug#83977: PROPOSED] include Perl Policy
Removed shorttags. New version at: http://people.debian.org/~bod/perl-policy/perl-policy.sgml Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: [PROPOSAL] cron.* scripts should be quiet
On Tue, Feb 20, 2001 at 07:49:34AM -0800, Seth Arnold wrote: * Julian Gilbey [EMAIL PROTECTED] [010220 07:29]: Good. How about something like cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to root. Why specifically root? I could imagine situations where a cron script may be setup to mail to some other user and yet still want to be installed through the Debian system. I'd like to suggest deleting to root. Ah, so we need to get the wording better. How about the following: cron.* scripts should not produce output on stdout. An exception may be made if the intention of the script is to mail a status report to root. This is because stdout gets mailed to root by cron. 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: [PROPOSAL] cron.* scripts should be quiet
Julian Gilbey (2001-02-20 16:23:10 +) : This is because stdout gets mailed to root by cron. ...unless otherwise specified: [...] In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent to the user so [...] -- Paul Vixie, in man 5 crontab -- Roland Mas [...] Des fois, y'a des trous. -- (Ptiluc) -- Signatures à collectionner, série n°2, partie 3/3.
Re: [PROPOSAL] cron.* scripts should be quiet
Roland Mas schrieb: Julian Gilbey (2001-02-20 16:23:10 +) : This is because stdout gets mailed to root by cron. ...unless otherwise specified: So what about: cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to the administrator. Though I feel that the exeption is to broad. I don't want to be mailed status reports like everything is fine from dozends of machines. ciao, 2ri -- Der beste Beweis für die Existenz ausserirdischer _Intelligenz_ ist der, dass noch niemand versucht hat, Kontakt mit uns aufzunehmen. -- Bill Watterson
Re: [PROPOSAL] cron.* scripts should be quiet
* Arthur Korn [EMAIL PROTECTED] [010220 09:35]: So what about: cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to the administrator. I like this, though the should not use stdout version with the same semantic change would work just as well with me. :) Though I feel that the exeption is to broad. I don't want to be mailed status reports like everything is fine from dozends of machines. In this case, I would think a wishlist bug against the package in question, asking for a simple variable/command line switch to tweak the verbosity in non-error cases would be in order; hmm. Tough call. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
only release packages that have maintainers?
Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA?
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? Then I'll adopt all the packages that don't have a maintainer and send RFAs for them (like I did with several of the packages tbm wanted to remove). But I take care about them when the maintainer is set to Debian QA, too, so I can't see the big difference. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: only release packages that have maintainers?
* Sean 'Shaleh' Perry [EMAIL PROTECTED] [010220 10:39]: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? In taking a quick list at the packages my machine knows about, it sure appears that Debian could still be useful if all those packages were thrown out. But, I am curious why you wish to do so. Is the Debian QA team getting tired of being the QA team? Do those packages have inordinate amounts of bugs compared to other packages? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: only release packages that have maintainers?
On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? This isn't such a bad idea. Then I'll adopt all the packages that don't have a maintainer and send RFAs for them (like I did with several of the packages tbm wanted to remove). But I take care about them when the maintainer is set to Debian QA, too, so I can't see the big difference. Yes, well as I've said to tbm, 1) adopting a package just to 'save' it, without really caring/wanting it just perpetuates old crufty packages in Debian, while some of these ancient neglected packages are just.. neglected, others are genuinely useless I think, otherwise would someone not have cared, and grabbed it? Which brings me to 2) can we get rid of more of these old crufty ones? Everyone is so afraid do this, else they'll get flamed for being evil and removing old packages! indeed the impertinence. I'd give some examples from the BTS but I don't feel like waiting. -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
only release packages that have maintainers?
Sean 'Shaleh' Perry writes: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? How about asking the QA team? I think that packages maintained by the QA team is a poor criterion for getting software. They shouldn't delay a release, but if the code is still useful, I don't think we should throw it out just because it relies on debian-qa for TLC. As a QA member, I'd feel a bit miffed. We exist at least partly to ensure that code no-one is maintaining is kept to a high standard. Maybe the QA team should be allowed to decide to prune things? Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org
Re: only release packages that have maintainers?
Matthew Vernon schrieb: Maybe the QA team should be allowed to decide to prune things? The QA team is the maintainer of these packages, and thus can request theyer removal just as every other maintainer can (though usually uninteresting stuff is orphaned by normal maintainers). Posting an ITR (Intend To Remove) to debian-devel would be nice of corse, even though maintainers should occasionally have a look on the work-needing packages report and adopt stuff they are interested in. ciao, 2ri -- Der beste Beweis für die Existenz ausserirdischer _Intelligenz_ ist der, dass noch niemand versucht hat, Kontakt mit uns aufzunehmen. -- Bill Watterson
Re: only release packages that have maintainers?
Hi. Yes, I have a comment :) I think the only packages that should be released are those without bugs. -Jim
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Brian Russo wrote: On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? This isn't such a bad idea. Then I'll adopt all the packages that don't have a maintainer and send RFAs for them (like I did with several of the packages tbm wanted to remove). But I take care about them when the maintainer is set to Debian QA, too, so I can't see the big difference. Yes, well as I've said to tbm, 1) adopting a package just to 'save' it, without really caring/wanting it just perpetuates old crufty I care about these packages: - they have no open RC bugs - I fix all other bugs I can fix without spending too much time - they have all a Standards-Version = 3.1 (that means their Standards-Version is higher than the one of 25% of the packages in Debian!) packages in Debian, while some of these ancient neglected packages are just.. neglected, others are genuinely useless I think, otherwise would someone not have cared, and grabbed it? I remember that silo was orphaned for several months before someone adopted it... Which brings me to 2) can we get rid of more of these old crufty ones? Everyone is so afraid do this, else they'll get flamed for being evil and removing old packages! indeed the impertinence. ... How do you decide if something is old crufty? I believe that of Our Priorities are Our Users and Free Software and that's why I want that there's a good reason when a package gets removed. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: only release packages that have maintainers?
On Tue, Feb 20, 2001 at 08:57:39PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Brian Russo wrote: On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: Then I'll adopt all the packages that don't have a maintainer and send RFAs for them (like I did with several of the packages tbm wanted to remove). But I take care about them when the maintainer is set to Debian QA, too, so I can't see the big difference. Yes, well as I've said to tbm, 1) adopting a package just to 'save' it, without really caring/wanting it just perpetuates old crufty I care about these packages: - they have no open RC bugs - I fix all other bugs I can fix without spending too much time - they have all a Standards-Version = 3.1 (that means their Standards-Version is higher than the one of 25% of the packages in Debian!) eh? example: saml There is 7 open bugs on it (1 serious, 6 normal, 1 wishlist) Standards-Version: 2.3.0.1 upstream last touched it approximately /four/ years ago. Not all orphaned packages are like this, but there are a fair number. I'm not talking about the packages that have been orphaned for only a few months. packages in Debian, while some of these ancient neglected packages are just.. neglected, others are genuinely useless I think, otherwise would someone not have cared, and grabbed it? I remember that silo was orphaned for several months before someone adopted it... I'm not talking about several months, more like 1 year+, there are many of these in wnpp. Which brings me to 2) can we get rid of more of these old crufty ones? Everyone is so afraid do this, else they'll get flamed for being evil and removing old packages! indeed the impertinence. ... How do you decide if something is old crufty? I believe that of Our Priorities are Our Users and Free Software and that's why I want that there's a good reason when a package gets removed. If something has been abandoned for a 1 year and a half, you don't think it's crufty? -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
packages with really old standards version
So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held.
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Brian Russo wrote: On Tue, Feb 20, 2001 at 08:57:39PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Brian Russo wrote: On Tue, Feb 20, 2001 at 07:56:04PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: Then I'll adopt all the packages that don't have a maintainer and send RFAs for them (like I did with several of the packages tbm wanted to remove). But I take care about them when the maintainer is set to Debian QA, too, so I can't see the big difference. Yes, well as I've said to tbm, 1) adopting a package just to 'save' it, without really caring/wanting it just perpetuates old crufty I care about these packages: - they have no open RC bugs - I fix all other bugs I can fix without spending too much time - they have all a Standards-Version = 3.1 (that means their Standards-Version is higher than the one of 25% of the packages in Debian!) eh? ... I was refering to the adopting a package just to 'save' it. This is the state of the 15 packages I have currently adopted to avoid their removal (and the last two will follow soon). Not all orphaned packages are like this, but there are a fair number. I'm not talking about the packages that have been orphaned for only a few months. And I do sometimes make uploads for orphaned packages to fix bugs, upgrade the Standards-Version and sometimes upload a new upstream version. packages in Debian, while some of these ancient neglected packages are just.. neglected, others are genuinely useless I think, otherwise would someone not have cared, and grabbed it? I remember that silo was orphaned for several months before someone adopted it... I'm not talking about several months, more like 1 year+, there are many of these in wnpp. Since the cleanup Martin made there can't be many that are orphaned for more than half a year with noone who intends to adopt them. Which brings me to 2) can we get rid of more of these old crufty ones? Everyone is so afraid do this, else they'll get flamed for being evil and removing old packages! indeed the impertinence. ... How do you decide if something is old crufty? I believe that of Our Priorities are Our Users and Free Software and that's why I want that there's a good reason when a package gets removed. If something has been abandoned for a 1 year and a half, you don't think it's crufty? Not automatically. I'm willing to spend some time on the packages that are orphaned, it doesn't matter if they are officially maintained by QA or by me. Has anyone a good reason why it's bad when I take care of these packages instead of seeing them getting removed? I can't see the benefits when we get rid of let's say 50 packages. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Brian Russo wrote: ... example: saml There is 7 open bugs on it (1 serious, 6 normal, 1 wishlist) Standards-Version: 2.3.0.1 upstream last touched it approximately /four/ years ago. ... I forgot to say about this example: Ian Zimmerman [EMAIL PROTECTED] intends to adopt this package so there's a Debian maintainer for this package. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: packages with really old standards version
* Sean 'Shaleh' Perry [EMAIL PROTECTED] [20010220 12:49]: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this. -- Martin Michlmayr [EMAIL PROTECTED]
Re: packages with really old standards version
Hi Sean! On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. picardmake it so/picard yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' :By professionals, | `. `' for professionals http://www.palfrader.org/ | `-http://www.debian.org/
Re: packages with really old standards version
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. Just for the record: ftp.debian.org has currently 579 source packages with standards version 3.0.0 And just out of curiosity: apt has standards version 2.4.1 And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: only release packages that have maintainers?
On 20-Feb-2001 Seth Arnold wrote: * Sean 'Shaleh' Perry [EMAIL PROTECTED] [010220 10:39]: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? In taking a quick list at the packages my machine knows about, it sure appears that Debian could still be useful if all those packages were thrown out. But, I am curious why you wish to do so. Is the Debian QA team getting tired of being the QA team? Do those packages have inordinate amounts of bugs compared to other packages? they are usually 2.x policy, not 3.x. A very small number of people are working on them, etc. Plus as others have said, if no one cares, the package should not be here.
RE: only release packages that have maintainers?
On 20-Feb-2001 Matthew Vernon wrote: Sean 'Shaleh' Perry writes: Anyone have comments on the idea that the only packages we should release are ones that have a maintainer, not Debian QA? How about asking the QA team? I think that packages maintained by the QA team is a poor criterion for getting software. They shouldn't delay a release, but if the code is still useful, I don't think we should throw it out just because it relies on debian-qa for TLC. As a QA member, I'd feel a bit miffed. We exist at least partly to ensure that code no-one is maintaining is kept to a high standard. Maybe the QA team should be allowed to decide to prune things? I am definately *NOT* saying that it should go away immediately. More, we should prune long QA packages. Maybe 6 months, may be longer. Some kind of mechanism for this would be nice. Of course, QA should have a say, I did not mean to take away any of your and others work.
Re: packages with really old standards version
* Adrian Bunk [EMAIL PROTECTED] [010220 13:52]: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. And just out of curiosity: apt has standards version 2.4.1 That is interesting. Of course, I bet apt 0.4 will be 3.x.x when it is finally released. And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. Logistics aside though, wouldn't it be kind of neat to have all the packages shipped with woody be standards version 3.0 or higher? (Although, maybe sarge is a better idea for this one; sarge ought to have kernel 2.4.x, and between that and having all packages be standards version 3.x, numbering sarge to 3.0 would make a certain amount of cool sense. shrug) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages with really old standards version
And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. sounds like a plan to me. Many of these are either: a) horribly out of date b) simply forgot to change the number
Re: only release packages that have maintainers?
Adrian == Adrian Bunk [EMAIL PROTECTED] writes: Adrian On Tue, 20 Feb 2001, Brian Russo wrote: Adrian I'm willing to spend some time on the packages that are Adrian orphaned, it doesn't matter if they are officially Adrian maintained by QA or by me. Has anyone a good reason why Adrian it's bad when I take care of these packages instead of Adrian seeing them getting removed? I can't see the benefits when Adrian we get rid of let's say 50 packages. No, you actually seem to be doing a good job as far as I can tell, so have at it. What you need to realize (and probably do) is that you have finite time and that if after a while you no longer have time to maintain the packages you have adopted you need to either find someone else to take care of them or ask for their removal. If Debian grows for ever and people sometimes orphan packages, then you will eventually be faced with either finding someone else who like you wants to see packages stay in Debian or choosing some packages to remove. So long as you are willing to remove the packages if you fail to find someone who can take care of them, then I think you're providing a useful service to the community.
Re: only release packages that have maintainers?
* Sam Hartman [EMAIL PROTECTED] [20010220 17:04]: What you need to realize (and probably do) is that you have finite time and that if after a while you no longer have time to maintain the ... are willing to remove the packages if you fail to find someone who can take care of them, then I think you're providing a useful service to the community. This is what I sent to Adrian recently; I'm reposting it here since I think some kind of Release Notes would be nice: If you do something worthwhile then write good Release Notes saying which packages have been removed and listing better replacements if there are any (e.g. upsd should be removed, replacement is nut and possibly others). That would be our users a better service that keeping packages around which are e.g. not even maintained upstream anymore. -- Martin Michlmayr [EMAIL PROTECTED]
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Martin Michlmayr wrote: * Sam Hartman [EMAIL PROTECTED] [20010220 17:04]: What you need to realize (and probably do) is that you have finite time and that if after a while you no longer have time to maintain the ... are willing to remove the packages if you fail to find someone who can take care of them, then I think you're providing a useful service to the community. This is what I sent to Adrian recently; I'm reposting it here since I think some kind of Release Notes would be nice: If you do something worthwhile then write good Release Notes saying which packages have been removed and listing better replacements if there are any (e.g. upsd should be removed, replacement is nut and possibly others). That would be our users a better service that keeping packages around which are e.g. not even maintained upstream anymore. And my personal opinion is that I prefer to keep a package if there's not a _good_ reason why it should get removed (and yes - it happens that I see a good reason why a package should get removed). cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: [PROPOSAL] cron.* scripts should be quiet
On Tue, 20 Feb 2001, Seth Arnold wrote: * Julian Gilbey [EMAIL PROTECTED] [010220 07:29]: Good. How about something like cron.* scripts should not produce any non-error output in general. An exception may be made if the intention of the script is to mail a status report to root. Why specifically root? I could imagine situations where a cron script may be setup to mail to some other user and yet still want to be installed through the Debian system. It already exists. Snort can be set up via debconf to send output to any account. I'd like to suggest deleting to root. -- I can be immature if I want to, because I'm mature enough to make my own decisions. Who is John Galt? [EMAIL PROTECTED]
Re: only release packages that have maintainers?
On Tue, Feb 20, 2001 at 10:20:36PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Brian Russo wrote: On Tue, Feb 20, 2001 at 08:57:39PM +0100, Adrian Bunk wrote: I remember that silo was orphaned for several months before someone adopted it... I'm not talking about several months, more like 1 year+, there are many of these in wnpp. Since the cleanup Martin made there can't be many that are orphaned for more than half a year with noone who intends to adopt them. [ you mention someone is adopting saml in a separate email ] ok that's fine, but this was a recent occurence, there was a long period where it was completely orphaned, and there are other packages that are still, completely orphaned. ... so we just let them sit there, forever? I mean someone will eventually pick them up.. yes, that's probably true, let it sit there long enough, for a couple years and probably some NM will grab it, but all during that time you have crappy ancient packages sitting around. Probably even the NM's that grab them don't really care, as if it were _so_ traumatic that after being removed a package should be later re-introduced when someone decides that its useful! it's not like it's hard to get packages into the archive, it _IS_ hard to get them out, this is mildly silly. also, if someone really wants a package of it, and its no longer in the distro, it's not *too* hard for them to get an older package out of archives. If something has been abandoned for a 1 year and a half, you don't think it's crufty? Not automatically. I don't remember saying it should be automatic. I'm willing to spend some time on the packages that are orphaned, it doesn't matter if they are officially maintained by QA or by me. Has anyone a good reason why it's bad when I take care of these packages instead of seeing them getting removed? I can't see the benefits when we get rid of let's say 50 packages. I'm not saying you don't have a right to upload -qa packages or any such thing. What I don't understand is if you really think they're useful, why you don't adopt them outright (no, not adopt then RFA). One of the present tasks of the -qa team is maintaining orphaned packages, but beyond a certain point, they must be dropped. Benefits of removing 50 crappy packages: o. Number of bugs in general goes down. o. Users are confronted with less crap to install o. Fewer collisions in the package name/file system namespace. o. Less load on BTS, ftp archives, mirrors, et al. o. Debian has less of a reputation for having old, worthless crappy packages. o. QA team can (maybe) spend time ACTUALLY doing QA instead of maintaining old, worthless packages that nobody visibly cares about. o. If they're crappy worthless packages, what's the real benefit of having them any? And WHY hadn't they been adopted ages ago? o. Fewer flamewars on old crappy packages on -policy, -qa, etc. I'm not talking about old packages per se, some old packages are simply stable, no active development 'cause no need to, etc. I'm not talking about 4 month old maintainerless packages, some are just lonely, looking for someone to pick them up. I AM talking about ancient, buggy packages (no not /just/ RC bugs) that are maintainerless, often having a dead upstream, that have been sitting around for a fairly long time (i'd say 8 months is a pretty lenient cut-off). Quality Assurance (n): a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met hmm, Perhaps we should rename the Quality Assurance team to the Debian Historical Package Preservation Society ? ... one last thought, it seems accepted that its ok for maintainers to ask for their packages to be removed, if this is true, would anyone object if i adopted a package then asked for its removal? i know this is silly, but then i think this whole thread is silly. -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: only release packages that have maintainers?
On Tue, 20 Feb 2001, Brian Russo wrote: ... I'm willing to spend some time on the packages that are orphaned, it doesn't matter if they are officially maintained by QA or by me. Has anyone a good reason why it's bad when I take care of these packages instead of seeing them getting removed? I can't see the benefits when we get rid of let's say 50 packages. I'm not saying you don't have a right to upload -qa packages or any such thing. What I don't understand is if you really think they're useful, why you don't adopt them outright (no, not adopt then RFA). One of the present tasks of the -qa team is maintaining orphaned packages, but beyond a certain point, they must be dropped. Benefits of removing 50 crappy packages: o.Number of bugs in general goes down. o.Users are confronted with less crap to install o.Fewer collisions in the package name/file system namespace. o.Less load on BTS, ftp archives, mirrors, et al. We are talking about less than 1% of the packages in Debian, less packages than the number of new packages each week. o.Debian has less of a reputation for having old, worthless crappy packages. When you can say why a package is worthless for everyone I think this is a good reason for a removal. o.QA team can (maybe) spend time ACTUALLY doing QA instead of maintaining old, worthless packages that nobody visibly cares about. I want to spend time on this packages to avoid them getting removed. o.If they're crappy worthless packages, what's the real benefit of having them any? And WHY hadn't they been adopted ages ago? Not every user is a developer? o.Fewer flamewars on old crappy packages on -policy, -qa, etc. I think there are fewer flamewars when we keep the packages... ... one last thought, it seems accepted that its ok for maintainers to ask for their packages to be removed, if this is true, would anyone object if i adopted a package then asked for its removal? i know this is silly, but then i think this whole thread is silly. The day after the package was removed I can send an ITP and upload a new package where I'm the maintainer and you can't stop this package from being in Debian again... Sorry, are we kids and everyone of us wants to be the most clever kid or are we intelligent adults? cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: packages with really old standards version
On Tue, 20 Feb 2001, Martin Michlmayr wrote: * Sean 'Shaleh' Perry [EMAIL PROTECTED] [20010220 12:49]: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this. So do I. 2.x doesn't get the GPL copyright, FHS or logrotate right, and that's a bit too much IMHO. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpViKEzrXDZ2.pgp Description: PGP signature
Re: only release packages that have maintainers?
On Tue, Feb 20, 2001 at 11:44:59PM +0100, Adrian Bunk wrote: On Tue, 20 Feb 2001, Brian Russo wrote: I'm not saying you don't have a right to upload -qa packages or any such thing. What I don't understand is if you really think they're useful, why you don't adopt them outright (no, not adopt then RFA). One of the present tasks of the -qa team is maintaining orphaned packages, but beyond a certain point, they must be dropped. Benefits of removing 50 crappy packages: o. Number of bugs in general goes down. o. Users are confronted with less crap to install o. Fewer collisions in the package name/file system namespace. o. Less load on BTS, ftp archives, mirrors, et al. We are talking about less than 1% of the packages in Debian, less packages than the number of new packages each week. how many does it take before it becomes wrong o. Debian has less of a reputation for having old, worthless crappy packages. When you can say why a package is worthless for everyone I think this is a good reason for a removal. I think I've demonstrated this as best as I can, I'm not promoting radical removal of packages, you seem to be the only one who has voiced disagreement, you have the right to an opinion certainly. o. QA team can (maybe) spend time ACTUALLY doing QA instead of maintaining old, worthless packages that nobody visibly cares about. I want to spend time on this packages to avoid them getting removed. Well that's fine, if you think Debian is better served by supporting older packages, instead of working on newer, active ones, have at it. o. If they're crappy worthless packages, what's the real benefit of having them any? And WHY hadn't they been adopted ages ago? Not every user is a developer? why don't we email debian-user and see if anyone cares then? I don't see mountains of letters pouring in from users asking that we fix up these packages, if there were heck I'd probably adopt more. one last thought, it seems accepted that its ok for maintainers to ask for their packages to be removed, if this is true, would anyone object if i adopted a package then asked for its removal? i know this is silly, but then i think this whole thread is silly. The day after the package was removed I can send an ITP and upload a new package where I'm the maintainer and you can't stop this package from being in Debian again... and then you'd immediately orphan/RFA it? i would have no objection if someone adopts them outright and improves them, rather than letting them bleed slowly to death. Sorry, are we kids and everyone of us wants to be the most clever kid or are we intelligent adults? kids/adults, silly outdated concept (promoted by adults). hm, so no comments on my Historical Society eh. ... I guess you'll have it your way then. Cruft remains, Debian (and it's users lose), IMO. you still haven't given a good reason that these packages remain, except that its your preference, clearly it should bear weight out of the hundreds of developers who have almost unanimously said I don't care and ignored these packages. IMO I don't want to perpetuate this thread anymore, ciao. -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 12:49:34PM -0800, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I.. (second? third? fourth?) this. -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: packages with really old standards version
On Tue, 20 Feb 2001 at 12:49:34 -0800 (PST), Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this proposal (assuming it is one). To avoid quite such a large number of RC bugs being filed, shall we try to deal with as many of these as possible during the bugsquash party this weekend? -- Colin Watson [EMAIL PROTECTED] pgp5MV6021a5W.pgp Description: PGP signature
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 12:49:34PM -0800, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I object to this. Holding packages due to actual bugs, yes certainly. Holding packages because there's a number that seems to indicate there might possibly be bugs, no way in hell. I'd encourage the lintian maintainer ( :) ) to automatically file old standards version bugs about such packages (of normal/minor/wishlist severity); and I'd definitely encourage the lintian maintainer to file serious bugs about automatically detect-able violations of any MUST directives in current policy (no matter what standards-version the packages claims to comply with). But please don't file RC bugs unless there is a *specific* problem with the package. Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 or similar, perhaps? 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) pgpsG8gAoIKhf.pgp Description: PGP signature
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote: Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory Yes, real bug. E-: missing-manpage Ditto. E?: standards-version-uses-4-digits-not-3 Not a bug (explicitly permitted by policy). As I work through policy, I'm going to take care over the issue of MUST/SHOULD/MAY etc. 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: packages with really old standards version
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote: I'd encourage the lintian maintainer ( :) ) to automatically file old standards version bugs about such packages (of normal/minor/wishlist severity); and I'd definitely encourage the lintian maintainer to file serious bugs about automatically detect-able violations of any MUST directives in current policy (no matter what standards-version the packages claims to comply with). I file any bugs I detect, once I get lintian running on the archive, old packages beware (-: A package of 2.x policy behaves in a way different than current packages. They lack a /usr/share/doc, their manpages are not in share either. They may violate other things. Point is, these packages will be a source of bugs. All I am asking for is the package get looked at. I found one today that had not been touched in 2 years. Ther eare many others, and they hide. If nothing else a way to flag packages older than X months or Standards-Version YY would be nice. Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed not sure what I am naming the MAY message. Messages that are not due to policy violations will have their level set on the importance of the problem. With this restructuring, a Developer who gets a third level may ignore the message, ignore a Warning for a short time and know that E: means 'I should read policy'.
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 06:27:40PM -0800, Sean 'Shaleh' Perry wrote: I file any bugs I detect, once I get lintian running on the archive, old packages beware (-: A package of 2.x policy behaves in a way different than current packages. They lack a /usr/share/doc, their manpages are not in share either. They may violate other things. Point is, these packages will be a source of bugs. Sure, but lacking /usr/share/doc is, aiui, a non-RC issue as it stands (since there seems to be some sort of deadlock in working out what to do about it)... All I am asking for is the package get looked at. I found one today that had not been touched in 2 years. Ther eare many others, and they hide. Sure, getting looked at is fine. That's different from filing RC bugs, though. E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed Currently, aiui, lintian uses E: for problems that it's sure are mistakes, and W: for problems that it's only guessing are mistakes. I think that division is still useful. katie or testing could legitimately automatically reject packages with E! lintian errors, but not E- or W!, eg. 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)
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 12:39:08PM +1000, Anthony Towns wrote: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed Currently, aiui, lintian uses E: for problems that it's sure are mistakes, and W: for problems that it's only guessing are mistakes. I think that division is still useful. no, it tries to do this based on 2.x level MUST/SHOULD and the authors beliefs of severity. Has nothing to do with the sureness of the test. katie or testing could legitimately automatically reject packages with E! lintian errors, but not E- or W!, eg. lintian will never be able to return a sure judgement. Manoj's packages confuse it thoroughly, but on hand inspection I am sure they follow policy. Every message lintian outputs should be checked manually and by a re-read of policy. It is trying to discern what a human meant. In the realm of coding, people do all kinds of crazy things and lintian can only cope so well. Assume every message is 'X-:'. A Package with an E: should be marked for human inspection at best. James Troup has stated that when I trust lintian he will consider hooking it into dinstall. I think this is a good thing. It is my hope to have lintian to a sane state by summer (July-ish). Wichert wants something in 3 months for the FSG. Not sure if the code base will make that, but I will try.
