On Fri, 1 Mar 2024 07:21:57 +0000 Julian Gilbey <jul...@d-and-j.net> wrote:
> 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". As far as I can tell, the proposed change aims to remove that kind of flexibility: any package that currently lists the team as an uploader would have to pick between "team as maintainer" or "out" to be in compliance. > > 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. I should probably have phrased that a bit differently than 'offload'. My packages simply never have RC bugs open for a long time and under normal circumstances don't require any team attention/intervention. Which is exactly why I prefer the "talk to me before making major changes" approach the current policy provides. Whatever extra time I have beyond that needed for my own packages mostly goes towards sponsorship, in part because that makes people feel their work is appreciated and encourages further contributions. > 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). Working directly in git is simply more convenient, lowers the bar for contributing, and subjects any contributions to the scrutiny of the CI pipeline. In addition, having team members familiar with python packages involved lowers risk vs. a drive-by NMU, no matter how well intended.
pgpd0kYFIliI4.pgp
Description: OpenPGP digital signature
