On 05/09/14 17:48, Ian Jackson wrote:
> It is true that long NEW processing queues is a big problem. But it > appears that a substantial amount of core team effort is being used to > deal with poor submissions. If we can fix that, we can fix the long > queue. > This is really the root of the problem and I agree that it would be nice to find ways to help them. A solution is good for the FTP masters and good for the project. Another way to look at your proposal may be to compare it to alternatives (I'm not suggesting I personally agree with all of these, but they are just some things that come to mind): a) let people self-certify packages when they wrote 100% of the code themselves. People abusing this privilege would lose it. b) offer some facility for upstreams to certify their packages as 100% free software by completing a DEP-5-like template and signing it with the same key they use to sign their tags and release announcements. c) offer a paid review service. FTP masters and assistants can sell their time through an auction process. Uploaders and interested third parties can bid for packages to be reviewed. If they reject a package, it goes back to its original place in the queue unless somebody pays for them to spend more time on it. Some people may feel that this will deter the FTP masters from reviewing packages unless all uploaders start paying while other people may feel that this funding would give the FTP masters more time. Maybe the fee could include a surcharge of 33% to cover regular queue processing, so for every 3 packages that pay, one package is taken from the front of the queue as well? The rate of the surcharge could be variable to keep the backlog within a 2 week target range. d) the upload with binary JARs inside it was accepted by the NEW queue software. Maybe the scripts could be stricter about rejecting such packages before they reach FTP masters? Do the FTP masters publish statistics on rejections that could be used to identify the top things to scan and reject automatically? Are there other alternatives that people can think of? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5409e308.3080...@pocock.pro
