Hi Paul and others,

its surely an interesting topic how to avoid binary name changes and its
also interesting to discuss ABI changes and workarounds.

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.

So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm
currently observing and I would be really happy if we can document the
policy for changed (and new) binary names of existing source packages.

To give another example which has nothing todo with ABI changes:
Currently I'm afraid of splitting some Arch: all data from some
Arch: any package since I'm simply afraid of the changed package
sticking long in new queue. I know this is bad - but I consider
users waiting for package updates worse.

Kind regards
Andreas.


[1] https://lists.debian.org/debian-devel/2021/07/msg00231.html

Am Mon, Jan 24, 2022 at 10:20:48AM +0800 schrieb Paul Wise:

On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:

That only works if there are no other packages depending on those
shared libraries which are coming from other source packages.

I don't think that is true, I believe you can put multiple things in
the depends section of an shlibs file and dpkg-shlibdeps will propagate
that to reverse dependencies just fine. From the manual pages it looks
like the same applies to the symbols files. I found on my system that
there are *already* packages that do something similar (see below).
...

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:

Hi Paul and others,

its surely an interesting topic how to avoid binary name changes and its
also interesting to discuss ABI changes and workarounds.

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.

As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released. As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior. A while back, people asked me I
could update f2fs-tools, and it was shortly before the release freeze,
and even though there was apparently security fixes involved that
would be fixed in the latest version of f2fs-tools, I knew there would
be no point, since there was no way the package would squirt out the
review pipeline before the release freeze.

Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.

- Ted

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 24, 2022 at 01:49:19PM -0500, Theodore Y. Ts'o wrote:

On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:

its surely an interesting topic how to avoid binary name changes and its also interesting to discuss ABI changes and workarounds.

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic.

As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released. As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior.

Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.

I like the earlier thread idea of de-coupling the copyright review
(eventually of NEW entirely? but for now, just bin NEW) from "the other
checks and balances". Ultimately, a mistake in debian/copyright *can* be
just considered a bug with priority determined just like any other, so
long as it is still legal for Debian to distribute. However, this is an
issue whenever upstream ships a new source file, not when a new binary
is added, so I hope that good maintainers do their due diligence on new upstream releases.

If that is agreed informally, then while a lottery review would be a
cool addition, it would not be a prerequisite to dropping its
requirement for sources which have already been accepted into the
archive once. This could be formalised via a GR empowering the FTP team.

That last has made me wonder if the ftp-master team could split the NEW
source queue into two phases, one where a copyright review is performed
and one where the other checks are. I can see pros and cons for either
way round these phases could be done, but one should feed into the
other. Presumably, that this has not already happened means there would
be little benefit because of context switching?

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYe/JuQAKCRDbymUJHySO bDpkAQC1iCuScu9XYkCkAl9asAKp+N7iNdNvFHtOY+wGUF2TJAEA1OKiqj8za7fy BmsiPZxw8yg0XFugK0AKrUML6bAtYw0=
=nysU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille <andreas@an3as.eu> wrote:

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.

So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm
currently observing and I would be really happy if we can document the
policy for changed (and new) binary names of existing source packages.

Since I feel my mail went lost in the discussion, here again my opinion:

Option C. New binary packages where the src is already in Debian can
still go through NEW for sanity checks, but do not require a
d/copyright review. These packages should be checked with priority
since they should be quick to review. Same goes for source packages
renames.

Instead, I suggest starting a "d/copyright review lottery" working
group with the goal to review the d/copyright of every package in
testing if changed since the last stable release, especially before
the next stable release. I would personally join this endeavor and
help to write tools to keep track of which packages are "eligible" for
the lottery.
This offloads a lot of work from the ftp-masters and in making regular d/copyright reviews for all packages split among project members
should also increase the quality of these.

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille <andreas@an3as.eu> wrote:

To give another example which has nothing todo with ABI changes:
Currently I'm afraid of splitting some Arch: all data from some
Arch: any package since I'm simply afraid of the changed package
sticking long in new queue. I know this is bad - but I consider
users waiting for package updates worse.

On Mon, Jan 24, 2022 at 7:49 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released. As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior. A while back, people asked me I
could update f2fs-tools, and it was shortly before the release freeze,
and even though there was apparently security fixes involved that
would be fixed in the latest version of f2fs-tools, I knew there would
be no point, since there was no way the package would squirt out the
review pipeline before the release freeze.

Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.

These are just two examples where the delay of updates in the NEW
queue affects the quality of a package or a Debian release - while it
should do the opposite. I'm sure there are many more, I'm not a DD for
a long time but I heard the "won't make improvement xyz because of the
NEW queue" argument regularly. IMHO if there is not a sudden increase
of review time from the ftp-masters, something needs to be done before
packages start losing quality due to NEW.

Regards,
Stephan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 25, 2022 at 10:50:01AM +0100, Stephan Lachnit wrote:

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille <andreas@an3as.eu> wrote:

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.

So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm currently observing and I would be really happy if we can document the policy for changed (and new) binary names of existing source packages.

Since I feel my mail went lost in the discussion, here again my opinion:

It's not been lost, there has been lots of discussion around the lottery
idea C, but in changing the email subject I believe Andreas is trying to
draw the distinction between the request to document *current* practice
and your subthread about possible improvements to the overall process.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYe/QCgAKCRDbymUJHySO bPYGAP9k0jBUpKoZxoWG7spPSC/89MSG7y++xSth72yBW9RcqgD+KlxSE9s4bmLp hqgdpeNGRbWRDz+7ceUhIXg4sCRS/w0=
=taqo
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)