Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain

[Luca Falavigna <dktrkranz@debian.org>]

Hi Lucas,

Thank you for your feedback!

2014-10-18 14:13 GMT+02:00 Lucas Nussbaum <lucas@debian.org>:
> 1) packages may require the default init system if:
> - their maintainer consider this a prerequisite for its proper operation
> - no patches or other derived works exist in order to support other init
>   systems
>
> 2) packages may require an init system other than the default init
> system if:
> - their maintainer consider this a prerequisite for its proper operation
> - no patches or other derived works exist in order to support other init
>   systems, including the default init system
>
> These two cases are very different.

I agree. I consider the first case the actual policy (or best practice, as
worst), and I'm still in favour of it. The second case tries to address the
cases where some packages will become immediately RC buggy because of a
change in the default init system.

The following scenarios could happen if a change in the default init system
occurs anytime in Debian:

The workflow without this proposal would be something like this.
* Maintainer is notified her software no longer works with the default init
* Maintainer looks how to support the default init (asking advice upstream,
  welcoming patches from other contributors, writing patches herself, etc.)
* If nothing can be done, the package becomes unsuitable for a release, and
  maintainer could be probably advised to ask for the removal of the software.

The workflow after this proposal would be something like this:
* Maintainer is notified her software no longer works with the default init
* Maintainer looks how to support the default init (asking advice upstream,
  welcoming patches from other contributors, writing patches herself, etc.)
* If nothing can be done, maintainer can inform users about the requirement
  of a specific init system as PID 1, leaving users the freedom to switch
  the default init system. This can be done by explicitly add a dependency
  to a package which switches the default init system.
(Note that I consider out of scope for this proposal to discuss a method to
 prevent an accidental change of default init system).

> (2) could lead to fragmentation in the services/init systems available in
> Debian, because it would no longer be the maintainers' responsibility to
> ensure that all packages work with the same init system.

I still consider maintainers' responsibility to aim for maximum
standardization, including, but not limited to, the default init system
the software they package and distribute will run upon.

As I stated in the Rationale paragraph:
"if [maintainers] consider [requiring a specific init system to run as PID 1]
necessary to prevent delivering broken, buggy, or otherwise incomplete software"
maintainers could decide to strictly depend on a specific init system if there
is no possible way to avoid that (key word: *necessary*).
On the other hand, if solutions exist (#2), they could consider applying such
solutions, or being overruled by fellow developers (#3).

Cheers,
Luca