Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"
Sean Whitton dijo [Fri, Jun 21, 2019 at 02:36:05PM +0100]: > My reading of the conclusion to #904558 is that the recommendation to > form a working group is a recommendation that can be directed only to > the developer body as a whole, not to the Policy process. That's > because actually implementing in the archive some new mechanism for > maintscripts is a prerequisite to any Policy change requiring packages > to use that new mechanism. In other words, what the working group would > be tasked with doing is beyond the scope of the Policy process. We do > design work as part of the Policy process, but we don't write code. > > Assuming that the T.C.'s recommendation is the right way to proceed > here, and someone doesn't come up with any other way to unblock things, > the wontfix+stalled status will remain until and unless the working > group actually forms, designs and implements something, and starts using > it in the archive. There is no role for the Policy process (and thus no > role for the Policy Editors qua Policy Editors) until that occurs. > > So, by all means insist on the recommendation, but so far as I can tell > that's something which does not involve either the Policy process or the > T.C., but simply the body of Debian contributors qua contributors. I completely agree with you - My idea to kickstart this at DC19 is not for TC and Policy Editors leading a session, but rather us (as individuals) expressing the issue at a BoF trying to get more eyeballs (and, more important, more brains) on it. > Stepping back a bit, tagging this bug wontfix+stalled is part of the > broader attempts, in which the Policy Editors are engaged, to more > sharply delineate the boundaries of the Policy process. We want to get > to the point where the only bugs that we have listed are either > highly actionable, or tagged wontfix. For a bug to be highly actionable > is for it to be the case that someone with enough time and background > knowledge can sit down, think through the problem, and come up with at > least a first version of a change proposal. > > I think that a large number of very-difficult-to-action bugs strongly > discourages people from getting involved. It makes Policy seem like a > sprawling, unmanageable morass of difficult problems. That isn't how > things are, because while there are indeed a lot of hard problems, they > are largely independent of each other, and tackling individual > debian-policy bugs really does improve Debian. However, it is much > harder to see that when half of the open bugs are more than five years > old yet not tagged wontfix. Right. This is a bug where I was quite happy that the TC decided to declare it outside of its functions - And it is just fitting that it's outside the Policy as well. We don't have a commonly implemented practice to document / show / follow. This should go to the developer body at large. signature.asc Description: PGP signature
Bug#930666: Please document consensus on use of dh sequencer
I believe that both Russ's text and Sean's revised text capture the project level discussions. I also believe that given those discussions the issues are well understood enough for us to move forward relatively quickly if new issues are not raised here. I believe that Russ has adequately responded to the issue that Bill raised. As such, at least under my understanding of the policy process, I think I've reached the necessary conclusions to second a proposal on this bug. So, I second Sean's revisions to Russ's proposed wording. --Sam signature.asc Description: PGP signature
Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"
Hello Gunnar,
On Thu 20 Jun 2019 at 11:18am -0500, Gunnar Wolf wrote:
>> ~ ~ ~
>>
>> In #904558, I did not ask the T.C. to rule on what maintscripts should
>> do when they fail to restart a service. Rather, I asked them to weigh
>> in on the decision between the options described above, given that the
>> Policy Changes Process had failed to achieve consensus. However, in the
>> message closing #904558, the T.C. indicated that they declined to issue
>> a ruling about what maintscripts should do when they fail to restart a
>> service. So the second option described above, corresponding to the
>> 'ctte' usertag, has been taken off the table.
>>
>> That leaves us with the question of whether to leave #802501 open, in
>> the absence of the possibility of closing it by having the T.C. make a
>> call. Given that this bug has already been filed (at least) twice, I
>> think it would be best for us to leave it open. So I'm tagging
>> wontfix+stalled.
>
> I want to interpret this wontfix+stalled, and the TC answer ("The
> Technical Committee does not engage in design of new proposals and
> policies") don't mean this problem will just lay dormant and unsolved
> forever. As Marga said in her mail closing this bug, «While we
> recognize that this is a problem worth fixing, this is not something
> that we can fix as a body and need the help of the Developers to do
> it.»
>
> I want to insist on our recommendation to create a work group of
> developers to tackle this issue. Maybe we can start it off as a BoF
> session in DC19?
My reading of the conclusion to #904558 is that the recommendation to
form a working group is a recommendation that can be directed only to
the developer body as a whole, not to the Policy process. That's
because actually implementing in the archive some new mechanism for
maintscripts is a prerequisite to any Policy change requiring packages
to use that new mechanism. In other words, what the working group would
be tasked with doing is beyond the scope of the Policy process. We do
design work as part of the Policy process, but we don't write code.
Assuming that the T.C.'s recommendation is the right way to proceed
here, and someone doesn't come up with any other way to unblock things,
the wontfix+stalled status will remain until and unless the working
group actually forms, designs and implements something, and starts using
it in the archive. There is no role for the Policy process (and thus no
role for the Policy Editors qua Policy Editors) until that occurs.
So, by all means insist on the recommendation, but so far as I can tell
that's something which does not involve either the Policy process or the
T.C., but simply the body of Debian contributors qua contributors.
Stepping back a bit, tagging this bug wontfix+stalled is part of the
broader attempts, in which the Policy Editors are engaged, to more
sharply delineate the boundaries of the Policy process. We want to get
to the point where the only bugs that we have listed are either
highly actionable, or tagged wontfix. For a bug to be highly actionable
is for it to be the case that someone with enough time and background
knowledge can sit down, think through the problem, and come up with at
least a first version of a change proposal.
I think that a large number of very-difficult-to-action bugs strongly
discourages people from getting involved. It makes Policy seem like a
sprawling, unmanageable morass of difficult problems. That isn't how
things are, because while there are indeed a lot of hard problems, they
are largely independent of each other, and tackling individual
debian-policy bugs really does improve Debian. However, it is much
harder to see that when half of the open bugs are more than five years
old yet not tagged wontfix.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#930666: Please document consensus on use of dh sequencer
Hello, On Thu 20 Jun 2019 at 08:51am -0700, Russ Allbery wrote: > That said, this is way too large of a problem to solve in this bug. I > think we need to stay focused on one section of policy here with a few > tactical fixes so that the text still reads cleanly and not confusingly > (which is the goal above), and then look at what we can do elsewhere to > spread the clarity once we've agreed on what we want to say here. I agree that this is the way to proceed here. -- Sean Whitton signature.asc Description: PGP signature
Bug#930666: Please document consensus on use of dh sequencer
Hello, On Fri 21 Jun 2019 at 01:09PM +01, Sean Whitton wrote: > packaging helper might want to use their new tool. The > recommendation to use ``dh`` does not always apply, and use of > ``dh`` is therefore not required. > > - saying that use of ``dh`` is "not required" is strictly redundant > because 'required' is equivalent to 'must', and nothing in the > previous paragraph says that you must use dh > > - I think I avoid any chance of misreading by reiterating that the > recommendation has exceptions Drop the final 'therefore' from my text, because the fact that it is not a requirement is not a consequence of the fact that the recommendation has exceptions. -- Sean Whitton signature.asc Description: PGP signature
Bug#930666: Please document consensus on use of dh sequencer
Hello Russ, Sam, On Thu 20 Jun 2019 at 09:01AM -07, Russ Allbery wrote: > Sean Whitton writes: > >> A tiny thing is that you seem to have switched "" for "", >> which seems wrong. > > I'll put this back to args... since it just muddles the discussion, and we > can talk about that separately some other time. But, for the record, > "" would imply that all the arguments have to be given as a single > argument and would be later split, as opposed to " ...", which allows > for one or more arguments. Aha, I see. >> However, any SHOULD requirement in Policy implicitly has that structure: >> "you should X unless there is reason not to X". Perhaps MUST >> requirements don't have that implicit structure, because perhaps the >> idea in such cases is that there is never reason not to X. > > I agree with Sam that this is not the way Policy is currently written. > This *is* what RFC 2119 SHOULD means, but this is one of the places where > Policy diverges from RFC 2119. > [...] Thank you both for the correction. In hindsight, it would have been wise of me to review our definitions of the magic words before making an argument based on how they are defined. >> Would it be right to say that what we are trying to express is the idea >> that dh should be used when there aren't *package-specific* reasons not >> to use dh, and for new packages, we're recommending a workflow of >> starting with the assumption that no such package-specific reasons >> exist? > > I don't think so, since this doesn't account for a maintainer who is > writing a new packaging helper, which is not a package-specific reason > (it's a maintainer-specific reason). I also don't think the project > consensus was to tell Jonas (the cdbs maintainer) to use dh for all new > packages. Good point. > I understand the concern about making the language too weak, but I also > don't think there's a need to be too firm here. The goal, at least as I > see it, is to push people who don't have strong opinions towards dh, not > to try to convince the people who do have strong opinions. (I think that > convincing is worthwhile but I think it will happen organically and Policy > isn't really the place.) My concern is not about making the language too normatively *weak*. I agree with everything just quoted. Rather, my concern is about the language being normatively *imprecise*. I wrote: | I would like to try to make the first sentence normatively clearer. I | think that it would be difficult to understand exactly what the project | consensus is from that sentence, had you not read Sam's d-d-a post. and I still think that. Let me say a bit more. We want to push people without strong opinions on the matter towards using dh. We could do that by writing something in Policy which does not use any of the magic words (like some other tool recommendations in Policy), and in such a case I would not be raising this concern. However, we have decided that we want to use the should/recommended words. And I think that when we use the magic words we should take special care to make it clear to the reader what the normative content of the sentence is. Looking at your patch again, I think that my concern could be allayed by explicitly tying the "There are various situations ..." paragraph to the "reason to use a different approach" clause. This is the sort of thing that I mean (I've also wordsmithed): The recommended way to implement the build process of a Debian package, in the absence of a good reason to use a different approach, is the ``dh`` tool. This includes the contents of the ``debian/rules`` building script. ``dh`` is the most common packaging helper tool in Debian. Using it will usually save effort in complying with the rules in this document, because ``dh`` will automatically implement many of them without requiring explicit instructions. There are sometimes good reasons to use a different approach. For example, the standard tools for packaging software written in some languages may use another tool; some rarer packaging patterns, such as multiple builds of the same software with different options, are easier to express with other tools; and a packager working on a new packaging helper might want to use their new tool. The recommendation to use ``dh`` does not always apply, and use of ``dh`` is therefore not required. Other notes on this: - I changed "a reason"->"a good reason" because this is in fact what we mean - saying that use of ``dh`` is "not required" is strictly redundant because 'required' is equivalent to 'must', and nothing in the previous paragraph says that you must use dh - I think I avoid any chance of misreading by reiterating that the recommendation has exceptions -- Sean Whitton signature.asc Description: PGP signature
