Scott Kitterman <deb...@kitterman.com> writes: > I think it would be better to reset and actually have the conversation > that was assumed to have happened before taking the step of a GR.
We're having that conversation right now. I see no reason to stop now that it's finally started in earnest unless it looks like it has concluded in an actual agreement, a delegate decision against tag2upload, or a pocket veto. In the last two cases, the obvious next step is a GR and I don't see a reason to wait. If people need some time to think, great, they can say so. The discussion is not on a clock yet; they can think while we're discussing. This is the soapbox that I climb onto whenever a GR is proposed, and I guess I need to climb onto it again. More fundamentally than my position on any given GR, I am on team closure. One of the worst and, I would argue, actually abusive things that Debian systematically does to people is string them along for long periods of time saying neither yes or no. I personally would rather be told "no" than "maybe" if the "maybe" involves staying in limbo for months or years. Obviously it's not my GR and I'm not going to make any of those decisions. Maybe the tag2upload maintainers would prefer "maybe" to "no" and that's their choice to make. But if it were me, I'd want this concluded here and now so that I can either deploy my thing or abandon it and find something else to do with my time and, more importantly, my emotional energy. We've just done a whole ton of work to reach a better shared understanding of all of the corners of the problem, and I for one have spent a truly absurd amount of time and energy over the past week trying to make the problem clear. It makes no sense to me, and I think would be actively cruel, to stop now and have to substantial amounts of that work all over again some time later. Debian is profligate in wasting the time and energy of its contributors already; we don't need to make it worse. > I see broad agreement on the goals of tag2upload (at least to a certain > level of detail) I would like to believe this, but I don't. The fundamental building block that FTP team did not allow in 2019, and is still not allowing right now as far as I can tell, is for Debian project infrastructure to build a non-trivial source package. We're still stuck on putting unjustifiable weight on a maintainer signature that isn't meaningful for the things that it's being used for. If they have changed their mind, great! Fantastic news. They need to say so. Until that happens, we keep talking. If the discussion stalls out with no movement from the FTP team, that amounts to a pocket veto whether there's a formal delegate decision or not. > and I don't think there's any clear evidence that a solution that meets > those goals while also addressing the FTP Master's concerns isn't > possible. *Possible* is not the bar that I would use in voting in a GR. Lots of things are *possible* with computers that are clearly bad ideas, or that are so much work as to make them infeasible, or that are just an unjustifiable waste of other people's time. I am frequently told that Debian is a do-ocracy: the people who are willing to do the work have wide latitude over how that work is done. One of the implications of that is that delegates don't get to force other people to do their work in arbitrarily different ways just because they would personally like that better. There is an obligation that comes with the delegate position to only block things for clear and important reasons that matter, and to do that, one also has to be *correct*. If I make a delegate decision on an incorrect basis, I am wrong and I can and should be overridden. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
