Re: Review of proposals
Hi,
Note that I'm not in the best position to propose changes, because I
am unlikely to vote it very high in any case.
On 29/11/19 at 11:44 +0000, Ian Jackson wrote:
> > 2/ It says:
> > > If policy consensus cannot be reached on such a facility, the
> > > Technical Committee should decide based on the project's wishes
> > > as expressed in this GR.
> >
> > Well, given that some of the criterias are not super-clear (see above),
> > it's likely that policy consensus will be hard to reach. Then the TC is
> > left with deciding based on the project's wishes as expressed in this
> > GR. But assuming that proposal D wins, where is that project's wish on
> > non-init-related declarative systemd facilities expressed?
>
> That is referring to the list of criteria in my clause 9
> (contextualised bn with the rest of of the whole proposal including
> (for example) the principles in clauses 1 and 2).
>
> What this is saying is that if we can't get policy consensus on
> whether the clause 9 criteria are met, the TC should decide the same
> question.
>
> I'm sorry that this isn't clear to you. I'd be happy to improve that.
To clarify this, it might help to drop "based on the project's wishes as
expressed in this GR." I think that asking the TC to decide based on
specific elements is going to add noise to the discussions.
> > I'm also not sure about the part about "being excellent to each other".
> > How does this part of this GR interact with the CoC? Is it expected that
> > the CoC includes special cases about init systems if this proposal wins?
>
> I think your criticism here is addressed primarily at my clause 11.
>
> Directly in answer to your question, no. If I wanted to modify the
> CoC I would say so explicitly. The CoC is quite generic, whereas this
> GR is quite specific. I don't know if you have been hanging around on
> -devel and reading the discussions there ? Clause 11 is trying to
> address some of the specific pathologies we see in those discussions.
>
> Do you see the same pathologies ? If so, what do you think should be
> done to try to address them ? The existing CoC etc. do not seem to be
> effective.
I think that it is more a problem with how we are enforcing the CoC
(because this is hard, not because we are doing a particularly bad job).
I don't think that the part about "being excellent to each other" is
going to help.
> > For those reasons, I am not sure if I will rank proposal D above FD. I
> > would very much prefer if it were compressed to a proposal of about the
> > same length as proposals B or C.
>
> I am sorry it is so long, indeed. It's just that I don't see what to
> cut. The init systems wars have been so wide-ranging and demonstrated
> a large variety of different pathologies, and poor arguments, as well
> as of course high-level differences of approach.
I think that clause 9 could be significantly reduced, to something such
as the following, which still captures the main ideas of the current
clause. But we clearly disagree on how much details should go into the
GR, and I don't see us agreeing anytime soon :)
9. systemd provides a variety of facilities besides daemon startup.
For example, creating system users or temporary directories. When
those are better than the current Debian approaches, transitions
should be carried out while ensuring that it is possible for the
non-systemd community to implement support for the new facility in
non-systemd systems, in order to ensure a smooth transition for all
users. This includes, for example, proper documentation of the
specification of the new facility, and a transition plan that allows
enough time to work on alternative implementations of the facility.
Lucas
Reply to: