Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]: > > I think it's appropriate for people to wait on such work until there's > > guidance from the TC ensuring that such a patch will be accepted. > > Otherwise, anyone spending time writing it is spending substantial > > effort that may well be wasted. > > I think this is a totally fair thing to be concerned about. Should such a > patch exist -- with the obvious condition that I think it's quite > reasonable to do several rounds of iteration on making that patch solid, > ensuring there are tests, and so forth -- I think it's obvious that we > should merge it given the previous TC decision. Of course, I'm not a TC > member.
I have informally talked with some other TC members; I am a TC member, but am writing just as an individual DD. You have said the TC has ruled to make an NMU in the past. I doubt an NMU would fly -- The dpkg maintainer does not want to engage with the TC, and I believe odds are high we could end up playing NMU ping-pong. That's not in the best interests of our users nor the project. However, TTBOMK, no patches have been proposed. However, even given his attitude, I trust he would apply a correctly done patch addressing the issue at hand. > It's difficult, procedurally, for the TC to do anything about a > theoretical patch that someone could write but hasn't written. Precisely. We cannot mandate a patch to be written. We can (and I _do_ think we should) require the maintainer to remove this warning -- not because it is false, but because torpedoing trust in the project is not the right course of action. > If a concrete patch exists, the TC can (and has in the past) authorize an > NMU to apply it. Obviously, we should try to avoid reaching that level of > social and process confrontation if we can avoid it, but this is clearly > within the TC's constitutional power via a maintainer override, which puts > the discussion on somewhat firmer ground. But design of that patch is > *not* within the TC's constitutional mandate. > > It may be useful to look at how multiarch support in dpkg was handled. > That was quite painful and I really hope we don't end up following that > path exactly, but it provides a concrete example of how Debian's processes > can reach a resolution. > > I personally am still hopeful that we could do much better than the > multiarch outcome and find a patch that meets the architectural criteria > of the dpkg maintainer, but I'm fairly certain that we're not going to > make any progress towards that goal without having working code, or at > least a very detailed architecture, to start discussing and analyzing. Completely agree here.