On 03/02/2016 18:30, Steve Litt wrote:
> The situation you describe, with the maintainer of a distro's
> maintainer for a specific daemon packaging every "policy" for every
> init system and service manager, is certainly something we're working
> toward.
This is certainly a possible, even a desirable, setup, but it is not
necessary. One of the advantages of small package granularity is that
you have more flexibility in maintainership - you don't have to assign
the same maintainer to all the packages in a set. And that overcomes
most of the obstacles:
> * Daemon maintainer might not have the necessary time.
Not a factor for the initial split: there isn't more total code.
Could become a factor when you add service managers, but the amount of
maintenance needed for 2 or 3 service managers should remain negligible
before the amount of maintenance needed for the daemon itself.
> * Daemon maintainer might not have the necessary knowledge of the init
> system or service manager.
Then acquire it. You're a maintainer for a distribution? You better
know how your distribution works. How all supported ways of starting
your daemon work. That's your job as a maintainer.
If it's really not possible, assign the maintainership of the package
with the new service manager policy to someone else, who knows the new
service manager.
> * Daemon maintainer might be one of these guys who figures that the
> only way to start up a system is sysvinit or systemd, and that any
> accommodation, by him, for any other daemon startup, would be giving
> aid and comfort to the enemy.
If you're disagreeing with the political choices of a distribution, why
are you sticking with that distribution?
See above: don't make people maintain things they don't want to maintain.
Find someone else who will. Small granularity to the rescue: I certainly
do not want to maintain mysqld, but I could probably be talked into
maintaining mysqld-init-s6rc if there was absolutely nobody else for the
job.
> * Daemon maintainer might be one of these guys who tries to (example)
> Debianize the run script to the point where the beauty and simplicity
> and unique qualities of the service manager are discarded.
That is a common risk with every package, and is orthogonal to the amount
of supported service managers, or their nature.
I am not saying the obstacles are not real, or hard to overcome. I realize
they most certainly are. I am saying that the issues you are raising are
all of a human nature, not a technical one, and at this point that is not
what I want to focus on. When designing a solution, I am passionate about
being dispassionate; if the path to technical excellence is riddled with
hardships the only possible answer to is "get better maintainers", then
so be it. There will always be time to compromise later.
--
Laurent
Received on Sun Feb 28 2016 - 01:12:19 UTC