Re: Generating excitement in GNOME

["John (J5) Palmieri" <johnp redhat com>]

On Wed, 2007-04-18 at 10:45 -0600, Elijah Newren wrote:

> > I was talking about this to Keith Packard and jg waiting for a flight
> > from Sao Paulo airport and came to the conclusion that we should have
> > some sort of RFC module or futures track which proposed applications and
> > API's would be able to be part of the release with the caveat that they
> > may not be fully adopted or if they are may look completely different
> > once they are accepted into one of the other modules.
> >
> > For instance putting the NetworkManager API's in here would allow us to
> > formally put constraints on acceptance into the platform, give the NM
> > developers a sign that if they do the right things it will get in and
> > give developers a sign that they can optionally depend on it with the
> > knowledge that API's may change. We did something similar with D-Bus'
> > DBUS_API_SUBJECT_TO_CHANGE macro.  While some people complained about
> > changing API's we could just shoo them off by telling them they agreed
> > to it.  The benefits of such were that people experimented and everyone
> > knew D-Bus would eventually become a household API.  It allowed D-Bus to
> > mature much faster.
> >
> > What do people think?
> 
> I'm not sure I follow.  For example, libwnck has such a flag
> (WNCK_I_KNOW_THIS_IS_UNSTABLE) and was long ago accepted into the
> desktop.  What's the difference between your suggestion and what was
> done with libwnck (other than the fact that libwnck wouldn't be in
> 'desktop' but something else)?  gstreamer is similar too...
> 
> Also, your example seems to be covering the future-track-platform side
> of things, but I'm not sure how future-track-desktop (i.e. apps
> instead of libraries) work.  Could you clarify?  Sorry if I'm missing
> anything obvious but I don't feel I'm following your proposal.
> 
> 
> It's awesome to see someone thinking about this and trying to tackle it.  :)

It is mostly a physiological game here.  Setting expectations while
still embracing things that are just not ready yet.  We were pretty
strict what got into the Desktop last round I would like another staging
area for things we can easily take out later.  The problem with the
Desktop is it is looked at as "official" and very hard to remove
components from it without looking unstable.  The few cases we have
there have been clear replacements for the app or API which we had to do
things like create migration paths for.

The futures track or "sneak peek" would be applications and APIs that
look promising but we have little obligations to.  It is just a way to
spur development and debate and give projects motivation.  Applications
in here would not have to conform to the rigid release criteria and
would act more like an outside optional dependency.  There would be some
rules however such as actual working code, active development and clear
goals for being integrated into GNOME at some point.

People get excited over what will be and not usually what they have.
Like storing potential energy which will culminates in future releases.
KDE 4 isn't released yet but people get excited over it.  I hardly hear
any buzz around KDE 3 these days.

I talk mostly about API's because it is the clearer win here.  If we had
people programming desktop applications to say Telepathy, if we landed
it in 2.22 there would already be apps taking advantage of it.  Of
course applications like gimmie and big board also gain advantages here
because young developers may see them as places to shine if they were on
some official track.  I have seen many developers give up a project
because they felt it would never be accepted in GNOME when in reality it
just wasn't ready to be.  Futures track gives them a bit more hope and
direction from us as to how to achieve that goal.  




-- 
John (J5) Palmieri <johnp redhat com>