Re: 2.4 Proposed Modules - 2 weeks left

[Havoc Pennington <hp redhat com>]

On Tue, May 06, 2003 at 10:27:03AM -0700, Peter Korn wrote: 
> Or are you suggesting that it means "there are no fundamental barriers to
> supporting theming, keyboard operability, and the AT-SPI, but we simply
> haven't gotten around to doing much work there"?  

That sounds good.

Or simply: is the big picture of the application correct.

What matters is that we are moving in the right direction overall.
If we adopt Mozilla in 2.4, then Epiphany in 2.6, then khtml in 2.8, 
then some other thing in 3.0, then that's what would be broken.
We can't be changing everything all the time.

So one primary decision-making factor needs to be whether the code
being evaluated is a subset of where we want to end up.

If Epiphany is a subset of the end goal, then it's just a matter of
adding work (such as a11y) and then we're at the end goal. If Epiphany
isn't, then the end goal means dropping Epiphany; so work on Epiphany
is wasted.

In including things in GNOME releases, we need to be guiding
innovation, focusing our energies on the work that needs doing.

Other than getting the big-picture direction right, I would say that
we should be guided by: which decision will be an improvement over
what users currently have?


So:
 - is epiphany is the right direction for the foreseeable future
   (next year or two) - I would say yes, native widgets + gecko
 - is epiphany a net gain for users - I would say yes, we have no 
   browser today

That is how I would evaluate adding modules.
 
> I think the real question here is are we prepared to add to the GNOME 2
> desktop a major application with very important functionality that is
> substantially inaccessible, and perhaps further without a commited roadmap
> to becoming substantially (if not necessarily 100%) accessible in a specific
> and fairly short term timescale?

My answer to that question is yes.

If we want committed roadmaps, then we have to pay somebody.

We are time-based because feature-based means you have to either a)
pay somebody or b) be prepared to delay indefinitely. As we don't have 
those options, we are time based.

You are advocating the "delay indefinitely" option for the browser -
because the nature of free software is that we cannot know that any
*specific* feature will happen at any given time, only that *some
features* will happen. Blocking the browser on a specific feature is
b), delay indefinitely.

Delay indefinitely mean users don't get the work that *did* happen.

> In no way am I suggesting that we shouldn't move technology forward as
> rapidly as we can.  But we cannot seriously commit to having an accessible
> desktop if we are prepared to add things - and especially things large and
> substantial - that are substantially inaccessible.

We can't commit upstream GNOME to being 100% accessible, because that
is a feature-based criterion, and we cannot pay people, and we cannot
delay indefinitely.

What we can do is be friendly to a11y - we can be sure that *if*
someone does the work, they can make the code shipped accessible.

This is exactly how we treat i18n and every other feature.

Havoc