Re: The plans for Alpine Linux

2016-02-27 Thread Laurent Bercot 

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

Re: The plans for Alpine Linux

2016-02-27 Thread Steve Litt 
On Sun, 31 Jan 2016 13:08:33 -0300
Guillermo  wrote:

> From this thread:
> 
> http://www.mail-archive.com/supervision@list.skarnet.org/msg01123.html
> 
> 2016-01-27 9:16 GMT-03:00 Laurent Bercot:
> >
> >  The biggest hurdle that *every* distribution faces is that every
> > daemon starting script is specific to the service manager, and
> > supervision systems do things very differently from non-supervision
> > systems.
> >
> >  And so, daemon packages need to be separated into "mechanism" (the
> > daemon itself) and "policy" (the way to start it), with as many
> > "policy" packages as there are supported service managers.
> >
> >  I plan to do this work for Alpine Linux towards the end of this
> > year; I think most of it will be reusable for other distributions,
> > including Buildroot.  

Hi Laurent,

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. But there are obstacles:

* Daemon maintainer might not have the necessary time.

* Daemon maintainer might not have the necessary knowledge of the init
  system or 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.

* 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.

SteveT

Steve Litt 
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28