On Mon, 09 Feb 2026 at 20:21:08 +0100, gregor herrmann wrote:
On Mon, 09 Feb 2026 13:29:44 +0000, Sean Whitton wrote:
We don't think you need explicit approval from your co-maintainers
anymore. Your upload workflows can be different to your teammates.
They can be using dput, dgit or tag2upload.
This surprises me a bit: Back in July I had described a scenario for
teams which might be problematic, and you seemed to agree at this
point:
https://lists.debian.org/debian-perl/2025/07/msg00027.html
Has anything changed since then wrt to this constellation?
I hope that maintainers and team members are aware of whether their team
uses specific tarball artifacts in the original spirit of the "orig"
tarball (most likely with pristine-tar or pristine-lfs, or perhaps
manually-managed), or whether their team uses any `git archive` output
that is "tree-same" to what upstream releases as some git-centric
developers advocate.
(Neither of these choices will make everyone happy, and I'm sure some
developers on each side of this divide already hate me for implying that
there is a choice to be made, but hopefully there's a majority in the
middle that is willing to accept the idea that there are two or more
reasonable possibilities.)
For teams that use tarball artifacts, the rule I've been following for
my own uploads is: first upload of a new upstream (usually revision 1)
has to include the desired tarball artifact (e.g. with `dgit
push-source` or traditional debsign/dput), but second and subsequent
uploads can be with `git debpush` (tag2upload).
I believe `git debpush` will usually stop you from uploading a new
upstream release if a pristine-tar branch exists, on the basis that if
that branch exists, it's presumably because you or your team wanted to
use it. So I think that's already a safety-catch against the failure
mode that gregor describes?
This does mean that revision 1 is more complicated, but that's the case
already, because the uploader needs to check the new upstream release's
suitability, reconcile the packaging with the new upstream, update the
copyright file if necessary, and so on; and it means we can at least use
`git debpush` to make subsequent packaging revisions simpler to upload.
"Trivial changes are trivial" is a nice property to have!
smcv
