Re: 2.4 Proposed Modules - 2 weeks left

[Havoc Pennington <hp redhat com>]

On Tue, May 06, 2003 at 01:19:33PM -0700, Peter Korn wrote: 
> Are we as a community happy to accept a world where there can be lots of
> accepted (and welcomed) innovation but that said innovation will only be
> accessible if someone with deep pockets invests in making it so?  Or do we
> want to have a stronger statement about what all apps *should* do?  What is
> the minimum level of an "active accessibility plan" that we should expect
> from an app that becomes part of the GNOME desktop?

I'd say the question I just posed following up to Janina is the right
one.

That is, would we build on this code or replace it. If the right
direction in the 2-years-ish timeframe is going to be to use a
different browser that's more a11y-friendly, then we would not build
on epiphany. Then epiphany should not be included.

However if the right browser is epiphany, and we know we want to build
on it to get an accessible browser, then epiphany should go in.
Leaving it out just slows down our browser solution, accessibility and
all.

There's no hard and fast rule here about any of the specifics; it's
purely an *overall* evaluation of whether a codebase is a better
foundation than other alternative codebases, or starting from scratch.
No *single* dimension of evaluation can determine the answer.
 
> We already delay indefinitely for quality, right?  There can be lots
> of innovation in a buggy program that crashes all the time.  And we
> would not want that program to be part of the GNOME desktop until
> those problems were fixed, right?  Would we not also delay
> indefinitely for significant build ugliness?  If folks cannot
> generally 'make install' the thing, it's not ready to be part of the
> GNOME desktop, right?

There's a line between bugs and features, and yes you can claim any
missing feature is really a bug, and any bugfix is a feature.  However
I think when we say "feature freeze" we have a general idea what that
means, which is that you don't write a significant new chunk of code
from scratch.
 
Given that definition of a feature, we know that in practice we can
obtain adequate quality (fixage of bugs) in a fairly predictable
timeframe after feature freeze. Note that time-based is technically
time-based feature freeze, not time-based release.  The release is in
fact indefinite, but the indefiniteness is controlled by a) entering
feature freeze in dogfoodable state and b) the feature freeze itself.

Release criteria that involve writing new chunks of code break the
time-basedness of your *freeze*. The indefiniteness there is
open-ended.

> I am NOT advocating the "delay indefinitely" option (from the GNOME desktop)
> specifically for Epiphany.  I don't know enough about it, and specifically I
> don't know enough about how much work is needed to make it a good
> accessibility citizen.  Rather, I'm trying to understand and help hash out
> principles and general requirements (which would then be applied to Epiphany
> and any other candidate for the GNOME desktop, GNOME core, and fifth toe).

Let's separate here the criteria for inclusion and for evaluation. 

For inclusion, I'm saying we should have a significant net gain for
users, and we should plan to build on the codebase in question rather
than replacing it.

More specific criteria are in the domain of evaluation.  Evaluation
criteria do factor into whether you'd build on a codebase, because you
want to compare that codebase to the alternatives (including the null
alternative) using your dimensions of evaluation.

What I'd like to see to justify excluding epiphany is someone
advocating a concrete course of action in which we *would not* build
on epiphany, but instead build on something else. That's what affects
inclusion.

In other words, in the big picture, what is our action plan for
achieving a good web browser that does what we want. Advocate a course
of action.

> > This is exactly how we treat i18n and every other feature.
> 
> Generally, on average, how long would you say it takes a new app in the
> GNOME desktop to support I18N after it becomes part of the desktop (not
> localized into all languages mind you, but simply to have all strings and
> user interface elements localizable)?  

For plain gettext-marking, many apps are already done up front. For
more complicated stuff like getting date formats right and working
with bidi and so forth, we've often taken a really long time.  I don't
have any hard data here though.

Havoc