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

Bug#727708: init system other points, and conclusion



On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
> Josselin Mouette <joss@debian.org> writes:

> > It shouldn’t come as a surprise that it is hard for developers to
> > respect the TC’s decisions when we see disrespectful sentences like the
> > one above from some of its members.

> I agree.

> We are of course each entitled to hold opinions about such things, but I
> would strongly prefer if we could all try *very* hard to keep such
> assertions out of TC discussion.  They have no place here.

I recognize that we as TC members have a moral duty to not gratuitously
demotivate Debian contributors.  However, the duty to not alienate
contributors is secondary to our duty of defending the technical integrity
of Debian, and so I stand behind that comment and am going to elaborate with
reference to an example so that the other members of the TC, and the GNOME
team, understand exactly where I'm coming from.  (The example is from a
question that was referred to the TC in July 2012 - bug #681687 - so it may
ring a bell for some here.)

For several years the GNOME Team ignored section 9.7 of Policy, concerning
integration with the MIME handling system.  They did this in favor of
implementing the related freedesktop.org on the grounds that the fd.o
standard is technically superior (and less work, since it was already
implemented upstream).

As it happens, I think the fd.o standard *is* technically superior (and I
think any other member of the TC who looked at the question would agree).
However, "my way is technically superior" is not a valid justification for
ignoring Debian Policy.  Policy is not *just* about being technically
better, it's *also* about having consistent behavior that all packages in
the archive can coordinate around.  No single upstream, no matter how large
or prominent they might be, has any business dictating behavior that
contradicts Debian Policy; Debian exists as a distribution to provide a
coherent, integrated OS, not to deliver half a dozen incompatible upstream
experiences to our users, and when Policy needs to be changed it needs to be
changed with transition handling in mind.

Each Debian maintainer has an obligation to ensure their packages comply
with Debian Policy, regardless of what direction upstream is headed in.
Sometimes this means writing compatibility code that's Debian specific;
sometimes it means getting Policy changed so that packages have new, better
rules guiding their integration.  Never does it mean silently ignoring the
issue as The Other Maintainer's Problem.

In case anyone missed it at the time,
https://lists.debian.org/debian-devel/2012/01/msg00830.html is the start of
a very long thread on this topic two years ago, when it came to the
attention of the wider project that Josselin had dropped support for mailcap
from evince, the single pdf reader that many Debian users had installed on
their desktop.  (Other packages, such as the eog image viewer, had dropped
their integration long before, but with a lower impact than evince.)

What struck me in that discussion is that at no point did the GNOME
maintainers raise this issue on debian-devel or debian-policy to ask for
help with this integration problem.  Instead, they uploaded breakage to the
archive and waited for users to trip over it, apparently in the belief that
if no one had provided a fix by now - /for the bug they had not asked the
developer community for help with/ - that such an automated system was not
important enough to worry about complying with policy for. 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658139#29)

Ultimately, bug #497779 and bug #658139 were resolved by someone
volunteering, in response to that thread, to implement an automated tool for
merging .desktop files into mailcap for backwards-compatibility.  This was
the desirable outcome all along; however, it happened in spite of the GNOME
Team, not because of them, and after a fair amount of good will had been
spent on both sides in the list discussions.  I completely understand the
GNOME Team not having time to write (or maintain) the tool to do this
automated conversion.  What I don't find acceptable is their not bringing
this issue to the project's attention /and asking for help/.

Maybe 'obstructionist' is not the right word.  But the GNOME Team has a
pattern of failing to engage constructively with the rest of the project
around crucial integration issues.  Josselin claims that a comment from a TC
member calling this out makes it difficult for developers to respect TC
decisions.  I counter that the GNOME Team's past handling of such problems
shows an existing lack of respect for project values and procedures, and I'm
merely giving voice to a view widely held among Debian developers who would
in fact be more than happy to contribute to improving GNOME's integration in
Debian, if only they believed this help would be welcomed by the current
package maintainers.

While I stop short of calling for the formal censure of the Debian GNOME
Team as Ian has in the past, I think the GNOME Team should take a hard look
at how their own actions have contributed to any sense they might have that
they lack the resources to comply with Policy.  I don't think it's a
coincidence that over the past two years, over a quarter of all the issues
decided by the TC have related to GNOME packages.


To reconnect this with the actual point of this subthread:  it is entirely
possible that the TC will decide that systemd is the technically better
solution for Debian to move forward with; and any member who thinks this
should certainly vote accordingly.  But if the members of the TC do
*not* think this is true - if, indeed, our collective preference is for
upstart rather than for systemd - then I don't think we should be swayed by
assertions that GNOME upstream is tethering itself to a specific init system
and that the current GNOME maintainers may force the issue by uploading
packages to the archive that have a hard dependency on systemd as PID1. 
That's nothing more than hostage taking, especially when there would be no
difficulty getting cycles for the integration bugs with GNOME and whatever
init system Debian standardized on... *provided that* the GNOME maintainers
showed themselves open to this work instead of blocking it.  From Joss's
reply to my message, it seems altogether too likely that he *would* block
such work.  But that is a bridge we should cross when we come to it, not
something we should allow to drive the future course of Debian...  nor
something we should beat the GNOME Team up about before it's actually
happened.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: