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 <email@example.com> 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.
Description: PGP signature