On Tue, 13 Jun 2023 08:39:24 -0700 Russ Allbery <rra@debian.org> wrote: > Sean Whitton <spwhitton@spwhitton.name> writes: > > > I still find myself feeling queasy about adding this must-with- caveat. > > It feels like with the caveat you're trying to get something between > > "must" and "should", but then rather than build down from "must", why > > not build up from "should"? I would like to propose: > > > Maintainers should strongly prefer using other overriding > > mechanisms, instead of diversions, whenever those other mechanisms > > are sufficient to accomplish the same goal. In other words, > > diversions in packages should be considered a last resort. > > This sounds good to me. The argument for building up from should instead > of down from must seems compelling. That essentially means it's fine to use diversions and ship releases using them, so that's exactly what will happen as per Murphy's law. > I think that this accomplishes everything, in terms of guidance for > our > maintainers, that the must-with-caveat wording does. But it avoids > saying that using diversions over a native mechanism in and of itself > renders a package RC-buggy, which doesn't seem right to me. > > My own experience with diversions is limited, and so I accept that I > may > well be naively underestimating the badness of the edge cases. Why would it not be RC-buggy? Not RC-buggy means we are happy if it ships in a release. What does that buy us? Why wouldn't we want to direct maintainers toward the better alternative, that is current practice as of today, and instead let them reintroduce a mechanism that we agree is inferior and was just removed from the distribution? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part