Linked by Thom Holwerda on Mon 14th Mar 2011 18:59 UTC
Talk, Rumors, X Versus Y And over the weekend, the saga regarding Canonical, GNOME, and KDE has continued. Lots of comments all over the web, some heated, some well-argued, some wholly indifferent. Most interestingly, Jeff Waugh and Dave Neary have elaborated on GNOME's position after the initial blog posts by Shuttleworth and Seigo, providing a more coherent look at GNOME's side of the story.
Permalink for comment 466185
To read all comments associated with this story, please click here.
Clarifying rules for external dependencies
by dneary on Tue 15th Mar 2011 10:48 UTC
Member since:

From :

In the interests of full disclosure, I sent a couple of emails to Mark explaining what I understood was GNOME’s policy towards dependencies. To ensure accuracy, I then spoke to 2 members of the release team, who both confirmed the policy for me. One of the members said some pretty strong things in his comments, which I tempered (without modifying the sense) in my email to Mark.

Here’s an extract from the first email I sent to Mark, where I describe my understanding of external dependencies:

> Mark Shuttleworth wrote:
> > It’s difficult to know what external dependency processes are for: some
> > say they are to bless existing decisions, others say they are a
> > requirement for those decisions to be taken.
> I’m writing a follow-up blog entry and I hope that I can clarify that
> for you. There seems to be no such confusion for the release team (at
> least, in the 2.x era): an external dependency is a non-GNOME module
> which is a dependency of a package contained in one of the GNOME module
> sets. And since libappindicator does not fit that definition, there is
> quite simply no need for it to be an external dependency. I can point
> you to 3 or 4 precedents, if you’d like.

Here’s the full email I sent to Mark after speaking to release team members, from which he cites above:

> I got you what is, as far as I can tell, a definitive answer on this.
> First, extracts from the release team policies:
> ** From
> “Do not add any external dependencies other than those already approved
> for that cycle (e.g.
> This
> includes not depending on a newer version than what is already approved.”
> ** From
> # I need a new dependency. What should I do?
> * New dependencies for features should be added as soon as possible.
> There are three possibilities for dependencies: make them optional,
> bless them as external or include them in one of our suites. New
> dependencies should be known before feature freezes. A dependency can be
> proposed for inclusion AFTER the 2.27.1 release because it might need
> more time to be ready.
> # How to propose an external dependency?
> * If you want to add a new dependency, make a good case for it on
> desktop-devel-list (this may only require a few sentences). In
> particular, explain any impact (compile and run time) on other modules,
> and list any additional external dependencies it would pull in as well
> as any requirements on newer versions of existing external dependencies.
> Be prepared for others to take a few days to test it (in particular, to
> ensure it builds) before giving a thumbs up or down.
> Now, in practice:
> 1. If a maintainer wants to add optional (compile-time) support for a
> new feature that uses a library, there is nothing they have to do beyond
> commit the patch, and let the release team know.
> 2. If a maintainer wants to add unconditional support for a feature
> which requires a new dependency, then they should first write the patch,
> then propose the dependency for inclusion in the next release.
> Traditionally, the bar for external dependencies has been low, modulus a
> number of conditions. There is reason to believe that the bar for
> libappindicator would be higher, because of the history involved. One or
> more maintainers arguing for the functionality would help.
> I have talked to 2 release team members specifically about
> libappindicator, and have been told by one that:
> * Since libappindicator has a CLA, it can’t be included in the GNOME
> module sets under current policy
> * It could be included as an external dependency, but would meet some
> opposition because of duplicate functionality with libnotify
> and by the other that:
> * libappindicator doesn’t make sense as a GNOME dependency because it is
> only useful with Unity, which is not part of GNOME
> * adding appindicator support will only make apps better on one distro,
> and don’t benefit GNOME as a whole
> * If people want to make their app integrate with Unity they’re free to
> do so, but they should add a configure option so the release team
> doesn’t have to worry about it
> * For core GNOME components, providing deep integration with other
> desktops is probably a non-starter
> This is of course all personal opinion on the part of the 2 people I
> spoke to.
> In short, it’s an unnecessarily emotional issue which has been
> aggravated by all concerned. But if module maintainers want to support
> libappindicator, then they are able to do so. And if you can persuade
> the shell authors to use appindicators in the same way as Unity, then
> there would be nothing apart from copyright assignment preventing
> libappindicator being part of the GNOME platform.

Hopefully it’s clear that Mark’s reading of my email is selective at least. There is no disagreement between the two release team members I talked to, the policies for dependencies are clear & unambiguous, and as others have said, there is no need to do anything if proposing optional compile-time support for a new dependency.

The relevant release team guidelines I quoted are also consistent with the position the release team took for libappindicator.

In fact, the release team adopted almost exactly the same position for libnotify when it was first proposed for inclusion, in 2.20:


Reply Score: 1