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