Hi All,

We had a discussion at the Evergreen conference hackfest about our plans
for removing the XUL staff client from Evergreen, effective with the
release of version 3.2.  I wanted to recap some of that here and open the
door to any questions or concerns about the process.

The key point of discussion centered around ensuring the browser client is
up to the task of replacing the XUL client for all users when the XUL
client goes away.  (A number of cataloging bugs in particular stood out
during the discussion).

Of special interest will be input from sites that are already using the
browser client in production, but still have some staff using the XUL
client, or any sites that delayed migration.  We need details on why they
are unable to make the switch to the browser client.

To track these, I propose we once again make use of the Launchpad
"webstaffblocker" tag to indicate which bugs we consider blockers for
migrating away from the XUL client.  These bugs should of course also be
marked as High priority.

We have a few such bugs already:


If you are aware of any bugs that should be added to this list, please
add/update the bugs in Launchpad.  Of course, we can't plan when we'll find
bugs, but getting the ones we know about solidified sooner than later helps
ensure we can address them during the 3.2 development cycle.

When determining whether a bug should be a blocker, a good rule of thumb is
that the bug describes a feature or work flow that's regularly performed by
staff in the XUL client that either has no analog in the browser client or
requires an untenable number of extra steps in the browser client to

Please feel free to add anything I missed from the discussion or reply with
questions, etc.



Reply via email to