[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))



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


Reply to: