Re: [gentoo-project] Council: Policy for Systemd units

[Rich Freeman]

On Wed, Jun 12, 2013 at 8:20 AM, Pacho Ramos <pacho@g.o> wrote:
> Also, isn't it already being done with prefix (and some hardened like
> pax_marking) stuff? Why systemd case needs to be different? (well,
> probably people hating systemd so much will know)

It doesn't need to be different.  The issue is that if I ping a
maintainer about adding some prefix variable to their ebuild and they
don't respond, and then I commit that change to their package, then
chances are that all I'll hear back are crickets.  If I were to
instead add a systemd unit to their package there is a chance it will
get reverted, flames on -dev, escalation to devrel, and so on.

Honestly, right now what I'd advocate for systemd unit maintainers is to:
1.  File a bug with the maintainer with a patch asking for the unit to
be added, and indicating that if there is no response in 7 days it
will be commited.
2.  If the maintainer doesn't commit it themselves, then commit it for
them in 7 days.
3.  If the maintainer objects, then if the unit is important tell the
maintainer that you are also going to maintain the package, and commit
it anyway.
4.  If the original maintainer quits, oh well.  Continue to maintain
the package or not per your personal interests.  If the original
maintainer gets into revert-wars/etc escalate to devrel.  As an
additional maintainer be responsive to bugs related to the unit file
you committed.

So, in a sense I agree that no new policy is strictly needed.
However, Council could show some leadership and suggest how people
could work together constructively, whether it is in the particular
manner I suggested or otherwise.

As has already been said in this thread, I don't have a lot of
sympathy for people who threaten to quit when they don't get their
way.

Rich