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

Re: NEW queue and ftp-master approval



Bartosz Fenski aka fEnIo <fenio@debian.org> writes:

> Hello.
>
> Our NEW queue is quite big and time needed to get package into unstable is
> rather long. Nothing wrong with that for me, I know that ftp-masters are 
> busy and that approving these packages is very important and responsible 
> task.
>
> But there are two kind of packages in NEW queue. 
>
> "Totally" new packages and old one that only incorporate new binary 
> package(s). These old packages has already source package in archive.
>
> I think the latter should be handled first, and then if ftp-master has
> some spare time he/she could handle totally new packages.

I think ftp-master already has a more complex prioritizing than
that. Adding a new kernel images deb tends to be real fast (with
exceptions), adding a new deb to old source reasonable fast and
completly new source can take forever if questionable (e.g. mplyer).

> Any comments on that?

Why is manual intervention needed at all?

On a recent discussion about this on irc several things were said that
have to be done for NEW packages, e.g. inform some U.S. government
agency about the new deb, add an override entry into the db. The only
thing that wasn't easily scriptable was:

ftp-master might reject the new package name


Someone said ftp-master might want to check the source for the NEW deb
but that would apply to any source upload just as well IMHO. Debian
already trusts DDs to not mess up existing debs so it should be simple
to trust them not to mess up when splitting debs or adding more to an
existing source.


Overall, in my eyes, the question becomes: Does Debian trust DDs not
to add debs with silly names to existing sources?

Why not automate the NEW queue for packages with prior source versions
in the archive? Worst case ftp-master has to remove a deb with silly
name from archive and kick the DD for it.

Correct me if I'm wrong.

> regards
> fEnIo

MfG
        Goswin



Reply to: