Re: Planning for GNOME 3.0

On 04/13/2009 10:07 AM, Frederic Peters wrote:
Sandy Armstrong wrote:

I sympathize with the desire to compete and innovate, but Dave's
criticisms resonate with me: this doesn't feel like a community decision.

It may not have been clearly stated in the "Planning for GNOME 3.0"
email but of course the discussion is open, and welcome, in his blog
Andre for example started with the following paragraph:

   Today I have released a GNOME release schedule proposal for 2.27 and
   2.29 (please keep discussion streamlined on desktop-devel mailing list
   instead of e.g. the comments section of this blog).

So, the whole thing is not a community decision, it is just the result
of the release team thinking about 3.0, and *discussing* the plans
with other people, be it in real life, at GUADEC, at the user
experience hackfest, in other events, or in digital life.

Nevertheless, while the plan is final (but flexible), it doesn't sum
up 3.0 by itself, at the end it will be the community that will decide
what goes in, simply by focusing of areas of interest.

I think you are missing my point. The inclusion of gnome-shell did not follow the usual module inclusion process. Or maybe I am misunderstanding what you mean by "the plan is final".

If this were a regular module proposal email, I'd have pointed out a few
things that concern me:

  * What is the a11y story for gnome-shell and mutter?  Eiphany+Webkit
has blocked on this for several cycles now.

It has been repeated many times accessibility is important, it is a
great asset of GNOME, and I want to keep it that way.

The 3.0 schedule has this item for April 27th: "Clear a11y plan and
schedule MUST exist for 3.0 and must be in place for 2.29.5. Define
acceptable regressions." The plan is not yet clear, but we want it
to be, soon, because we care about a11y.

If Epiphany/Webkit is not ready when a release comes around, it is not included. This rule does not seem to apply to gnome-shell. Instead, the release schedule is pushed back.

  * What is the applet story for gnome-shell?  As the maintainer of a
GNOME applet (Tomboy), I accept that there may be significant work to
port our applet to a new infrastructure, but now I'm concerned that I
will also need to *create* that infrastructure (because gnome-shell is
basically being imposed upon us, and not going through the regular
process, I can only assume that if there's no applet infrastructure,
it's my fault for not caring enough to contribute one).

I expect gnome-shell people will have a proper answer here; I remember
a few exchanges going on about the i18n clock applet, but can't locate
them at the moment.

From hanging out in #gnome-shell and reading gnome-shell-list, I have seen that there is no clear plan for this, little interest on the part of lead developers, and contradicting answers that seem to converge mostly on the idea of a separate workspace hosting Dashboard-like widgets (which, in my opinion, is an irritatingly modal approach).

Normally we get to test an app and understand its impact on the rest of the Desktop suite before deciding to include it in GNOME.

  * People keep hand-waving the hardware requirements issues, but didn't
Federico's deployment survey [0] show that almost half of all GNOME
deployments are done via thin clients?  We can't just pretend that we're
not going to have to continue supporting these users.

Jason Clinton pointed somewhere else in this thread: "An approach
similar to what Dave Richards is using at City of Largo is actually
the right way to do this: the compositor and a few video-intensive
apps run locally on the hardware. There's no technical reason that
Shell couldn't do the same thing."

I was including Jason's post when I referred to "hand-waving". This obviously increases the cost of each thin client, and will surely require an upgrade for many existing thin client installations.

Aslo my current laptop, my development laptop, will be five years old
next week, and I really want to be able to run 3.0 on it. We have been
tackling performance problems in many places, for many cycles, this
won't go to a waste.

Normally we get to evaluate the performance issues of an app before deciding to include it in GNOME.

And lastly, until all of these issues are resolved, I am very concerned
about the inevitable differences (and tensions) between distros and
upstream GNOME for the next few years.  Do we really want this to be
like KDE, where some distros ship 3.x, some ship 4.x, and some ship both
(then the user can only blame themselves for making the wrong choice,

We definitely do not want, and it is noted in the 3.0 plan: "we should
be ready to diagnose early on during the 2.29 development cycle and we
should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for
GNOME 2.32 for the 3.0 release"

Well, I am glad that we are ensuring that gnome-shell will not suck for 3.0. Normally we wait until an app does not suck before deciding to include it in GNOME.

(not saying gnome-shell sucks, I've never used it, but so far its unsuckiness has not been verified for me)

What other changes in GNOME 2.30 depend on inclusion of mutter and gnome-shell? Not really sure why we are willing to hold back the 2.30 release, instead of holding back the inclusion of gnome-shell.

Hopefully my use of obnoxious repetition has made my point easier to understand.


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