Re: Bits from ftp-team (aka: Don't upload RC fixes to NEW queue)

[Alexander Reichle-Schmehl <tolimar@debian.org>]

Hi!

Am 31.10.2010 22:42, schrieb Lucas Nussbaum:

>> [..] For example, work on things that are not entirely release critical,
>> like processing the NEW queue [2], are not the highest priority currently. [..]

> I must admit that I'm not too happy about that.

Neither are we.  However, unless someone reacts on our constant "we want
more members in the team"-mails, I fear there's not much we can do.

Please note that we see your arguments and agree completely, but please
also note it's not as easy as it sounds.  IIRC recently PostgreSQL 9.x
was accepted, resulting in some packages not being able to migrate to
testing.

I think there's has already been the case, that a ABI breaking library
was accepted to experimental (hey, it was only experimental, was it?),
and later uploaded by the maintainer to unstable, leading to unpleasant
results as well.  (Granted, not during this freeze.)

So, I can choose between helping the release by trying to fix some RC
bugs, or getting kicked by the release team for accepting $package, I
usually choose the former ;)


> Finally, as DDs, we sometimes have a responsibility towards our upstreams:
> if an upstream says "could you upload that new RC release to Debian
> experimental so we can see if the porting issues were correctly fixed?",
> it's a bit annoying to have to take long NEW delays into account.

Just for the record:  I consider that a legitimate reason to ask for the
package to be fast tracked.


> So I really think that long delays in NEW processing[1] are annoying and
> harmful, whether we are in freeze or not, and that the fact that NEW
> packages being processed won't end up in squeeze is not really a good
> reason for not processing them.

Just for the record 2:  Before the freeze, we weren’t that bad (beside
some problematic packages, which indeed waited far to long), and most
packages where processed within days (and sometimes even hours).


>> This also means that we might not notice a package fixing RC bugs in the NEW
>> queue.
> I would have loved to say that UDD already can give you a list of
> packages in NEW fixing RC bugs, but unfortunately, there's a small bug
> in the way the NEW status is imported that prevents that.

There's a dak patch floating around, which will hi light packages fixing
RC bugs in the output of http://ftp-master.debian.org/new.html.  So it
will become easier to spot the important packages to accept immediately
(which will still be no excuse for fixing your RC bugs in NEW ;)


> AFAIK, the main reason for NEW processing is the legal verification.
> For new binary packages, legal verifications are out of the picture,
> so couldn't you use the information provided by the maintainer in the
> control files, accept the package immediately, and do verification a
> posteriori ?

As the whole point of NEW processing is to decide whether we are in the
legal position to distribute the uploaded package, I fear it won't be
possible to do that after we already did so.


Best regards,
  Alexander, who promises to spent some more time on NEW processing in
the coming weeks, but points out, that still more volunteers are needed