Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Hi Mo,
Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:
> 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).
I have heard this argument and my mail was simply to find out what
fellow developers think about this. IMHO the issue is sufficiently
important to have some kind of documented consensus about this.
> 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.
I also heard that argument that passing the new queue is a good chance
to review d/copyright. But as you said it will never catch code that
never needs passing new queue again. So also here I would seek for
opinions since this argument is in conflict with my interpretation
of the said mail I was refering to[1].
> 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 agree that this solution possibly covers both sides. However my
question was a bit simpler since I wanted to find out whether we really
have supporters of both sides and how strong their arguments might be
for the respective side. Than we can document the issue and possibly
your suggestion might be an acceptable solution (if and only if we
realise that there are those conflicting opinions).
> > 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.
"Speculate" is the term we need to get rid of first. ;-)
This was my motivation to write the initial mail.
> 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.
I perfectly agree that we have a high probablility for outdated
d/copyright files in our archive. However, I would like to consider
this problem as orthogonal to the binary name change issue. It puts
an absolutely not rectified bias on those packages that are typically
changing binary packages frequently - at least I do not see any good
reason to prefer a package that by chance has a new binary name over
any other package inside the archive.
That's why I would rather consider to do a call for volunteers to
verify d/copyright files of *completely* random packages. I do not
see any point in putting this workload onto ftpmaster but may be as
a first interesting step to join the ftpmaster team.
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
--
http://fam-tille.de
Reply to: