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
Attachment:
signature.asc
Description: PGP signature