On Thu, Mar 17, 2005 at 10:15:50PM +0100, Sven Luther wrote: > On Thu, Mar 17, 2005 at 07:57:11PM +0100, Joerg Jaspert wrote: > > On 10231 March 1977, Sven Luther wrote: > > > > >> - check that the package names are sane, don't conflict, and > > >> aren't gratuitiously many (a -doc package for 10 kbytes of > > >> documentation...) (what's the current opinion on that, anyway?) > > > Don't you think maintainers are big enough to know how to handle this kind of > > > decisions ? > > > > NO. > > For many of them this is a clear no. Unfortunately. > > To know in how many packages to split or not to split the packages ? That would be one of the things that maintainers have gotten wrong in the past, yes. There's also been (to my personal knowledge, since I perpetrated examples of these crimes) problems with debian/copyright where neither a copy of the licence (nor a reference to /usr/share/common-licenses/) under which a package was under weren't listed, and also an issue of section. In each case an ftpmaster (known as Cap'n Satan to some people, apparently) politely explained the problem to me an helped me to rectify the problem. The ftpmasters have also had to deal with blatantly non-free stuff trying to be put into main, dangerously patent-encumbered stuff going into main, and all forms of bloated and unimpressive stuff floating by. For an indication of the sorts of cruft that gets uploaded, take a walk through merkel.debian.org:/org/ftp.debian.org/queue/reject/*.reason. These are the ones that got caught automatically -- but if maintainers can have these sorts of accidents, I see no reason to believe they'll be any more successful stopping other sorts of accidents. > > Automated NEW is IMO a thing we should never do. > > Semi-automated was the proposal, with a delayed acceptance (a week or so) > where the ftp-masters can take positive action to prevent the automated NEW > handling. No risk, if a packages is exageratedly splitted, they get the email > about it, notice it is exageratedly splitted, and veto it, and normal NEW > behavior follows. Would you be happy if the ftpmasters put everything on auto-veto if there was nobody available to monitor the auto-new queue for a few days? > We could even imagine an automated analysis, which would differentiate > unproblematic modifications (a few new packages of moderate size for example), > or policy-mandated NEW (same packages with just a different ABI version > number, or a new kernel package), and provide them to ftp-masters via email > and a keyword in the subject allowing this classification and easy filtering > of problematic packages. I can imagine it, but the heuristics would be tricky at best. But I'm sure you'll have a nicely working demo shortly. > Mmm, i will try to find time to flesh out this proposal and propose code for > it. Now if the existing code was written in a reasonable language :) I prefer other people's python to other people's perl. - Matt
Attachment:
signature.asc
Description: Digital signature