Re: GUADEC meeting

[Jeff Waugh <jdub perkypants org>]

<quote who="Luis Villa">

> > We've always wanted to franchise the release schedule outside of GNOME,
> > so maybe this is a good time.
> 
> What about just tossing the notion of release altogether and basically
> issuing a list that says 'these apps are the best possible GNOME desktop;
> if you don't like $appX for some reason, here are the alternatives in
> descending order of gnominess.' Could still have the six month cycle as a
> criteria for gnome-iness.

You start with tossing it and end with the six month cycle as criteria. ;-)

So I disagree with tossing it, but recently I've been thinking how/if the
following things could help us:

 * Franchise the release process (I've been talking to the GNOME Office
   dudes and GPE about this, I'm sure there are other targets, but I just
   picked some nice ones to start with)

 * Split "platform" and "desktop" into four suites, to make compatibility
   lines clearer:

     "Bedrock" -> GTK+ family, gnome-print, GConf - all the ones we're
     quietly telling ISVs we believe are usefully stable. We need to make
     these *the* GNOME integration libraries. Clear and precise. Developers
     shouldn't need anything else to make a good, functioning, integrated
     GNOMEy app. These are definitely C.

     Platform -> less stable libraries available for particular needs,
     documented interface stability, not necessarily as solid as "Bedrock".
     I see gda, libgoffice, chunks of the current platform sitting here.
     There is no really solid requirement for these to be C, given that we
     may have d-bus interfaces or simple client libraries, etc.

     Desktop -> much like the "Bedrock" platform, this would be a really
     limited scope set of things that have consistent interfaces and must be
     assumed to be available on any GNOME desktop system. Panel, Nautilus,
     Session, etc. The essential difference is that we start to establish
     strong interface stability further in these crucial desktop components
     (which is very important for ISVs). Much of the interfaces here will be
     defined by file formats and locations, command line tools, freedesktop
     standards, etc.

     Everything else -> if you're on the six month release cycle, you're in
     the game. You get in the release notes, you get in the feature list,
     etc. This is where the franchising of the release process happens. We
     make sure it's easy to be in the loop, and get your info into release
     documentation and so on. I created devel-announce-list thinking that
     this may happen in the future.

You can see I'm thinking about ISVs at the same time as thinking about the
language issue. :-)

- Jeff

-- 
GUADEC 2005: May 29th-31st                           http://2005.guadec.org/
 
      "Openness cannot be assumed, it must be asserted in order to be
                       assured." - Christopher Kelty