Re: GUADEC meeting

On 5/13/05, Jeff Waugh <jdub perkypants org> wrote:
> <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. ;-)

I'm talking about tossing the monolithic 'in or out'. If you're a
gnome app, and you don't release every six months, fine. If you're
still better than something that releases every six months on other
criteria, you'll get rated higher.

> 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)

No offense, Jeff, but you've been talking about this for nearly three
years now. And promising a written discussion of the issue for exactly
that long. I'm not waiting for you again. :)
>  * 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. :-)

Not unreasonable in general, though I fear that more complexity in
answering 'what is gnome' is not really great.


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