Russ Allbery dijo [Fri, Jun 14, 2024 at 02:06:35PM -0700]: > (...) > The tag2upload developers have been working on this system for many years > now. Deployment has been blocked by an FTP team decision. At this point, > the tag2upload developers are quite understandably not willing to do more > work unless their work can actually be used by the project. The design > has gone through multiple iterative improvements, and while it can always > be better, at some point we need to make a decision about whether we're > going to ask them to abandon it or let them deploy it. The decision of > the FTP team appears to be that they should abandon it. The tag2upload > developers are proposing to appeal that decision to the project as a > whole. > > Deciding to deploy the service does not mean freezing the whole thing > as-is forever. It's inevitable that new issues will arise once the > service is running, and those will need to be addressed. It does mean > extending trust to the tag2upload developers to manage their portion of > the service, similar to how we trust the FTP team to manage dak. That > trust includes expecting them to respond reasonably to concerns and > problems as they arise. > > There is no need for this to be personal or hostile. I'm also a project > delegate in another area, and I consider it part of the role of a project > delegate to accept guidance from the project. I will make mistakes. I > will also make decisions that I don't think are mistakes but that don't > match what the project wants. The project gets to decide via GR if I'm > wrong. That's part of the bargain I accepted when I joined the project. > If they so decide, it's my responsibility to go along with that decision > in good faith and with good will, or to decide that I no longer want to do > the delegated work. > > The point of the GR is to provide clear guidance from the project: either > deploy this thing so that we can see how it works and further improve it, > or abandon the idea. We need to get some closure on this; talking about > it forever while blocking forward progress creates animosity and > frustration. Once the project provides that closure, I would expect > everyone involved to reorient around the guidance that the project has > provided and work collaboratively together on Debian, just like we all try > to do in every other area.
You bring an important issue to my mind. In case the ftp-masters are forced to accept tag2upload as a valid authorized package generation mechanism, this should not tie their hands forever: It should be explicit that the project wants to _try_ this mechanism, and possibly set a timeframe for this decision to be held or repelled. Or maybe even more lightweight -- "barring any further controversies, in $(now+1yr) this GR becomes null, and the decision of whether to allow tag2upload-generated packages goes back to the ftp-masters". This is, if in 1yr (or whatever) it becomes clear that the tag2upload maintainers are not cooperative tracking and fixing any bugs or issues pointed to them, or if weaknesses in the system become clear, ftp-masters should not require to come back to another GR to decomission a faulty system, and should have the authority to do this themselves. Of course, that's not the conclusion I expect. I expect tag2upload to become a good alternative for many developers, and I expect its maintainers to be responsive and responsible. But I think it's important to restore ftp-masters' full authority over their delegation. (I know it's almost impossible to decomission systems used by some developers ;-) not that it hasn't ever happened, as Alioth itself shows, but it's not ever a lightly taken decision)
