Simon Richter <[email protected]> writes: > The difference is the expectation that the delegates will continue to > perform this work and therefore need to deal with the long term > impact. One-time contributions are welcomed as long as they are a net > positive, but not all of them are, and some take up hundreds of hours of > volunteer time several years down the line.
Sure. I don't think anyone involved has ever intended for tag2upload to be a one-time contribution. It's an ongoing service and the developers have been clear that they intend to maintain and further improve it if it is deployed. > Deploying tag2upload *as a service* is an ongoing commitment, which > means creating a new delegation, or altering the scope of an existing > one. We need to be explicit which one it is. I don't know what the general practice is for Debian project infrastructure. There isn't a separate delegation for the buildds, even though I don't believe they're run by the FTP team, and I don't think they're entirely covered by the DSA delegation. tag2upload is essentially a source package buildd, so however the buildds are handled might make sense, although I realize binary buildds are a bit more complicated since it's often different people per architecture. In other words, I'm not sure that "ongoing commitment" == "delegation" (either new or existing). I think there are lots of things in Debian that are ongoing commitments but not delegations. But I can also see the argument for considering that a bug and wanting a delegation for any new ongoing service. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
