I'm not really sure that the point you bring up is all that related to the question I was asking. But I think the point you bring up is important and I hope relatively easy to solve, so let's discuss it and try to solve it.
>>>>> "Bill" == Bill Allombert <ballo...@debian.org> writes:
Bill> In my view it is detrimental for the policy proces for the
Bill> Debian policy to include decisions made by the TC, because
Bill> this leads to a situation where some policy text is frozen
Bill> because the policy editors cannot change it without
Bill> potentially overriding the TC.
Thanks for bringing this up.
I agree that it would generally be unfortunate if we had policy text
that could not be changed by the policy process. I can see rare
situations where it might happen: we might have legal advice requiring
specific text be included in packages under certain circumstances. And
in such a situation it might well be that we'd expect the policy editors
to go back and check with lawyers before changing that frozen text.
I hope we don't run into that situation with the TC very often, and
can't see a lot of reasons why we would if we handle things correctly.
I want to solve this because I think it would be very detrimental if our
policy documents didn't reflect technical policy of the project. And If
we decide it's detrimental for the policy document to include technical
policy that the TC decides under section 6.1.1 of our constitution,
we're effectively saying that we don't want the TC to decide technical
policy. I don't want a situation where people need to go look at the
policy document and then separately go look through all the TC
resolutions.
Now, some TC resolutions are quite specific to a specific package or
situation and aren't within the scope of policy. Others aren't even
setting technical policy. But when the TC sets technical policy that
packagers should know about, I want to see that reflected in our policy
documents so that our policy documents remain useful.
I agree with you having frozen text in policy documents is undesirable,
and unless there's a good reason to do so we should avoid it.
I think the policy editors could handle this by deciding amongst
themselves how they want to interact with the TC and then writing a note
to the TC along the following lines adapted based on what the policy
editors think the write answer is:
----------------------------------------
Dear Technical Committee:
We wanted to clarify how we we handle situations where you exercise
your power to set technical policy under Constitution section 6.1.1 and
where that decision should be reflected in Debian Policy.
Often it will make sense for you to include a diff to Policy in your
decision. We will apply that diff. As with all contributions to free
software, we will continue to refine and improve the contribution over
time. In other words, we assume your decision is the intent of the
policy, and your text is intended as your best attempt to reflect that
in our document at the time you make the decision. If there's text that
you do not want refined, please call that out and if we have any
concerns about that we will raise that.
As part of our normal process of evaluating changes to Policy, we will
consider whether those changes are consistent with decisions of the TC
and whether we need to ask for an override. If we think their might be
a perception of conflict we'll let the TC know or ask for a specific
decision depending on how likely we think it is there is a conflict. If
you think we've introduced changes into Policy that conflict with TC
decisions please open a bug.
----------------------------------------
In pa
particular: I don't think the specific text that the TC proposes is
generally frozen. I think that's rarely the TC's intent. I also think
that because of the separation between policy editors and TC, it's not
really clear to me that the TC can freeze text in Policy even if they
can set technical text for the project. Thy can set policy; they
probably help everyone out by showing how that would fit into our
current Policy document. The editors need need to produce a Policy
document that is consistent with the technical policy established by the
TC. Of course if the editors think they can't do that they can throw up
their hands and quit (or more constructively point out the problem to
the TC).
Even beyond that, TC decisions are made based on a lot of context. I
don't think it always needs a TC override to actually go against the
decision if the context has changed enough. Sometimes the TC is good
about specifying the limits of the context. For example as I recall
they were debating what the default init system would be for a
particular release, not as standing policy.
But even if the TC is imprecise about context, it shouldn't require an
override if that context has changed enough. As an example, I don't
think anyone needed to go back to the TC to ask about using
/usr/bin/node for nodejs. Time had passed since the initial decision,
Nodejs had become a lot more popular, and the previous program went
away. I don't think asking the TC was a bad idea, but I don't think it
was necessary.
Yes, you can abuse this. If a maintainer were overridden, and a week
later reversed the TC's decision arguing that "a whole week had passed,"
that maintainer would not be acting in good faith. The TC would
hopefully find that package needed a new maintainer very quickly and
da-manager might take notice.
If the same maintainer tried doing things the TC's way for a release and
found that it really didn't work out, well that would be different.
I'd say it would be good form to let the TC know before doing something
different. But the context would have changed enough that I don't think
it would inherently require an override.
Basically be reasonable, let people who might have a concern know, and
explain yourself. If you find that you're often too willing to revisit
TC decisions back off.
If we as a project find that you're not acting respecting the TC
process, we can warn you, ask you to involve co-maintainers, and
eventually can change maintainers of packages or ask the account
managers to get involved.
I think that's true for maintainers and for the policy editors.
Let's act in good faith and not make unnecessary process for ourselves.
When we are acting in good faith treat mistakes as bugs and go fix them.
signature.asc
Description: PGP signature
