On Friday, January 21, 2022 12:19:12 PM EST Andreas Tille wrote: > Hi Mo, > > Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou: > > I'd rather propose choice C. Because I to some extent understand > > both sides who support either A or B. I maintain bulky C++ packages, > > and I also had a little experience reviewing packages on behalf of > > ftp-team. > > > > A -- Some (e.g. C++) packages may frequently enter the NEW queue, > > with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs > > feel it is not necessary for frequently because it drastically > > slows down the maintainer's work. In the worst case, when the > > package finally passed the NEW queue, the maintainer may have > > to go through NEW queue again upon the next upload. (This is very > > likely to happen for tensorflow, etc). > > I have heard this argument and my mail was simply to find out what > fellow developers think about this. IMHO the issue is sufficiently > important to have some kind of documented consensus about this. Speaking only for myself, not the FTP Team. There are other considerations. Here's a few I thought of without investing a lot of time in it (not necessarily comprehensive): 1. When the SO name changes and the binary package name is adjusted accordingly, it is not super rare for the maintainer to mess something up in the renaming and end up with an empty binary package, which does no one any good. I note that for debhelper compat 15 there appears to be some related work in progress. Perhaps this is, or can be extended to be, sufficient to eventually make this kind of error a thing of the past. 2. New binary package "steals" binary from another source. This is sometimes OK. Sometimes it's accidental. It could also be malicious (I don't remember if I've every actually seen this done for an intentional "steal" or not, I might have). 3. New package added for reasons that make sense to the maintainer, but not for the archive as a whole. I've seen this come up multiple times, usually in the context of the binary being too trivial (which is a judgment call). It's not just let's do extra copyright/license checks. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.