Hi David, On Thu, Aug 30, 2018 at 10:43:01PM -0300, David Bremner wrote: > Tobias Frost <tobi@debian.org> writes: > > > Hallo everyone, > > > > This is a gentle reminder regarding the Salvaging Process discussion! > > > > For all of those, who did not yet have read the proposal, but still want > > to participate in the discussion, please step forward now, as I plan to > > start to work on finalizing the text after Saturday, September 1st. > > Hi Tobi; > > I'm not sure it's a good idea to have the definitive criteria for > salvaging in the wiki. I guess partly I'm not too comfortable with the > lack of definition of an process to change those criteria in the > wiki. It's also strange to me to have the salvaging description split > across two locations. I'd suggest that whatever the "real" conditions > are (even if the concensus is to use a less formal set of conditions > like those given here), that they go in the same document as the > procedure they enable. The split was actually thought to be a feature [1] :) It was to make the process itself less normative about the actual (concrete) figures/criterias, but still give safe figures to e.g necomers they can rely on, and on the other side enable more advanced people to reasonably deviate from it (but with a strong documentation/justification requirement). Yes, you're right, there should be a process documented how to change this text, e.g the process should include an manadatory discussion on e.g -devel; Beside that our Wiki records every change and who did the change, so we get also an audit trail for free. (I've just added some language to the Wiki for it now) Not sure if that would adress your concerns well enough; Let me CC enrico to get also his thoughts. -- tobi [1] The idea picks up this quote from the BoF summary: Gregor's mail [1], with input from enrico: Vagueness could be a good thing, and the worst that can happen if someone does a bad call on salvaging is that an ITS bug gets opened and closed, and something that was unclear gets documented. The number of months and so on that are currently in the proposal are still useful to empower a new maintainer to make the call without fear, and could be put as an example reference in the wiki, rather than in the dev-ref.
Attachment:
signature.asc
Description: PGP signature