[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On Friday 17 October 2014 23:03:37 Wouter Verhelst wrote:
> I would like to see the above clause modified like this:
> "There may be some loss of functionality under sysvinit if the package
> is still basically functional."
> Rationale: I don't think that "the maintainer believes the loss of
> functionality is acceptable" is a good test for whether the cost is
> worth the benefit. Rather, that test should be about "how hard is it for
> a maintainer to support the alternative init system". If a maintainer
> thinks that, say, a power manager written to read /sys/power directly
> but control things through systemd is useless without the ability to
> suspend the system, they might well remove all support for non-systemd
> systems; if someone else believes otherwise and sends in a patch, under
> the proposed language the maintainer would be able to reject such
> patches.
> As such, in the spirit of §2.1.1 of the consitution, I would therefore
> like to see something along the lines of "in the absense of patches,
> it's okay for a maintainer to remove support for non-default init
> systems if they have no desire to maintain that support themselves, but
> maintainers should not reject patches implementing such support without
> a sound technical reason".

I do partly agree with you in here. The part that I do not agree with is: 
supposing Mike the maintainer receives a patch from Peter the patcher to 
support $foo then Mike would be forced to ship the patch most possibly as a 
delta from upstream.

Now a new version of the software arrives and the patch does not applies 
anymore, needing a big refactoring. Peter doesn't shows up and Mike is forced 
to either drop the support (would that become RC bugs?) or do the refactoring 
himself. All I can see is problems for Mike, added to what he already has.

We could also add broken API/ABIs if the package in question is a lib, big 
deltas from upstream, etc.

I think we should still leave that to the maintainer unless overridden by the 

I am two fools, I know, for loving, and for saying so.
  John Donne

Lisandro Damián Nicanor Pérez Meyer

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: