(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
