>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> Thank you for giving an example. It helps better me
Helmut> understand what you mean with setting policy, but I remain
Helmut> unconvinced that this poses a significant enough difference
Helmut> that we would not require a super majority as this policy
Helmut> has the same effect as overriding systemd maintainers.
I don't think that matters.
I think what matters is which power the TC uses to make a decision.
I often think that setting policy will make it clear what maintainers
should do and if they don't choose to follow that policy should make a
decision about an override later very easy.
I would encourage the TC not to set policy that really is about one
package, because that does appear to be an end-run around the super
majority requirement in some cases.
But when a requirement actually legitimately crosses a boundary between
packages, that falls well within the scope of policy in my mind, even if
the policy is choosing a default implementation and describing how
non-default implementation behave.
I don't remember if it was done under the policy making power, but I
think it would have been entirely reasonable for the TC to decide the
default init system for (was it jessie? stretch?) as a matter of policy.
There have been cases where the secretary has explicitly asked the TC to
describe which power they are using in a resolution and there has been
deference given to the TC's decision about what power it was using and
what the super majority requirement was for that power was in those
cases.
