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 <paultag@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
Attachment:
signature.asc
Description: Digital signature