Re: Generating excitement in GNOME

["Elijah Newren" <newren gmail com>]

On 4/18/07, John (J5) Palmieri <johnp redhat com> wrote:
> It is mostly a physiological game here.  Setting expectations while

s/physiological/psychological/, yes?

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

Ah, this makes sense to me.  Would have been really nice with e.g.
gnome-user-share too.  And it also gives us a way to better handle
things like tracker that might be interesting but really need  proving
time, better communication about use cases, and possibly even just
experience with other module maintainers trying it out more.

Sounds good to me.  Time to propose this on d-d-l?

Cheers,
Elijah