Re: GMAE release suites

[Vincent Untz <vuntz gnome org>]

Hi Murray,

Le mercredi 02 mai 2007, à 16:44 +0200, Murray Cumming a écrit :
> * A GMAE release suite:
> 
> The GMAE members (people on gnome-embedded-list) would like us to have
> some clearly-defined release suites for GMAE, released on the regular
> GNOME schedule, for GNOME 2.20. To start with that can probably just be 
> 
> GMAE Developer Platform:
> atk+
> pango
> glib
> gtk-doc
> gtk+
> libxml
> 
> That will usually be exactly the same versions that ship with regular
> GNOME:
> http://live.gnome.org/TwoPointNineteen/Platform
> But at times in future the might lag - for instance, when people
> couldn't use GTK+ >2.6 before the performance problems were fixed.
> It might also involve different recommended build options in future. For
> instance, gtkmm has an optional reduced API, chosen during configure,
> and there was talk of doing something similar for GTK+.
> 
> The main idea is just to have a clearly-defined list to avoid vagueness
> when talking about GMAE software, and to present this list to people who
> don't want to be overwhelmed with the complete GNOME module list. And to
> show that, yes, it does build.
> 
> We'll need an equivalent list of external dependencies.
> 
> 
> * Extra release suites:
> 
> We will want to add some other suite, with less-API-stable stuff such as
> gstreamer and evolution-data-server. I can't think of a good name for
> that.
> 
> We should avoid including stuff that's due for deprecation, and that
> might even mean not including gnome-vfs. We have to make up our minds
> about things like gconf, but I suggest we do that by starting small and
> gradually adding.
> 
> I think it's too early to make a GMAE applications suite, but that
> should be expected for the near future.
> 
> We might want to call these "GNOME Mobile" release suites, rather than
> GMAE release suites. I'm not sure what the current branding is.
> 
> 
> * Building (smoke-testing):
> 
> To start with, it's fine to just make sure that this builds on a regular
> desktop, using the regular jhbuild moduleset idea.
> 
> We would also like to make sure that the jhbuild moduleset works inside
> a scratchbox environment, though we'd have to choose an arbitrary
> scratchbox rootstrap for that - probably the Maemo 3.1 SDK for now.
> 
> We'd also like to distribute OpenEmbedded or Poky packages if we can
> manage that. Matthew Allum ( mallum openedhand com ) should be able to
> take care of that, or find someone who can. It would be nice to have.
> 
> There's also interest from Igalia in setting up BuildBrigade stuff for
> this, even intergrating with scratchbox and/or OpenEmbedded. But I don't
> think it would be wise to depend on that for GNOME 2.20.
> 
> 
> * Getting it done
> 
> So, does the release team think this is OK? Can you take over
> responsibility for making sure that the releases suites are defined and
> released, asking for whatever help you need from us?

This is really something that I think we should do. The main issue here
is manpower, I guess. We'll probably need someone working on GMAE to
push for this.

Some more comments:

 + we might want to rename the GNOME Developer Platform to GNOME Desktop
   Developer Platform?

 + sounds interesting to also have a GMAE Bindings suite (with the right
   configure flags for gtkmm, eg)

 + someone from GMAE will need to figure out the external dependencies

 + GNOME Mobile sounds better, indeed

 + I agree on the "extra platform", or whatever it could be called.
   Maybe "Platform lab" or something like this...

 + e-d-s in GMAE environment is usually the OpenedHand e-d-s. We'd need
   a tarball to include it.

 + someone will need to define the rules for module inclusion in the
   Mobile suites. The rules that we have for the various desktop suites
   are probably a good basis.

 + I'm not sure that, in the long term, it's a good idea to keep GNOME
   Mobile and GNOME Desktop schedules in sync. Is it useful? 6 months
   might be short without any real need for software that will be
   shipped on specific hardware. I don't know. Just raising the point.
   On the other hand, this is important for translations.

 + someone will need to figure out the scratchbox/jhbuild integration
   and make it easy for the release team to use it.

 + I like the Poky idea, although we'll probably need to have a specific
   server to build the packages. Or leave it to Matthew.

 + last but not least: is the current release team the best candidate to
   handle this? Most people in the release team only have a desktop
   background, and not a mobile background. Recruiting people from GMAE
   could help; another solution would be to have a mobile release team.

Sorry for not organizing this reply in a better way, I'm just a bit
short in time today.

Vincent

-- 
Les gens heureux ne sont pas pressés.