Re: Nitpicking in the NEW queue.
Hi Paul, Le Tue, Sep 03, 2013 at 09:12:42AM -0400, Paul Tagliamonte a écrit : README.Source would surely get my attention (as would README.Debian). Acutally, I do not know what is missing from README.Debian to justify the existence of this package. It runs a script each time a kernel package is installed or removed. I do not see which other package would be fit for these kernel hooks. We are going into circles: I still have no hint on what else I can do that I have not done before. I therefore re-uploaded with the following change. --- a/debian/copyright +++ b/debian/copyright @@ -1,6 +1,6 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -Files: debian/update-grub +Files: * If this bug in the machine-readable file was the only blocker, it would have helped a lot to have marked it as such in your rejection message. Otherwise, a policy about small packages would have been helpful. Cheers, -- 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 Archive: http://lists.debian.org/20130911021016.gb30...@falafel.plessy.net
Re: Nitpicking in the NEW queue.
(Long answer, but I promise to limit my messages in this thread). Le Mon, Sep 02, 2013 at 01:08:12PM -0400, Paul Tagliamonte a écrit : Yes. For the record, this day when Charles sent this mail, I was working in NEW from early in the morning to about 9:00 at night. I don't want thanks or even for people to care about such things, but to come home from the bar to such an email is annoying and makes me want to review NEW less. Hi Paul, first of all, please let me clarify that the reason why I answered on our core mailing list is not to fingerpoint if or not you are wrong, but becase this is the only way I have to see if others agree to my opinion that comments that are not critical to the suitability of a package for our archive should be left out. I also thank Andreas for his balanced proposition. Your involvement is very appreciated, but isn't what you wrote above an indication that something is going wrong ? Backlogs and long days lead to burnout, and experience shows that positive enthousiasm can also fuel burnouts. If there is so much work to do to keep our archive compliant with the law and our priciples on Free software, please let me suggest to defer other checks to other teams and automated systems. It does not mean that that your help or vision is not wanted or useful, it means that when a task reaches a given size, it needs to be undertaken with a more systematic approach. In particular, what I am complaining about (and I understand that complaining correctly is a difficult art in which I am not the most skilled) is clearly the result of the recurrent backlogs in the NEW queue and the shortage of time that can be spend on a package. You asked me if the scripts I packaged could not be part of another package, but the very first message of the ITP bug clearly showes that I already explored that possibility. Given that we need to wait for weeks to ensure that people had enough time to anwer, it took me months ! Also, the machine-readable Debian copyright file had a bug, which I again apologise for, but on the other hand, it contained each and every copyright statement that needed to be reproduced. What I am asking for is a predictable system. If ITP bugs will not be read, just document that fact proeminently somewhere, and if possible provide a workaround (like adding a temporary message in README.source ?). If a question is recurrent, having an entry in a checklist would be much appreciated. In that case it could be: For a native package containing less than X files, you must explain your reasons in the file debian/README.foo). Same for the files that, like OpenOffice documents, are in binary format, but in a format that is not as well recognised. Given that the NEW queue is often processed by batches, discussion about rejections tend to stop by loss of momentum, without solving the issues raised. For that reason, and to ensure predictability, I think that it is very important to have at least a clear separation between the blocking issues and the personal comments. In the case of pv-grub-menu, I am left with the questions What else shall I do that I have not tried yet ? How many weeks or monthes shall I try before giving up, which will waste time on your side and mine. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903084352.gd19...@falafel.plessy.net
Looking for ideas for merging a micro package... (was: Nitpicking in the NEW queue.)
Le 02/09/2013 06:12, Paul R. Tagliamonte a écrit : Respectfully - when we add micro (under Size 100 packages) the amount of metadata added to every mirror and every users machine is almost as much as the package contents. This is a very common request (make sure this really needs to be split out ) and not even the reason for this reject. My new pagemap package have recently been rejected being a small package. Indeed, it is a small script, wrote in ruby, that use /proc/PID/pagemap binary files (and a few other from /sys) and display in text the mapping between physical and virtual memory. When working on NUMA system, it can sometimes be a useful tool to analyze the performances of HPC programs. Never mind. My current problem is that I have no idea which current package to contact to ask for a inclusion. It is not important enough to be included in packages such as util-linux and few (no?) system/devel packages already have a dependency on ruby (ie adding the pagemap script would add a dependency on ruby). Any idea? Regards, Vincent sources: dget http://people.debian.org/~vdanjean/debian/pool/main/p/pagemap/pagemap_1.1-3.dsc binary: http://people.debian.org/~vdanjean/debian/pool/main/p/pagemap/pagemap_1.1-3_all.deb -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5225a308.2080...@free.fr
Re: Nitpicking in the NEW queue.
Reading Charles' mail I had a thought; how about accepting buggy packages (unless the issues make them non-distributable) and file RC and other bugs if there are DFSG or other issues? -- 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 Archive: http://lists.debian.org/caktje6h+flbo4vrq4fe4sh4ct3qs-yjtowtwwg9hdy6def8...@mail.gmail.com
Re: Looking for ideas for merging a micro package... (was: Nitpicking in the NEW queue.)
On Tue, Sep 3, 2013 at 10:51 AM, Vincent Danjean wrote: Never mind. My current problem is that I have no idea which current package to contact to ask for a inclusion. It is not important enough to be included in packages such as util-linux and few (no?) system/devel packages already have a dependency on ruby (ie adding the pagemap script would add a dependency on ruby). I would suggest inclusion in util-linux is the way forward, possibly with a rewrite in C or whatever languages are accepted in util-linux. -- 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 Archive: http://lists.debian.org/caktje6eyoxxwxmu-ad9b4a4h3pluqchxqm6q2mfnjrxphhx...@mail.gmail.com
Re: Nitpicking in the NEW queue.
2013/9/3 Paul Wise p...@debian.org: Reading Charles' mail I had a thought; how about accepting buggy packages (unless the issues make them non-distributable) and file RC and other bugs if there are DFSG or other issues? Although this could be possible, a second upload would be needed anyway (hopefully in a very short timeframe), so reuploading a fixed package to NEW would avoid wasting bandwith and disk space on mirrors and snapshot.d.o. Usually, rejected packages are fast-tracked when reuploaded to avoid letting them slip at the bottom of the queue. Simply reply to rejection mail (or ping us in IRC) informing us a fixed package has been reuploaded to the NEW queue. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0p3tqwt6_ssqq3ygpen7aonsrgqkscwkv8tf7bvr-r...@mail.gmail.com
Re: Nitpicking in the NEW queue.
Paul Wise wrote: Reading Charles' mail I had a thought; how about accepting buggy packages (unless the issues make them non-distributable) and file RC and other bugs if there are DFSG or other issues? Why should we rush to let more broken stuff into the archive? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vgq3g-0007aw...@mail.einval.com
Re: Nitpicking in the NEW queue.
Hey Charles, On Tue, Sep 03, 2013 at 05:43:52PM +0900, Charles Plessy wrote: Hi Paul, first of all, please let me clarify that the reason why I answered on our core mailing list is not to fingerpoint if or not you are wrong, but becase this is the only way I have to see if others agree to my opinion that comments that are not critical to the suitability of a package for our archive should be left out. I also thank Andreas for his balanced proposition. Your involvement is very appreciated, but isn't what you wrote above an Thank you. indication that something is going wrong ? Backlogs and long days lead to burnout, and experience shows that positive enthousiasm can also fuel burnouts. This is true. I've burned out (and seen my friends) of Ubuntu work quite a few times, I'm sadly aware of the problem. If there is so much work to do to keep our archive compliant with the law and our priciples on Free software, please let me suggest to defer other checks to other teams and automated systems. It does not mean that that your help or See, this is an interesting proposal. The issue is we *do* have a system for doing this -- Lintian autorejects. If something is really this easy to detect with automated systems, it should be added to Lintian, and set as an autoreject tag. The problem is, figuring out what the prefered form of modification is is a hard problem, and needs a human judgement call. A lot of this stuff is a grey area, so a human making the decision means that there's at least a sound Debian-ish argument behind the decision (that perhaps is in line with the *spirit* of the Project) In addition the DFSG are a set of Guidelines (see the G), so appling judgement to what is or isn't DFSG free is also something we need a human to decide. So, yes. It would be nice to get robot overloads to do this work. However, I'm not sure *I* (personally) would like such cold black-and-white logic behind something that's a bit of a grey area. vision is not wanted or useful, it means that when a task reaches a given size, it needs to be undertaken with a more systematic approach. In particular, what I am complaining about (and I understand that complaining correctly is a difficult art in which I am not the most skilled) is clearly the result of the recurrent backlogs in the NEW queue and the shortage of time that can be spend on a package. You asked me if the scripts I packaged could not be part of another package, but the very first message of the ITP bug clearly showes that I already explored that possibility. Given that we need to wait So, we have two fun issues here -- I both nitpick and don't research enough :) The issue is that I'm not going to go and make sure you're closing all the right bugs and your diff is as clean as it should be -- that's not my job. I'm not going to pull up every ITP, because I assume the research for which ITP to be closed was done. for weeks to ensure that people had enough time to anwer, it took me months ! Also, the machine-readable Debian copyright file had a bug, which I again apologise for, but on the other hand, it contained each and every copyright statement that needed to be reproduced. What I am asking for is a predictable system. If ITP bugs will not be read, just document that fact proeminently somewhere, and if possible provide a workaround (like adding a temporary message in README.source ?). If a question README.Source would surely get my attention (as would README.Debian). is recurrent, having an entry in a checklist would be much appreciated. In that case it could be: For a native package containing less than X files, you must explain your reasons in the file debian/README.foo). Same for the files that, like OpenOffice documents, are in binary format, but in a format that is not as well recognised. I don't REJECT micro packages for fun, I just want to make sure that the maintainer has done their homework, and understands the tradeoffs in adding such a package for our users and mirrors. If you'll notice, I asked a question, not a statement. If there's a reason why (as you say wrote in the ITP (I've still not opened it yet)), you could have replied with that. No one here is trying to Keep the masses down :) Given that the NEW queue is often processed by batches, discussion about rejections tend to stop by loss of momentum, without solving the issues raised. For that reason, and to ensure predictability, I think that it is very important to have at least a clear separation between the blocking issues and the personal comments. In the case of pv-grub-menu, I am left with the questions What else shall I do that I have not tried yet ? How many weeks or monthes shall I try before giving up, which will waste time on your side and mine. You know, you can reply to ftpmaster@ about the REJECT to *ask* about such things. We're usually friendly. Cheers, Paul -- .''`. Paul Tagliamonte
Re: Nitpicking in the NEW queue.
On Tue, 03 Sep 2013, Luca Falavigna wrote: 2013/9/3 Paul Wise p...@debian.org: Reading Charles' mail I had a thought; how about accepting buggy packages (unless the issues make them non-distributable) and file RC and other bugs if there are DFSG or other issues? Although this could be possible, a second upload would be needed anyway (hopefully in a very short timeframe), so reuploading a fixed package to NEW would avoid wasting bandwith and disk space on mirrors and snapshot.d.o. Usually, rejected packages are fast-tracked when reuploaded to avoid letting them slip at the bottom of the queue. Simply reply to rejection mail (or ping us in IRC) informing us a fixed package has been reuploaded to the NEW queue. This is not a good trade off. You're loosing out valuable ftpmasters time for minor bandwith and disk issues (that kind of supplementary upload will not change much in the global amount of bandwith and disk consumed). I find pabs's idea rather good. And if you really care about a second check, you can do that once you get the bug closure notification. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903134756.gd30...@x230-buxy.home.ouaza.com
Re: Nitpicking in the NEW queue.
Raphael Hertzog hert...@debian.org writes: On Tue, 03 Sep 2013, Luca Falavigna wrote: 2013/9/3 Paul Wise p...@debian.org: Reading Charles' mail I had a thought; how about accepting buggy packages (unless the issues make them non-distributable) and file RC and other bugs if there are DFSG or other issues? Although this could be possible, a second upload would be needed anyway (hopefully in a very short timeframe), so reuploading a fixed package to NEW would avoid wasting bandwith and disk space on mirrors and snapshot.d.o. Usually, rejected packages are fast-tracked when reuploaded to avoid letting them slip at the bottom of the queue. Simply reply to rejection mail (or ping us in IRC) informing us a fixed package has been reuploaded to the NEW queue. This is not a good trade off. You're loosing out valuable ftpmasters time for minor bandwith and disk issues (that kind of supplementary upload will not change much in the global amount of bandwith and disk consumed). I find pabs's idea rather good. And if you really care about a second check, you can do that once you get the bug closure notification. I disagree. A second review by the same ftpmaster is usually fast and painless and requires less time and effort overall than doing the bug handling dance. I've done both, and my experience so far was that REJECT+reupload worked much better in most cases. That it also keeps the archive a tinsy bit cleaner is just an added bonus. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hae20w2u.fsf@algernon.balabit
Re: Nitpicking in the NEW queue.
Hi! On 09/02/2013 06:04 AM, Scott Kitterman wrote: It would have been nice if you'd done such an inspection before you uploaded and wasted the ftp-team's time doing multiple reviews. I fully agree. I don't think it's a bad thing at all to thoroughly check the package, even for minor problems. I do that myself when sponsoring packages from mentors and I am very glad for the hard work the FTP team does actually reviewing that huge list of packages that is constantly in NEW and not just passing them through. Conveniently, you have elided the actual rejection reason from your message to -devel and gone off on a rant about about something that was raised as a reasonable question. Yep, this is otherwise just an unbalanced, unreflected rant. If you want to kick off a discussion, please let us actually know what the FTP team's answer was. If you would prefer we not ask the maintainers questions when we have them, perhaps you would like it better if we put such packages aside and leave them in New until we have time to fully research them? Absolutely. People who think that packages in NEW should just be passed through and accepted into the archive haven't really understood the point of the NEW queue. Please just answer the question, fix your package, and quite harassing someone who's trying to do work that's important to the project and doesn't need your demotivational speeches. Adding to this. I know Paul personally very well and I don't think that he'd maliciously reject a package. He takes his job as an FTP master very seriously and I am pretty sure that he is also not leaving cheap comments but rather suggestions to help improve the package and get it into shape for the archive. If he rejects a package, there is a very good reason why he did so and there is certainly also a reasonable explanation that he provided. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52247898.90...@physik.fu-berlin.de
Re: Nitpicking in the NEW queue.
Hi Paul, On Mon, Sep 02, 2013 at 12:12:09AM -0400, Paul R. Tagliamonte wrote: I would like that the FTP team please refrain from giving cheap side comments Um.. or ask cheap questions in its rejection emails (have you noticed that the ITP bug was originally submitted as a wishlist addition to another package ?) and These cheep comments are intended to be helpful. I'm sorry you don't appreciate it, but folks are usually thankful for the second pair of eyes on the changes. Please keep up with your helpful comments even when nitpicking! While lacking the full context (no quote of the original mail) I just can wild guess that possibly a similar thing might have happened as it was some time ago in one of my packages: In the first place I was overlooking the real problem which was mentioned in a short sentence after a more verbose minor comment about spelling. While I really like your comments it might perhaps cause less friction (and avoid mails like those from Charles) when you would tag your mail like: Rejection reason / major problem: ... Additional hint (not relevant for accepting): ... or something like this. Thanks for your work on the NEW queue Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130902130338.gi21...@an3as.eu
Re: Nitpicking in the NEW queue.
On 09/02/2013 07:38 PM, John Paul Adrian Glaubitz wrote: Adding to this. I know Paul personally very well and I don't think that he'd maliciously reject a package. I don't think so either. Though what happens is that Charles is being frustrated because of the current waiting time in the NEW queue (and it clearly shows in his mail). If it was like before November 2012 (eg: less than a week for a review), then it wouldn't happen, IMO. I've been very happy to see that there was more people accepted in the team in order to help solving this problem. Let's just hope that it will work out better in the near future, and reduce the frustration of everyone facing issues with the current delay. The graph of the NEW package count shows there's an ongoing effort for this. BTW, we always know who rejects a package. Though it'd be nice to also know in the ACCEPTED message who did it (for example we could send thanks for the work of reviewing an upload). Has the FTP master team thought about that? Or is there reasons why you want to stay anonymous? (or perhaps nobody has time to work on that futile feature?) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5224c106.50...@debian.org
Re: Nitpicking in the NEW queue.
On Tue, Sep 03, 2013 at 12:47:02AM +0800, Thomas Goirand wrote: On 09/02/2013 07:38 PM, John Paul Adrian Glaubitz wrote: Adding to this. I know Paul personally very well and I don't think that he'd maliciously reject a package. I don't think so either. Though what happens is that Charles is being frustrated because of the current waiting time in the NEW queue (and it clearly shows in his mail). If it was like before November 2012 (eg: less than a week for a review), then it wouldn't happen, IMO. I've been very happy to see that there was more people accepted in the team in order to help solving this problem. Let's just hope that it will work out better in the near future, and reduce the frustration of everyone facing issues with the current delay. The graph of the NEW package count shows there's an ongoing effort for this. Yes. For the record, this day when Charles sent this mail, I was working in NEW from early in the morning to about 9:00 at night. I don't want thanks or even for people to care about such things, but to come home from the bar to such an email is annoying and makes me want to review NEW less. The package count went from over 300 on Friday to under 180 this mornig (I saw some processing by other ftpteam members too, so that wasn't just me). This is being worked on, and the ftpteam is working hard to review packages in a timely way. BTW, we always know who rejects a package. Though it'd be nice to also know in the ACCEPTED message who did it (for example we could send thanks for the work of reviewing an upload). Has the FTP master team thought about that? Or is there reasons why you want to stay anonymous? (or perhaps nobody has time to work on that futile feature?) I don't mind staying anonymous, none of us are doing this to get rich or famous, we're just here to make sure the archive stays safe sane. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5224c106.50...@debian.org Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Nitpicking in the NEW queue.
Answering on a broader audience because I think that there is really a drift from ensuring archive integrity to massive and arbitrary top-down nitpicking. Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a écrit : Hello, maintainer, I'm sorry, but I've rejected your package. [...] This package is also really small, is there no other package this fits into? Hi Paul, you have to understand how demotivating and infuriating it is to bounce from people who think that these files should not be in their package to people who think that these files should be in somebody else's package, with multi-week waiting times or waiting lines in between the answers. Earlier this year, I had another rejection email where I was asked to by the way clean some emacs backups or whatever from the Upstream tarball. It is a matter of taste. How do these comments guide us to undestand if the next upload will be rejected or not ? I would like that the FTP team please refrain from giving cheap side comments or ask cheap questions in its rejection emails (have you noticed that the ITP bug was originally submitted as a wishlist addition to another package ?) and stick to what makes the package fit or not fit for our archive. Is a small package acceptable, yes or no, where do you draw the line, and please assume that the uploader acted responsibly, or if not, check first the facts before asking. PS: While I apologise for my error in the Debian copyright file, please note that a quick inspection of the package could have shown you that replacing the current content of the Files field by * would have solved the problem entirely. I will re-upload when I have time. Cheers, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130902025841.gd8...@falafel.plessy.net
Re: Nitpicking in the NEW queue.
On Monday, September 02, 2013 11:58:41 Charles Plessy wrote: Answering on a broader audience because I think that there is really a drift from ensuring archive integrity to massive and arbitrary top-down nitpicking. Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a écrit : Hello, maintainer, I'm sorry, but I've rejected your package. [...] This package is also really small, is there no other package this fits into? Hi Paul, you have to understand how demotivating and infuriating it is to bounce from people who think that these files should not be in their package to people who think that these files should be in somebody else's package, with multi-week waiting times or waiting lines in between the answers. Earlier this year, I had another rejection email where I was asked to by the way clean some emacs backups or whatever from the Upstream tarball. It is a matter of taste. How do these comments guide us to undestand if the next upload will be rejected or not ? I would like that the FTP team please refrain from giving cheap side comments or ask cheap questions in its rejection emails (have you noticed that the ITP bug was originally submitted as a wishlist addition to another package ?) and stick to what makes the package fit or not fit for our archive. Is a small package acceptable, yes or no, where do you draw the line, and please assume that the uploader acted responsibly, or if not, check first the facts before asking. PS: While I apologise for my error in the Debian copyright file, please note that a quick inspection of the package could have shown you that replacing the current content of the Files field by * would have solved the problem entirely. I will re-upload when I have time. It would have been nice if you'd done such an inspection before you uploaded and wasted the ftp-team's time doing multiple reviews. Conveniently, you have elided the actual rejection reason from your message to -devel and gone off on a rant about about something that was raised as a reasonable question. If you would prefer we not ask the maintainers questions when we have them, perhaps you would like it better if we put such packages aside and leave them in New until we have time to fully research them? I didn't think so. Please just answer the question, fix your package, and quite harassing someone who's trying to do work that's important to the project and doesn't need your demotivational speeches. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4523068.he7bHlQMSZ@scott-latitude-e6320
Re: Nitpicking in the NEW queue.
On my phone, excuse the Cc and (I'm guessing HTML mail) Hi, Charles. On Sep 1, 2013 10:59 PM, Charles Plessy ple...@debian.org wrote: Answering on a broader audience because I think that there is really a drift from ensuring archive integrity to massive and arbitrary top-down nitpicking. Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a écrit : Hello, maintainer, I'm sorry, but I've rejected your package. [...] This ... Is why I rejected the package. You didn't have copyright noted for any files in the package (and noted a file that didn't exist) This package is also really small, is there no other package this fits into? Hi Paul, you have to understand how demotivating and infuriating it is to bounce from people who think that these files should not be in their package to people who think that these files should be in somebody else's package, with multi-week waiting times or waiting lines in between the answers. Respectfully - when we add micro (under Size 100 packages) the amount of metadata added to every mirror and every users machine is almost as much as the package contents. This is a very common request (make sure this really needs to be split out ) and not even the reason for this reject. Earlier this year, I had another rejection email where I was asked to by the way clean some emacs backups or whatever from the Upstream tarball. It is a matter of taste. How do these comments guide us to undestand if the next upload will be rejected or not ? I would like that the FTP team please refrain from giving cheap side comments Um.. or ask cheap questions in its rejection emails (have you noticed that the ITP bug was originally submitted as a wishlist addition to another package ?) and These cheep comments are intended to be helpful. I'm sorry you don't appreciate it, but folks are usually thankful for the second pair of eyes on the changes. stick to what makes the package fit or not fit for our archive. Is a small package acceptable, yes or no, where do you draw the line, and please assume that the uploader acted responsibly, or if not, check first the facts before asking. PS: While I apologise for my error in the Debian copyright file, please note that a quick inspection of the package could have shown you that replacing the current content of the Files field by * would have solved the problem entirely. I will re-upload when I have time. Cheers, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130902025841.gd8...@falafel.plessy.net
