Re: Migration Paths for New Modules

[Willie Walker <William Walker Sun COM>]

Hi Shaun:

> What's important to me is what happens to a Gnome 2.14 user
> who upgrades to 2.16.  Will we automatically migrate her to
> Orca from Gnopernicus?  How will her settings be migrated?

As of right now, we are not planning to migrate user preferences from
Gnopernicus to Orca.  We've not seen any demand for this from our users
(whom we interact with daily) and prefer not to add the complexity if we
don't need it.  These words may come across a bit stronger than I intend
them too, though, so please read on.  :-)

The setup for Orca is relatively simple (we provide both a self-voicing
text-based setup and a GUI-based setup), and the user is automatically
placed in setup mode the first time they run Orca.  Furthermore, Orca is
also designed to run in the absence of any settings.  As a result, the
following scenario should "just work":

1) The user's session is set up to automatically launch "the screen
reader", which happens to be gnopernicus.

2) The user's machine is updated, replacing gnopernicus with orca.

3) The next time the user logs in, "the screen reader" (which is now
orca) will be launched.  In this user environment, Orca will detect that
accessibility is enabled, automatically find a working speech synthesis
driver, connect to BrlTTY if it is running, and bring up the Orca
configuration GUI, which the user can navigate using Orca.

A big question for me is what does it mean to be 'the screen reader' and
how does it get launched (much like what it means to be 'the web
browser' or 'the e-mail reader')?  This is something outside of the
control of Gnopernicus and Orca, and I'm not sure how this works.
Guidance here would be greatly appreciated.

If there is a real world use case for why importing Gnopernicus settings
is a necessity, however, we can look at importing them.

> How will her settings inter-operate with Gnopernicus if she
> has multiple machines using the same home directory?  

The settings for the two are completely separate at the moment.  I'd
really hesitate trying to combine them.  It could get rather ugly and
might screw the user more easily than keeping them separate.

> What
> sorts of problems is she likely to encounter, and how can
> we address those problems in the documentation?

We've been keeping a list of FAQs and such at the Orca WIKI:

  http://live.gnome.org/Orca

>From my experience, many of the problems the user will encounter are
related to audio configuration.  Bad configuration of the audio (outside
our control, unfortunately) will usually result in Orca and/or
Gnopernicus being silent.  We try to offer some coping/debugging
strategies for how to determine where the failure occurs.

> For the record, from what I've seen, I love Orca.  I think
> it's the right move for Gnome, and I'm glad the Gnopernicus
> folks are in favor of it. 

Thanks!  The Gnopernicus folks are a great team.  They've also been
contributing to Orca over the past few weeks and I'm happy to have
people with their skills and experience on board.

> But we have to be very careful
> about how we manage migrations, because the sorts of people
> who use Gnopernicus and Orca will be completely screwed if
> something goes wrong with them.

Agreed.  Our focus for Orca has, and always will be, the users.  My
mantra for the project is "let the user requirements drive the
architecture, not the other way around."

Will