Re: Generating excitement in GNOME
- From: "Elijah Newren" <newren gmail com>
- To: "John (J5) Palmieri" <johnp redhat com>
- Cc: release-team gnome org
- Subject: Re: Generating excitement in GNOME
- Date: Wed, 18 Apr 2007 10:45:24 -0600
On 4/17/07, John (J5) Palmieri <johnp redhat com> wrote:
I am sure you guys are well aware that many people found our last few
releases boring. I have argued that boring is actually good as people
are working on the less sexy bits so that GNOME becomes more stable and
that the more sexy bits are being work on but have yet to be proposed or
are just not ready for inclusion into GNOME.
My opinion is that this is mostly a function of lack of "sneak peek"
articles (that Davyd used to make) and a drop in the effort that went
into the release notes. Compare
http://www.gnome.org/start/2.14/notes/en/. People aren't going to dig
into GNOME to found out all the differences themselves; they're often
going to form opnions of the new release before even trying it based
on what they read. If we don't provide them much information, they'll
believe not much was done.
I may be wrong, but that's my (possibly unfounded) guess on the crux
of the problem.
That said, I do think other changes may be helpful too. So I'll try
to add some other comments.
That being said I don't think the problem is sexy things aren't
happening in GNOME but that we just don't advertise them. Things like
telepathy, gimme and bigboard. Many people also fail to start projects
because they think the rejection from not being in GNOME means they will
never be part of GNOME. It also sucks because we land API's in a
release but no one uses them because they weren't in previous releases
so no one experimented with them.
Yeah, I think we're on a similar wavelength here. Going off on a
slight tangent, Dave Neary has been talking for a little while about
making the GNOME tent bigger (which might mean officially including
the sexy closely-related-to-GNOME projects). He wrote up some of his
ideas at http://live.gnome.org/ReleaseSets (which I just stumbled upon
randomly; I haven't talked to him about it). I'd like to hear your
thoughts (and everyone else's) on those ideas of his. There may be
other similarities to what you are proposing below...
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. :)
] [Thread Prev