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

[Travis Reitter <treitter-dev netdrain com>]

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
>