On 2024-04-07 16:04 +0200, Andreas Tille wrote: > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > [Feel free to quote any part of this email which I wrote outside of this > > mailinglist] > > OK, moving the discussion to debian-devel where it should belong. Good plan. > > Debian packages need to be well maintained. In some cases, having > > multiple maintainers on a package improves the resulting quality of > > packages. But in some other cases, it does not; <snip example> > > I am all for reducing the barrier to doing NMUs. Let's look at > > that; it's ridiculous that we need to ask permission to help > > someone else with maintaining packages if it's clear that they can > > use it. Debian as a whole is a team, and we maintain the > > distribution together. So when I do an NMU for your stuff, I'm > > here to help. You should be happy when I'm offering to help; and > > that's even enshrined in the code of conduct: > > [...] offers for help should be seen in the context of our shared > > goal of improving Debian > > The fact that a package is listed as maintained by a person rather > > than a team does not mean the person is the only person who is > > responsible for that package. Debian as a whole is. And the > > release team is, in the context of deciding what happens with a > > package that has outstanding RC bugs. And the QA team is, when > > they run full-archive test rebuilds for new things. And our users > > are, when they file bugs. So I agree with everything Wouter said in this mail. I'm keen on changing the _culture_ to make it easier to just fix things. But Andreas seems to have taken this idea of 'we should make it easier to help people maintain packages', and conflated it with 'everyone has to use salsa' and 'everything should be team maintained'. I think that's a mistake, and I'm not a fan. Because so far as I can tell 'use salsa' actually means 'maintain your packages in git'. So far as I can see it is not possible to use our existing 'uscan, patch, sbuild, dupload' type workflows with Salsa. And that's why I'm not using it, and don't want to be made to use it. But I am _not_ against people helping me fix my stuff - I'm on the 'just NMU my packages - I won't bite' list. As I said elsewhere: For me Salsa is just one more thing to deal with. It is useful if you need to share a package _before_ it is uploaded, but mostly it's just a load of extra stuff I didn't want or need (git, web-interfaces, certificates). And when I _do_ have to deal with it it takes a lot of extra time and effort I would prefer to have spent elsewhere. I have a workflow I am quite happy with (uscan, meld, quilt, sbuild, dupload). I've tried various fancy new things (salsa, git, dgit) but mostly I've found they got in the way (and delayed uploads/wasted time) rather than made my life easier, so I keep going back to the old way because it just works. I don't mind what other people do, but I worry that conversations like this seem to take the new thing as so self-evidently better that no-one can reasonably complain about them being made a requirement. Well, we don't all think it's better, and I wouldn't enjoy seeing 'packages must be in Salsa' made a requirement, for example. Dgit almost solves this problem but is backwards from my POV. It lets the git people pretend that they still use quilt and tarballs so the interface remains compatible (excellent). But it doesn't let the tarball people expose an interface to keep the git people happy (SFAIK - you can't do a dgit upload unless you have a git repo) which is a pity - I'd be fine doing doing 'dgit upload' instead of 'dupload' for compatibility purposes. > > If there are stupid barriers to helping people out by doing NMUs or > > taking over packages, then by all means let's break down those barriers. Right, but this is (or should be) quite separate from 'make everyone use git/salsa, i.e. stop them using the existing workflows'. If 'use salsa' means that when I do 'dupload' a copy ends up in salsa too, and when I do 'dget' it actually gets the dsc+tarball from salsa then that's fine. But if it means 'your package is a git repo, you have to use git to work with it', then no, I strongly object. I don't want to change all my workflows and tools. Perhaps there is some tool I am not aware of that can solve this problem? Like I say, dgit is so close, but exactly the opposite of what I need. > > But let's not try to "fix" a problem by introducing a rule that is, at > > best, affecting something only very weakly related to the problem that > > we are trying to solve. > > I would be happy to talk about rules that might help solving problems > (as well as droping rules that are creating barriers). Me too. Please let us improve the culture around NMUs, collaboration and fixes without making people (OK, duffers like me) change all their tooling. I am all for more Matrix over IRC though - that's a genuine improvement (and they are easy to bridge). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature