Quoting Simon Josefsson (2025-08-20 11:37:52) > Jonas Smedegaard <jo...@jones.dk> writes: > > > For me, the concern is not tied to specific packages. I have used this > > namespace for 100s of packages to encourage collaboration but with the > > assumption that "Maintainer" and "Uploaders" still have a meaning. > > > > By using the "debian" namespace, I did not mean to invite anyone in > > Debian to do *uncoordinated* uploads (it has happened once, about a week > > ago, and that took me by surprise). > > Me too! I had no idea that the Salsa /debian/ namespace had any > semantical meaning wrt upload rights. > > > I encourage more collaboration, but I think it is the wrong approach to > > casually redefine established constraints like this. > > However I think clarifying/changing semantics as suggested is okay, in > this situation. > > I'm fine with anyone else doing uploads of "my" packages. The more > uploads the better. I believe any mistakes are better handled by making > new uploads, not by preventing people to do uploads.
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? 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 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. 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. 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 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
