Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
2013/4/1 Rene Engelhard <rene@debian.org>:
> True for unstable, not for experimental, Because stuff uploading to experimental
> can cause a transition if uploaded to unstable, yes - for *jessie*.
Most of the packages introducing new transitions were accepted, if
targeted experimental. A lot are still in the queue, though. The
"rationale" will follow shortly.
> Of course if mallicous or careless maintainers uploaded to unstable.. *shrugs*
True, and currently it's not possible to block those. But TTBOMK, only
a very few cases happened, and fortunately it was not to crack the
game.
> I understand that, *if* comments were needed. But that's not the case always.
>
> Some were stuck there and gor rejedted after 2 months. That specific
> exmple was needed to make a transition which *will* happen in jessie
> _less painless_.
Comments and rejects are issued during package review. Most of the
packages are accepted without remarks, some of them have a longer
path. I know the frustration of waiting for two months or more, and
then having your package rejected for just a few comments, but that is
why the NEW queue is in place, and maintainers sometimes have to face
a "try again".
> And this isn't a explanation for *completely new*, (and thus no r-deps,
> thus no transition) packages.
>
> (And no, I didn't get a comment.)
As I outlined in my previous message, we're in a phase in which we
receive more packages than we're able to process, due to internal
factors (our team is made of five members, while active developers are
about five hundred), or external (some of us have been busy elsewhere,
rationales are better explained in other mailinglists). binary-NEW
packages are usually processed first due to dak sorting, and the NEW
queue is not generally processed as FIFO, so it can happen a package
is processed way later even if it has been uploaded earlier.
>> On the other hand, FTP Team is willing to fast-track NEW packages anytime,
>
> I know, and afaicr I went this way (or /query ansgar), too and I am very
> grateful for that.
>
> It's more cumbersome than it needs to be, though.
In a perfect world there wouldn't be any need for a NEW queue at all.
But we have to face with the reality.
We try to do our best to improve things where we can. From the FTP
Team side, we always try to be quick and helpful with our fellow
developers, and are happy to hear about suggestions how to improve
further. On the other hand, please bear with us a little more when
packages are not processed so quickly. FTP Team is not just pressing a
button.
Cheers,
Luca
Reply to: