Re: Streamlining the policy process
Jonathan Nieder <jrnieder@gmail.com> writes:
> Question
> ~~~~~~~~
> I'm happy to hear you have ideas for a smoother policy process. Could
> you suggest a few? Maybe we can batch them up and make a general
> resolution. :)
I think the problems with the current process fall into roughly the
following categories. Different people will disagree over how significant
these problems are. :) I think the first two at least are clearly
problems, though.
1. Significant changes to the way Debian packages are maintained, ones
that require coordination and implementation by many developers, aren't
documented in Policy until well after they're in effect. This is
mostly because the changes involve a significant amount of work to
write up for Policy and there are very few people doing that work.
Even once that text is written, the discussion and debate of it usually
takes literally months and as much as a dozen revisions or more.
Obvious examples: symbols, multiarch, triggers.
2. There are insufficient change shephards and seconders to allow us to
process more minor changes in a timely fashion while still getting
sufficient review that we can be reasonably assured that the new policy
is the consensus of the project.
I was able to produce a net decrease of our outstanding bugs when I
committed to spending an hour a day, every day, on Policy, partly by
producing wording for everything in sight, partly by just watching and
merging changes, and partly by bugging people for seconds.
Unfortunately, I don't have the time to be able to make that
committment more than occasionally, and none of the other Policy
maintainers appear able to devote anywhere close to that much time.
3. Whenever there is any disagreement over a change, the process here
effectively grinds to a halt. We don't seem to have a workable process
for achieving rough consensus with some disagremeent, or making
decisions when there's disagreement. We might be able to get around
this by more aggressively appealing to the tech-ctte. Obvious
examples: #587279, #248809.
4. New changes get very detailed wording review, which frequently results
in multiple rounds of patches and means that even relatively
straightforward changes usually take at least a week of intermittant
effort to finish. Many changes are just abandoned at this stage
because it's too much effort.
My past experience is that this *significantly* decreases the speed
with which we can work through bug backlogs. I'm not sure what the
solution is, since I'm just as much of a perfectionist as everyone
else, but it's definitely one of the reasons why we're not keeping up.
> Here are some conterpoints from someone who has occasionally written
> small patches to address policy bugs.
> - Uncertainty about the policy process leads to a stilted and
> uncertain discussion. For example, I would not mind writing a
> patch documenting the consensus from bug#678607 (which is about the
> requirement to list original authors in debian/copyright) but I
> have no idea what the consensus is. The conversation stopped for
> no good reason.
This seems to be another version of 3. Even mild disagreement causes
everything to grind to a halt.
> - After a patch is written, it can sit for a long time afterward
> without being applied despite consensus. This takes away some of
> the reward of writing a patch.
This is *usually* because of point 2, specifically insufficient seconders.
> For example, I think there is a strong consensus behind bug#578597
> (dpkg-buildflags is the interface for retrieving compiler flags in
> debian/rules) but even the proposed change to an example in
> bug#613046 has not been applied.
In this case, that's because the patch, while producing the correct
results in the context of that specific example, uses a construct that
won't work as soon as you want to change the behavior (to enable hardening
flags, for example).
There's probably some amount of the best being the enemy of the good here,
but I do think we should be able to come up with a better example.
> Another example: there seems to be a strong consensus that symbols
> files are a part of the package format that we support and that
> they basically work as described in the patch from bug#571776. But
> nothing happens.
Here, that's because I posted a long patch and maintained it through
several rounds of modifications, but then got somewhat discouraged by the
last round of comments and stepped away from it for a while, and since
haven't gotten back to it. I disagreed with several comments in the last
round, and need to do another revision plus feedback on what I disagreed
with.
That patch probably would have been better if we could have gotten it in
in pieces.
> In all these cases, if I understand correctly then nothing is
> happening because no one knows what the next step is.
Or because only I, or only Policy delegates, can take the next step.
There are also five or six open bugs that are just waiting for seconds. I
was pinging those regularly, and haven't had time to do that.
> In most packages, that would be a situation for interested people to ask
> the maintainer what is needed next and for the maintainer and others to
> give guidance. The current policy process means that even the policy
> maintainers can wonder why a bug is stalled and there is no one to offer
> guidance.
> To put it another way: I don't think a lack of patches is the only
> problem. Sorry for the ramble.
Yes, I agree that it's not the only problem.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: