Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On Sun, Jul 19, 2009 at 07:12:57AM +, Philipp Kern wrote: On 2009-07-19, Charles Plessy ple...@debian.org wrote: Do we have evidence that maintainers have damaged the project in the past by willingfully upload packages with overriden lintian errors? Damaged the project... no. Caused a RC bug to be overlooked... yes. I recently encountered a package where the library's binary package was not named after the SONAME. This caused a lintian error which was... overridden. And it broke horribly when the SONAME change went unnoticed because... well... the binary was never named after the SONAME and thus the check wasn't active anymore. Lintian's error on soname mismatches references both the binary package name, and what lintian thinks the package name should be based on the actual soname. AFAIK you can only override lintian errors by spelling them out fully, so surely the lintian error should have reappeared in this case as soon as the soname changed? Or did the maintainer willfully update the override *as well* when the soname changed? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On 2009-07-23, Steve Langasek vor...@debian.org wrote: On Sun, Jul 19, 2009 at 07:12:57AM +, Philipp Kern wrote: On 2009-07-19, Charles Plessy ple...@debian.org wrote: Do we have evidence that maintainers have damaged the project in the past by willingfully upload packages with overriden lintian errors? Damaged the project... no. Caused a RC bug to be overlooked... yes. I recently encountered a package where the library's binary package was not named after the SONAME. This caused a lintian error which was... overridden. And it broke horribly when the SONAME change went unnoticed because... well... the binary was never named after the SONAME and thus the check wasn't active anymore. Lintian's error on soname mismatches references both the binary package name, and what lintian thinks the package name should be based on the actual soname. AFAIK you can only override lintian errors by spelling them out fully, so surely the lintian error should have reappeared in this case as soon as the soname changed? That would have prevented this indeed. But it looks that it did not work that way because the only override present was this one: libbotan1.8: package-name-doesnt-match-sonames This obviously didn't need changing. According to [0] there was also no other Lintian warning. Kind regards, Philipp Kern [0] http://lintian.debian.org/maintainer/dan...@debian.org.html#botan-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On Sun, Jul 19, 2009 at 07:15:56PM +1000, Ben Finney wrote: There are a great many Debian changelog messages along the lines of “made change foo to keep Lintian happy” as though that were the only readon why such a change would be beneficial. Apart from being bloody useless, that kind of changelog message strongly implies that the writer hasn't bothered to understand why Lintian was programmed to complain about the issue in the first place. I've been guilty of this a few times. However, the lintian test in question was one that checked for a valid copyright line, and the fix was to bodge the existing valid copyright lines to match the test's regex. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On 2009-07-19, Charles Plessy ple...@debian.org wrote: Do we have evidence that maintainers have damaged the project in the past by willingfully upload packages with overriden lintian errors? Damaged the project... no. Caused a RC bug to be overlooked... yes. I recently encountered a package where the library's binary package was not named after the SONAME. This caused a lintian error which was... overridden. And it broke horribly when the SONAME change went unnoticed because... well... the binary was never named after the SONAME and thus the check wasn't active anymore. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On Sun, Jul 19, 2009 at 9:12 AM, Philipp Kern wrote: Damaged the project... no. Caused a RC bug to be overlooked... yes. I recently encountered a package where the library's binary package was not named after the SONAME. This caused a lintian error which was... overridden. And it broke horribly when the SONAME change went unnoticed because... well... the binary was never named after the SONAME and thus the check wasn't active anymore. The person who did this should probably reconsider their need to maintain library packages or be force-fed 100 copies of libpkg-guide (and its bugs) printed on sandpaper. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Charles Plessy ple...@debian.org wrote: Hi, Do we have evidence that maintainers have damaged the project in the past by willingfully upload packages with overriden lintian errors? We sure have a few people that would blindly add overrides rather than fixing the actual cause of the lintian warning/error. No doubt about that. Heck, we still have people that do not use lintian. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On Sun, Jul 19, 2009 at 09:08:50AM +0900, Charles Plessy wrote:
And today, the NEW queue managed by four persons dedicating 5-10
hours per week to the Debian archive contains 265 packages, some of
them waiting for one month or more. I disagree with their decision
to self-appoint themselves with a new duty while they are already
lacking time for the current one they volunteered for.
While I can understand your frustration, your argument looks flawed to
me. The measure of refusing _automatically_ uploads being affected by
(certain) lintian errors can not be classified as a new duty,
precisely because it will be automatic. Actually, it has even chances
to reduce the work-load related to processing NEW.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Julien BLACHE jbla...@debian.org writes: We sure have a few people that would blindly add overrides rather than fixing the actual cause of the lintian warning/error. No doubt about that. This might be a symptom of the wider problem, that people see Lintian not as a series of warning lights indicating probable problems with the package, but rather as “a deity to be appeased”, in the words of Al Viro URL:http://article.gmane.org/gmane.linux.kernel/831034. There are a great many Debian changelog messages along the lines of “made change foo to keep Lintian happy” as though that were the only readon why such a change would be beneficial. Apart from being bloody useless, that kind of changelog message strongly implies that the writer hasn't bothered to understand why Lintian was programmed to complain about the issue in the first place. I don't know what more can be done about this; heck, Lintian itself has an easily-accessed detailed explanation attached to every one of its tags that explains why fixing the issue that triggered that tag is of interest not to Lintian, but to the project at large. -- \ “It has yet to be proven that intelligence has any survival | `\ value.” —Arthur C. Clarke, 2000 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On Sun, Jul 19 2009, Ben Finney wrote: There are a great many Debian changelog messages along the lines of “made change foo to keep Lintian happy” as though that were the only readon why such a change would be beneficial. Apart from being bloody useless, that kind of changelog message strongly implies that the writer hasn't bothered to understand why Lintian was programmed to complain about the issue in the first place. Or the writer thinks that the Lintian check is wrong or pointless, and does not have the energy to enter into a flame fest about the issue. I have a few pet peeves with Lintian myself. manoj -- A car is just a big purse on wheels. Johanna Reynolds Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Le Sun, Jul 19, 2009 at 10:44:00AM +0200, Stefano Zacchiroli a écrit : While I can understand your frustration, your argument looks flawed to me. The measure of refusing _automatically_ uploads being affected by (certain) lintian errors can not be classified as a new duty, precisely because it will be automatic. Actually, it has even chances to reduce the work-load related to processing NEW. Hi Stefano, this is only the first half of the plan, and I completely agree with it. But according to Luk, packages introducing a new override will be parked to NEW for examination. This is the problematic part. (4a604816.5030...@debian.org). We are removing normalisation and discussion in favor of power-based enforcement. What will be the criteria for deciding that an override is correct? I guess it will follow the same logic as for the copyright summary: correct if a member of the FTP team thinks it is correct. What is the point having a Policy if we follow that path? I also understand the frustration of the release team, but to me, hijacking or removals are the appropriate response to irresponsible behaviours, not a set of extra rules for which our current experience already expose a flaw: think about changes in names of binary packages that trigger copyright checks by the FTP team. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Charles Plessy ple...@debian.org wrote: Hi, Automatic rejection of packages with errors not justified by overrides is of And what do you do with unjustified overrides? Or can I just override every lintian test and upload my totally broken package? JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
On 11815 March 1977, Julien BLACHE wrote: Automatic rejection of packages with errors not justified by overrides is of And what do you do with unjustified overrides? Or can I just override every lintian test and upload my totally broken package? The way we currently think about it there will be two classes of errors. Those that may reasonably be overwritten by everyone using the usual lintian override feature, and those that may not. (No maintainer name/address, files in /opt or /usr/local, that kind of). -- bye, Joerg exa Snow-Man: Please don't talk to me. You have demonstrated yourself sufficiently. There is a serious matter being talked. Snow-Man exa: It's hardly serious, it's about you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Le Sat, Jul 18, 2009 at 09:55:30AM +0200, Julien BLACHE a écrit : Or can I just override every lintian test and upload my totally broken package? Sure you can, yet you never did. Why? Do we have evidence that maintainers have damaged the project in the past by willingfully upload packages with overriden lintian errors? We have a whole range of procedure for dealing with maintainers whose behaviour is not pleasing the majority: - Whishlist bugs when it is a matter of taste. - Non-RC bugs when we think they are wrong. - RC bugs to protect our users. - The technical comittee when the problem can not be resolved by discussion. - The DMUP to remove upload rights of developers who upload damaging packages on purpose. - Expulsions procedures for developers that the Project do not trust after they harmed us or our users on purpose. I do not see where the systematic review of some lintian errors overrides at upload time by the FTP team fits there. Especially that there is no procedure for the resolution of disagreements, that we can expect to be time-consuming. And today, the NEW queue managed by four persons dedicating 5-10 hours per week to the Debian archive contains 265 packages, some of them waiting for one month or more. I disagree with their decision to self-appoint themselves with a new duty while they are already lacking time for the current one they volunteered for. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of stuffing the NEW queue with issues it was not designed for.
Le Fri, Jul 17, 2009 at 11:44:54AM +0200, Luk Claes a écrit : AFAIK the FTP Team is working on a system to prevent uploads which have lintian errors. The whole category of lintian errors has already been assessed and possible overrides are planned to arrive in the NEW queue at least once... Please do note that I'm talking about errors, not about warnings. Excellent news ! I was also thinking that there were not enough packages in the NEW queue and that uploads with lintian errors were causing too often critical bugs that needed immediate catching at upload time. Automatic rejection of packages with errors not justified by overrides is of course a good idea, but can we get to a compromise where the maintainer is free to take the responsibility to override errors? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
