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
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
