On Sun, 09 Mar 2025 at 19:32:32 +0800, Sean Whitton wrote:
IMO it is the maintainer's responsibility to ensure that NEW+unstable
together is always all installable, if you see what I mean.
Do I assume correctly that this principle can be weakened for
experimental-NEW?
As a general principle I think uploads to NEW that are more complicated
than a completely new leaf package should usually be to experimental,
unless there is a reason why this specific package can't (for example if
foo_2.0 is already in experimental and now the maintainer needs a
package-split or a new SONAME for foo_1.2 in unstable). A lot of the
time the NEW package will need a new sourceful upload after it's been
accepted *anyway*, to get a source-only upload that can migrate to
testing - and if the package is in binary-NEW because it has a new
SONAME, it's better to have the maintainer and not the ftp team be in
control of the point at which it hits unstable and starts a transition.
Does the ftp team agree with that as a general idea? And if a largeish
dependency graph needs uploading together, is it OK to upload them all
to experimental-NEW, with the idea that if the ftp team accepts them in
the wrong order they'll just sit in BD-Uninstallable status until the
whole batch has been processed, with no real harm done?
smcv
