Re: NEW processing friction
On Mon, Feb 07, 2022 at 07:05:59PM -0700, Sean Whitton wrote:
> Hello,
>
> On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote:
>
> > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote:
> >>
> >> When we treat any of the above just like other RC bugs, we are accepting
> >> a lower likelihood that the bugs will be found, and also that they will
> >> be fixed....
> >
> > Another part of this discussion which shouldn't be lost is the
> > probabiltiy that these bugs will even *exist* (since if they don't
> > exist, they can't be found :-P) in the case where there is a NEW
> > binary package caused by a shared library version bump (and so we have
> > libflakey12 added and libflakey11 dropped as binary packages) and a
> > NEW source package.
>
> Which category of bugs do you mean? I distinguished three.
The argument why a package which has an upstream-induced shared
library version bump, has to go through the entire NEW gauntlent, is
because it is Good Thing that to check to see if it has any copyright
or licensing issue. But if you have a different package which doesn't
have upstream-induced shared library bump, it doesn't go throguh the
same kind of copyright and license hazing. And I believe this isn't
fair.
Either we should force every single package to go through a manual
copyright/licensing recheck, because Debian Cares(tm) about copyright,
or "copyright/licensing concerns are an existential threat to the
project" (I disagree with both arguments), or a package such as
libflakey which is going through constant shared library version bumps
should not go through the NEW gauntlet just because it has new binary
packages (libflakey11, libflakey12, libflakey13, etc.) at every single
upstream release.
- Ted
Reply to: