Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
Hi Luca,
On 18/10/14 at 15:53 +0200, Luca Falavigna wrote:
> 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).
While I understand your concerns, I think that it is highly unlikely
that we will decide to change the default init system to something that
would break existing packages without a known reasonable way to fix
them.
> > (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).
Both:
[...] if they consider it necessary to prevent delivering broken,
buggy, or otherwise incomplete software packages
and:
to render software usable to the same extent
are quite far-reaching criteria to allow maintainers to break
standardization.
I value standardization and integration very highly, and would be more
comfortable (more likely to vote this above FD) with e.g.:
On the other hand, Debian maintainers are fully entitled [...], if
they consider it necessary to prevent delivering broken software
packages, or software packages that would be unsuitable for a Debian
release.
and:
; and no patches or other derived works exist in order to support
other init systems in such a way to render software basically usable.
However, we can agree to disagree on the above.
Thanks for the clarifications!
Lucas
Reply to: