external dependencies; trolling for more feedback, pushing to make it official ; -)

On 9/11/06, Matthias Clasen <mclasen redhat com> wrote:
The topic came up earlier, and I think there was a general consensus
that it is a good idea to freeze the versions of external dependencies,
and use tarball modules for them in the gnome-2.18 moduleset in jhbuild.

Due to the feedback received so far, I've modifed the exact wording of
the proposal and the list of versions a couple times so far.  I
thought it'd be worth posting the most recent version and asking if
there was any further feedback on it or objections to it being

 The basics:
   The versions of external dependencies that Gnome module may depend
   upon are listed on a link from the release schedule
   (http://live.gnome.org/TwoPointSeventeen/External Dependencies,
   for this release).  It may be updated at any time by the

 Getting the list updated:
   If you want to add a new dependency or want one of the versions
   updated, make a good case for it on desktop-devel-list. In
   particular, provide reasons why it is important to bump the
   version number, explain any impact (compile and run time) on other
   modules, and list any additional external dependencies it would
   pull in. Be prepared for others to take a few days to test it (in
   particular, to ensure it builds) before giving a thumbs up or

 Available enforcement mechanism:
   If a module depends on either a new external dependency not listed
   here or a newer version of an external dependency than one listed
   here, we may revert to an older version of that module for Gnome
   2.17.x (which may result in reversions of other modules too). The
   development version of that module can again be used once either
   this page is updated by the release-team or the new(er) external
   dependency is made optional.

Two special cases worth noting (and already documented on that page):
 (1) xulrunner from cvs will still be used until the 1.8.1 release;
     Christian has pointed out this is needed for current Epiphany,
 (2) David has already made some pretty convincing arguments that
     we'll want to adopt HAL & 0.5.9 once they're out; this
     isn't really so much of a special case, as just notice that we
     need to work out build issues so that those without a bleeding
     edge OS and not testing/developing/documenting HAL related
     functionality can still easily build what they need.  Help

Thanks for your awesome work everyone,

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