Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Hi Andreas,
Thank you for mentioning this. Your post inspired me to came up a
new choice.
On Fri, 2022-01-21 at 11:33 +0100, Andreas Tille wrote:
>
> This recently happed for me in the case of onetbb (which was not
> uploaded by myself - so I'm not even asking for myself while other
> packages of mine (new ones and ones with just renames) are waiting in
> the queue.) There are lots of other packages (namely numba and lots
> of
> other packages depending from numba that FTBFS) depending from onetbb
> -
> thus I pinged on #debian-ftp more than once (which I really hate).
When I was once an ftp-trainee (now I'm not in ftp-team), there was no
popcon query when doing dak review. Whether a package is of high
priority depends on one's experience to some extent. Even if I knew
some packages must have a high popcon, their bulky size make the
review process (checking files one by one) not quite easy.
> Due to this I'd like to have a clear statement here (which would
> prove myself in pinging either right or wrong and thus I'm asking):
>
> A. Packages with new binary package names should not undergo
> the copyright inspection by ftpmaster and can be
> auto-approved (either technically or manually)
>
> B. Any package in the new queue needs to be inspected by
> ftpmaster for copyright issues and it takes as long as
> it takes no matter whether it is a new package or a
> package with changed binary name.
>
I'd rather propose choice C. Because I to some extent understand
both sides who support either A or B. I maintain bulky C++ packages,
and I also had a little experience reviewing packages on behalf of
ftp-team.
A -- Some (e.g. C++) packages may frequently enter the NEW queue,
with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs
feel it is not necessary for frequently because it drastically
slows down the maintainer's work. In the worst case, when the
package finally passed the NEW queue, the maintainer may have
to go through NEW queue again upon the next upload. (This is very
likely to happen for tensorflow, etc).
B -- Uploads with OLD src and OLD bin are not required to go through
NEW queue, even if a decade as passed as long as the src names and
bin names are kept unchanged. One of the supports for B is that
the d/copyright file may silently rot (get outdated), as uploads
without updated d/copyright won't be rejected. Checking packages
when they bump SOVERSION is to some extent a "periodical" check.
This worked very well for packages with stable ABI. But for pacakges
without stable ABI, especially bulky (C++) packages, this is
painful for both uploaders and ftp checkers.
Given the understanding of both options, I propose choice C:
C. Lottery NEW queue:
if (src is new):
# completely new package
require manual-review
elif (src is old) but (bin is new):
if not-checked-since-last-stable-release:
# approximate advantage of choice B.
require manual-review
elif src.version already exists in archive
# choice A wants to avoid this case.
auto-accept
else:
if (lottery := random()) < threshold
require manual-review
else:
# I expect a faster pace of debian development.
auto-accept
In this way concerns for both people supporting A and B can be partly
addressed. The old-src-new-bin case have a large chance to pass NEW
as long as they have been reviewed once after the last stable release.
The burden for ftp-team can be reduced. And pace of maitnainers can
be faster with less chance of being blocked and unstable to do anything
but wait.
> I would love to have this clearly documented since in case B. I would
> stop wasting my and ftpmaster time with nagging which is not
> rectified
> than.
>
> I personally clearly prefer A. and I wish we could clarify this
> situation.
Me too. I perfer A personally as well. Debian might be the only major
distribution which checks the license so thoroughly. Unconditionally
allow an old-src-new-bin upload to pass is basically impossible, I
speculate. Choice C might be more practical and feasible.
It must be many outdated d/copyright in our archive. Letting eligible
uploads automatically pass with a high probability is not likely
causing problem even if yet another outdated d/copyright sneaked in.
> Kind regards
>
> Andreas.
>
> [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html
> [2] https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html
>
Reply to: