Re: NEW handling ...
On Fri, Mar 18, 2005 at 09:06:10AM +1100, Matthew Palmer wrote:
> On Thu, Mar 17, 2005 at 10:15:50PM +0100, Sven Luther wrote:
> > 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.
So ? Mistakes happen, and people learn from them. The current lesson on gets
from this whole mess is to not upload packages which requiere NEW processing.
> 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.
Ok, but not-really-new packages are package who where already in the past in
the archive, so this kind of argument is invalid. I mean why reject a package
for such bases just because the documentation was split out, or the library
got a new soname and thus following policy the source package name needs
renaming. They may deserve an RC bug, but not NEW.
> 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.
so what, this is hardly relevant to what we are discussing here.
> 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.
so what, define clear rules on what is or not acceptable for package split
library/kernel renaming due to new version, and automate it.
> > > 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?
If the NEW queue handling people can't get the job done, then they should
recruit more people to help out on this instead of making the whole project
suffer from their lack of disponibility.
> > 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.
we can start with :
1) packages whose source name did not change. these should be basically ok.
we check that the amount of binary packages did not grow beyond a given
threshold => 20-50 % maybe.
2) packages whose sole modification is the addition or modification of their
version or soname-number are autoaccepted, and maybe older versions are
marked as candidates for removal.
This would probably catch most of those 70 packages waiting currently in NEW
and which right now require manual processing and scarcely available
ftp-master time.
> > 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.
well, if i adapt code or provide patches, it is preferably in a language i
know. Perl and python are not among those, so ... This is no critic to the
languages chosen, just a maybe inadequacy of myself proposing patches.
Friendly,
Sven Luther
Reply to: