Re: Getting to Topaz (Was Re: getting on a longer release cycled)




Travis:

One thing I'd like to remind people is that typically when a product
bumps the major version number, this involves some evolution in the
underlying interfaces.  I know some of these sorts of issues are being
addressed by Project Ridley (e.g. GtkPrint), but it would probably be
good to consider how we want our Desktop interface stability story
to look after Topaz.  Some suggestions...

1) How could we better navigate people who want to integrate with
   the desktop towards interfaces that the GNOME community recommends?
   Are all GNOME Platform interfaces recommended or just a subset?
   Are some interfaces recommended over others?

2) Should additional interfaces be included in the Platform that
   are not already?  Should libcairo or GStreamer be made part of the
   Platform?  Are there others that would make sense to support in
   a more Stable fashion?

3) Are all interfaces exposed in the latest GNOME Sysadmin Guide
   supported in a stable fashion, for example (such as
   /usr/share/gnome/default.session)?

3) What further items in Project Ridley should be done before Topaz?
   Should libgnome, libgnomeui, libgnomecanvas be deprecated?  Should
   GNOME after Topaz have a different Platform that doesn't include
   deprecated libraries?  Should we deprecated esound in favor of
   GStreamer?  I noticed libgnomeprintui was deprecated, should
   libgnomeprint be deprecated also (or has it been already and I didn't
   notice?)

4) How does the GNOME community want FreeDesktop interfaces to be
   exposed?  It seems the Portland project is controversial.  Do we
   recommend users use Portland interfaces or other interfaces to
   integrate with /usr/share/applications, the MIME database, icon
   integration, etc.  This doesn't seem clear to me.

   Also libcairo is a FreeDesktop library interface, and it isn't
   really clear how this will be managed.  Since it is not a part
   of the platform, I assume an ABI incompatible libcairo-2.0 could
   come out and a new version of GTK+ could use it (as long as those
   libcairo interfaces exposed in GTK+ didn't break).  Might be
   nice if we clarified how we anticipate stability will be managed
   with FreeDesktop library interfaces like libcairo.  Should
   end-users consider using libcairo in a Stable fashion or no?

   Also could consider the same sort of questions about d-bus.

   Should libart_gpl be deprecated in favor of libcairo?

5) How could we better manage the file-system footprint.  I notice
   over 3/4 of the directories in /usr/share are installed by GNOME.
   Could the clutter be better organized?

It would probably be a good thing if we thought about questions like
these so that we would have a better desktop integration story to
coincide with whatever functionality/usabiity improvements we intend
to deliver with Topaz.

Just my 2 cents...

Brian


This kicked off a few ideas for me:

Topaz basically seems to be so massive a change that some extremely
enthusiastic people are flinging high-level concepts at the wiki
(without developing them - I'm responsible for one of these [which I've
since removed]), while others (who seem to tend to be more experienced
developers) are so caught up on feasibility concerns that they're just
focusing on short-term, tangible goals.

So I think the big blocker is that those who are experienced enough to
dive in realize how complex a re-design would be, and just give up on
it. We need to make Topaz development less scary.

Here's my plan:

1. Pick a short list of major concepts to put into Topaz.

We don't need perfect consensus at this stage, but it'd be nice to start
forming some agreement. Concepts ("superfeatures" across the
platform/desktop) would be along the lines of "People as a first-class
object", "Integrating Web apps and desktop apps", "User tasks instead of
individual apps", "Pervasive integration of Creative-Commons artwork,
music, etc.", and so on.

It's important that these be global concepts, and not just "An app to do
'X'" or necessarily "A library that does 'Y'" - I think our current
development process already handles these cases fairly well. Topaz
should be about superfeatures that require concerted, simultaneous
effort from many different projects (which is what we currently _don't_
do well).

2. Have everyone create mock-ups and prototypes of their ideas for these
concepts.

Overlap should be encouraged (ie, multiple meta-implementations of one
concept, multiple meta-implementations of each concept for each
project).

3. Use a process similar to the "proposals for inclusion" to select a
short list of these major concepts and meta-implementations to focus on
for Topaz's first development cycle. These concepts and
meta-implementations would be chosen based on their feasibility and
perceived usefulness.

4. Start implementing.

It seems like the development cycle(s) could work in one of two ways:

A. Gradually; Select a few concepts to integrate _well_ in each 6-month
cycle. Develop in our current lineage, without a parallel branch. Phase
Topaz in without causing significant breakage and panic.

B. In Parallel; Branch for Topaz, and mainly focus on implementing the
short list of concepts in one go (possibly a 12-month initial cycle,
then back to 6 month cycles after that). Continue 2.x releases every 6
months in parallel, though only working on bug fixes, documentation,
etc. Basically like the current releases, but with slightly fewer
features (and hopefully much less developer involvement necessary).


The whole point of this plan is to move forward without getting ahead of
ourselves and rigidly defining ourselves into a corner.

What does everyone else think?

-Travis

On Thu, 2006-09-07 at 23:55 +0100, Jono Bacon wrote:
Hi all,

I think the focus in this thread is a little imbalanced. I think we
really, really need to focus on actually decided on what Topaz is
going to be. I feel that the lack of direction in the project to say
"this is what will be in Topaz" is actually starting to harm us - it
is making us look like we can't make decisions.

Much of the problem is that huge infrastructure changes cannot be
easily hacked on by a single person to gain enough momentum to become
Topaz. Sure, I have my idea of how Topaz should work, and I have
blogged about how the GNOME desktop should be contextual to a project,
and I also fleshed out ideas of interface with MacSlow at GUADEC. But,
I think need to sit down, and make hard decisions about what is
happening with Topaz.

There are distinctive connections and threads of similarity between
what people seem to want to achieve, and this seems to large fall into
the domain of people as top-level objects and such. But, I think we
need to get a core bunch of us together to sit down, thrash out some
ideas and actually start scoping out what GNOME 3.0 should look like.
I have a huge interest in usability, and Jokosher is a product of an
application domain re-thought around usability - I think we need to
decide on this before we start a flamewar about release scheduling.

  Jono
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list




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