[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan

Reply to: