Re: SONAME bumps (transitions) always via experimental
I should point out in case it wasn't clear that I'm in favour of this
proposal - I was enumerating all the possible problems I could see from
a devil's-advocate point of view, so that we can make sure there are
solutions to them, rather than trying to make it not happen.
On Mon, 09 Jan 2023 at 18:58:12 -0700, Sam Hartman wrote:
> I think what Paul, Simon and apparently I are asking for is that
> maintainers be able to explain why they are sending an upload that needs
> to go through new to unstable in the changelog and have ftpmaster
> consider whether their reason is good.
If this is a strong convention but not an automated rejection, and
maintainers have the opportunity to ask the ftp team to let it through
as a rare exception to the usual rule, then I personally think that's
an appropriate balance.
Unfortunately I think this probably can't be implemented as an
overridable Lintian autoreject, because Lintian's design is that it
doesn't know about any version of the package other than the one currently
being considered, so determining whether a package is NEW can't be done
within Lintian's scope.
> Also, I'm less convinced there's a good reason for source new uploads to
> target experimental.
> If it's a new package with entirely new binary packages, it shouldn't be
> involved in any transitions.
Equally, a new source package might take over existing binary package
names from older source packages (like my src:steam-installer upload
currently waiting in NEW, which takes over binary packages from src:steam,
or the recent transition in which src:pkgconf took over the pkg-config
name from src:pkg-config). I think it makes just as much sense to do
that via experimental as it would for a new SONAME. Also, if a package
is not in Debian at all yet, then asking its maintainer to upload it
to experimental as a default seems like a reasonable thing to ask for,
even if it's not necessary in all cases.
If it makes things easier for the ftp team, I would personally not
mind if we had an expectation that NEW packages *never* target unstable
(only ever experimental or some more specialized suite) unless there is
a specific reason why experimental can't be used, regardless of whether
the reason to be in NEW is a SONAME bump, an entirely new package, an
internal restructuring or anything else.
Requiring that for all NEW packages seems to me like it would only be
a small extra burden. If the package is otherwise ready for inclusion
in testing and all of its binary packages could be binNMU'd, then it
would need one extra source-only maintainer upload after acceptance that
isn't currently required. In all other cases, re-uploading to unstable
would be part of an upload that already needs to happen, so there's no
additional cost to the maintainer.
smcv
Reply to: