Hi Jeroen, On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote: > On Tue, 27 Feb 2024 18:32:54 +0000 > Scott Kitterman <deb...@kitterman.com> wrote: > > > While I do take advantage of this for a few packages, I don't > > personally care much either way. I suspect that packages will be > > removed from team maintenance as a result though and I think that's > > a bad idea. > > > > I'd prefer the current approach over people removing packages from > > the team, so I think it's important that anyone who feels strongly > > enough about this to do so, speak up. > > For me, the weaker collaboration option that the DPT provides is key > to putting my packages under a team umbrella. > > As I find myself completely AFK for up to a month at a time for both > work and private reasons, having a knowledgeable bunch of developers > around with full access to my packages (VCS and CI included) is a > definite plus, if only out of a strong sense of responsibility. The > same goes for benefiting from the shared knowledge of the team, > including routine fixes and similar minor changes being rolled out > across all packages in the team.
These are really interesting points. Under the proposed system, I presume that one could leave "privately maintained" packages within the python-team area of salsa and still benefit from these automatic changes without giving automatic permission to other developers to make manual changes. Being part of the team is a relationship between developers; it surely doesn't say anything about a specific package's maintenance, just as one can ask questions on debian-devel without saying "anyone can do anything to my packages without asking me". > That said, I'm very careful not to spend more time on volunteer > efforts than I can afford to, and not looking to offload the full > maintenance of any of my packages. Upstream involvement often gives > me advance knowledge of upcoming releases, their compatibility issues > and other quirks, which in turn helps avoid problems on the Debian > end. I do not share the optimism that documenting such details > somewhere in individual packages - as suggested elsewhere in this > thread - would be effective to avoid trouble; more so considering > that the inability to stick to a single, concise, and rather clear > team policy is ultimately what triggered this whole discussion in the > first place. I don't think it's a binary choice: "offload the full maintenance" of a package versus "keep the full maintenance". As far as I understand it, a package maintained by the team will typically have a main person who does the day-to-day work on it (few people have the time to start doing serious work on lots of other packages), but anyone on the team could work on it. In the cases mentioned, there are RC bugs in packages which have not been addressed in a timely fashion and are holding up transitions or similar. In some of "my" packages, other developers on the team have uploaded more regular updates (thanks!). In most cases, updates are routine and I'm very appreciative of it. While documenting quirks might not fully avoid trouble, it's much better than not documenting them. After all, this is detailed knowledge of a package or collection of packages that has been gained over time, and in addition to helping anyone stepping in to do a team upload, documenting it will help whoever ends up taking over the package one day (as well as helping the maintainer themselves!). The question for your quirky packages then becomes: what does the current team maintenance position offer that having the package solely maintained by yourself would not provide? I can see very little; anyone wanting to help with a package outside of the team can still offer to do an NMU (and push their changes to salsa). > As for the inclusion of codes of conduct or similar wording, > documenting common sense just feels unnecessary. While being on the > receiving end of a compliment for bug-squashing work is certainly > nice, the lack thereof isn't a measure of disrespect. I cannot recall > any discussion on the team's IRC channel or mailing list crossing > that line. As far as I understand, this thread was started not because Andreas did not receive a compliment, but because he received quite unpleasant emails "telling him off" for doing it. These were not public communications, so you would not have seen them. I don't think anyone is suggesting that every team upload requires a compliment (though such things are, of course, nice and appreciated!). Best wishes, Julian
