Re: Sorting out external dependencies

[Olav Vitters <olav vitters nl>]

On Thu, Apr 14, 2011 at 11:15:49PM +0200, Frederic Peters wrote:
> ** 1st level : established, stable, system modules, they have been in
> place for a long time, with stable API and ABI, and they exist in
> sufficient versions in the distributions commonly used by GNOME
> hackers, even in older but still used versions (Fedora 13 for
> example).
> 
> Examples : libxml2, libpng, dbus...
> 
> Proposed guideline : mentioned as dependencies with a base version,
> not built by default by jhbuild.

jhbuild should track and install the packages for debian/ubuntu, fedora
and opensuse (packagekit)

We should considerably lower the effort that is needed to get jhbuild
working.

> ** 2nd level : modules developed outside GNOME, with little attention
> to our schedule, but with an active development, and where we want to
> track recent code.
> 
> Examples : mozilla (js-185 nowadays), poppler.
> 
> Proposed guideline : built from tarballs, version bumps whenever a
> module need a new version.

Need distribution perspective (ok by them?). Plus ensure the bump makes
sense (don't track alpha stuff which would never have be stable before
our release).

I actually skip mozilla in jhbuild, but I do build poppler. Think
they're different somewhat. Cannot explain why :)

> Rationale : we need recent code, but we do not want to arrive on a
> release days with modules failing to build because they require some
> code only available in $DVCS.

Is this ok with distributions? Current policy mentions to ask on the
mailing list. Don't recall any objections, but also: at the moment we
bump only when needed, not immediately.

Still seem to make sense.

> ** 3rd level : libraries developed outside GNOME, with attention to
> our schedule (i.e. we can ask for a tarball and get it in two days).
> 
> Examples : webkitgtk, polkit.
> 
> Proposed guideline : treated like any other GNOME module, built from
> latest git.

Also that freedesktop input thing would fit in here (the one needed by
control-center).

> Rationale : we do not need to put extra burden on modules that are
> close to us.
[..]
> A glaring omission is the process required to get into one of those
> classification, I left it out because I think it should be discussed
> at the same time as the changes to our "new module proposals" process.

I think what Matthias suggested is nice. Get rid of module proposals,
only do feature proposals. Then if some new dependency is required, it
is part of the feature process.

Though need to ensure our external dependencies don't expand too much
(too much stuff being considered a feature).

-- 
Regards,
Olav