On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille <andr...@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 <andr...@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 <ty...@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