On Sunday, June 23, 2024 10:57:26 AM EDT Russ Allbery wrote: > Simon Richter <sjr@debian.org> 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. I think that misses some key points, although I mostly agree. Three thoughts: First, as I understand the position of the FTP Masters involved in this discussion (for clarity, I'm a non-delegated member of the FTP Team (i.e. FTP Assistant)), their view is that determining if an upload is from a person authorized to upload to the Debian archive is a function that is within the scope of their delegated authority and the current tag2upload proposal takes over that function. Second, whatever the current buildd's do, it's downstream of that decision, so not involved in the question of if a new upload is authorized or not. I don't think the buildd analogy is particularly helpful here. Third, even though the host that DAK runs on is DSA managed, DAK is not. It's maintained and developed by the FTP Team and that's an explicit part of the FTP Master's delegation. Assuming tag2upload is integrated into the package upload process, I think it is clear it will have to run on a DSA managed host, but that's a separate question from who will manage the tag2upload service. The idea what we would take something that's part of one team's delegated responsibility and move it elsewhere for some types of uploads without that also being subject to some form of DPL delegation seems wrong. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.