On Friday 17 October 2014 23:03:37 Wouter Verhelst wrote: [snip] > 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 TC. -- I am two fools, I know, for loving, and for saying so. John Donne Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
