Re: Choice Hartmans1a

[Sam Hartman <hartmans@debian.org>]

>>>>> "gregor" == gregor herrmann <gregoa@debian.org> writes:


    gregor> Thanks for the clarification.

I am going to accept Holger's proposed changes and post this as an
accepted amendment to Proposal A.

    >> I'd appreciate help in achieving these goals without undermining
    >> the text in debref.

    gregor> I think the main problem is actually that you try to write
    gregor> down NMU rules in a GR; where they do not belong, as the NMU
    gregor> guidelines develop in practice and are reflected in the
    gregor> process of updating DevRef.

We're not in agreement on what belongs in a GR, especially in this GR.
I wonder if you believe that a GR sets long-running policy that would be
hard to overturn.

Yes, a GR can do that.
But This choice on this GR doesn't do that.

Quoting in part:

>The project issues the following statement describing our current
>position on Init systems, Init system diversity, and the use of
>systemd facilities.  This statement describes the position of the
>project at the time it is adopted.  That position may evolve as time
>passes without the need to resort to future general resolutions.

That is, this describes where we are today.
That can move along over time.

And yes, people can point back to the GR result and use that as a
justification.  For example if choice hartmans1A won the vote, and the
next day someone proposed we throw out sysvinit, it would be reasonable
to argue that it was exceedingly unlikely the project had changed its
mind in a day.  Even two years down the road, if someone proposed
throwing out sysvinit, you would presumably ask them to demonstrate a
consensus to do so or significant changed circumstances before seriously
considering the proposal.

But even a month later if the NMU guidelines had changed, arguing that
outdated text in the GR about NMUs no longer applied would be entirely
reasonable.
This GR is about  systemd and init systems, not NMU guidelines.
If it touches on NMU guidelines in an auxiliary manner, it's reasonable
to assume it does not stop the evolution of those guidelines.

Now, if choice hartmans1a passes, it would  be reasonable to discuss the
impact on the ability to fix init system related bugs in a discussion of
NMU guidelines.  I think that's fine and reasonable.
You wouldn't be obligated to keep things working the same, but someone
should argue you could, just as they could argue in favor of the status
quo in a number of ways.


Why do I wantto emphasize that you can NMU in choice hartmans1a?
Because one of the thing that various proponents of init diversity have
requested is the ability to do work without people blocking them.  Being
able to NMU gives a significant part of that, so I want to emphasize how
the option meets (or partially meets depending on your opinion) that
desire.