Jonas Smedegaard <jo...@jones.dk> writes: > So you would be fine with me right now uploading gnulib 20250820 and > golang-github-smallstep-crypto 0.63.0 to unstable, without discussing it > with you first?
Yes. While I am working on both of these (right now) I consider it a race to upload, and I should only be happy if someone beats me to the finish line. Although I won for golang-github-smallstep-crypto :) If there are differences in the result, I get to sort them out and do another upload (if necessary). If the other persons' upload causes problems, I don't necessarily have to take the responsibility. For gnulib I have been side-tracked because of the git-merge-changelog bug (that maybe should go into trixie-updates, but I always forget that process) and preparing the upstream gnulib git bundle release (that didn't work out as well as I wanted to), and coordinating other upstream releases that will use a more modern Debian gnulib git commit from the bundle, but none of this are excuses to prevent you to do an upload. > Sometimes I am in the middle of some larger transition that involves > multiple packages, or I am aware of some details with newer upstream > that makes me decide to hold back on pulling that into Debian just yet. > Often I do so without formally tracking such details as bugreports - and > even if I did (or if others tracked it elsewhere, e.g. as salsa issues), > then the drive-by uploader might not notice it, or might decide that > they have different priorities and that the change is super important > to enter Debian *now*. I can sympathise with this, I am often in the same place. However this is a problem for everyone. I often forget and don't finish things. So there is a big chance that whatever was "in progress" in my head will just never materialize. Others may be better at remembering and finishing things, but I think merely the risk of that happening does not motivate preventing others from doing uploads by claiming ownership. I understand others feel differently and strongly about ownership though. Ownership tends to have that effect. > I might have opinions on how to track new upstream releases - personally > I generally prefer to use `gbp import-orig --upstream-vcs-tag=...` to > track upstream git, but sometimes I deliberately avoid that, e.g. to > not bloat the Debian git repo with a giant embedded library that is > stripped in a tarball reapackaging anyway. I've given up on trying to enforce any particular style in git. There are simply too many options around and I tend to agree with most arguments for each variant. Even when the arguments conflict. > It would be a big headache for my continued maintenance work, if some > well-intended fellow developer pushed an import of a new upstream source > to one of "my" packages, in a style different from mine for that > package, but at least I then had the option of force-pushing a different > history, wiping that change (yes, that is bad, but might be better than > living with the mess forever). I would not have that option of > forcefully dropping a problematic change if then the package was also > published into Debian: "reverting" such change might require introducing > an epoch or other clumsy hacks. What can't be fixed with another upload? Even a 1.2.3+really0.0.5 version upload solves a problem of someone "accidentally" uploading v1.2.3 but the Debian archive not being ready for it and we really need to continue with v0.0.5. I don't recall ever having to invoke the epoch spell. I think anything that lives on Salsa can be force-push'ed to "fix" things. There is one major exception: if someone removes a branch or tag, you need to have a local copy of it to be able to force-push it back into existence. I wish there were a read-only continous backup of salsa git repos, just like snapshot.d.o. I've had this happen for Go packages, some maintainers hate pristine-tar and remove that branch on Salsa. I don't push it back out of respect for their decision, but sometimes I wish I had access to the old version for myself. Renaming branches (e.g., renaming 'upstream' into 'upstream-stable') is a mess since it destroys the ability to build older versions of the package from git with gbp.conf that refers to the old branch, or similar. > I have caused similar pain for others in the past (although not in the > "debian" namespace - at least not this example that I am aware of): > Once I dis an NMU of a rust-* package where I used the upstream source > tarball as the Debian upstream source tarball. That caused pain for the > maintainer (the Rust team) because they do not use upstream source but > redistributed prepackaged source from the crates.io distribution. I think we should better blame the lack of consistency in Debian around upstream source handling, and maybe the tooling involved. I'm probably guilty if that too, it is hard to know which kind of upstream artifact is the "intended one" with some people following debian/watch and some people merging upstream git. >> I would prefer if all Debian packages were maintained in the /debian/ >> Salsa group and all DDs had the ability to make improvements to all >> packages, compared to having things scattered among namespaces, sites >> and people. > > So would I, ideally - but I find it problematic to implement that > before we have solved issues with varying packaging styles, or at least > found a way to explicitly state a packaging style and then have an > established rule that uncoordinated non-maintainer uploads *must* obey > existing maintenance style. I would like that too, but I'm not sure it is realistic, considering that "existing maintenance style" is often poorly specified. /Simon
signature.asc
Description: PGP signature
