Re: [RFC] General Resolution to deploy tag2upload
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.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: