Re: Planning for GNOME 3.0

[Sandy Armstrong <sanfordarmstrong gmail com>]

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,
> > right?)?
>
> 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.

Sandy