Re: What are the community's goals for 2.0? [was Re: Getting serious about releasing]

[Owen Taylor <otaylor redhat com>]

Observations:

 * Just pushing the deadline out can often be a very bad way of getting
   a stable release out.

    - People lose interest
    - People start hacking on cool post release features instead of 
      working on the release
    - You get into a eternal cycle of "but we have to fix X" "but we have to fix Y"
      "but we have to fix Z".
    - Dependencies start shifting underneath you. ("Oh, but GTK+-2.2 will
      be out then, we should use that.")
   
 * There are stability guarantees that have to be made for:

    - API
    - File locations
    - String freezes

   That block people from doing the final stabiliziation for a vendor
   release until the upstream has said "this is it."

   I don't think it's reasonable for Ximian/Sun to say "we will guarantee
   that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
   much more reasonable to say "we will have a GNOME-2.0 based product
   we feel comfortable shipping by July."

 * If people are going to trust being able to build solutions on top of
   GNOME, we need *two* reputations:

    - Being able to deliver a quality product
    - Being able to deliver on schedule.

   It's easy to think of lots of examples of software products that failed
   because of getting a bad reputation in one or the other areas.

   We can't steal from one of these goals to satisfy the other. 
   So, we have to look elsewhere to figure out how to satisfy these two 
   goals; and this mostly means reducing the feature set, and waiting
   on fixing useability/etc. bugs so that we can deliver stability.

 * We are getting close on the crashing bugs. Many of the places where
   GNOME-2.0 needs improvement need significant new implementation;
   things like menu editing, mime types, and printing.
  
   If we start trying to fix all these issues, then:

    - We'll delay progress in all the areas that are feature complete for 2.0.
    - We'll destabilize the code
    - We'll rush in code that probably hasn't been fully tested

   We need to get out a stable base and take baby steps from there.
      
I'm certainly not arguing that we should release something at the
GNOME-1.0 level of stability. And I don't think there is any danger
that we will ...  GNOME-2.0 is already considerably more stable than
GNOME-1.0 was.

But we should have only three very simple goals:

 - Someone sitting down and playing with the desktop shouldn't be able
   to crash it or discover embarassing misbehavior. (*)
 - The desktop should be useable as a day-to-day desktop for the 
   average current GNOME user. (**)
 - We shouldn't be blocked from moving forward in the future.
 
Other goals such as:

 - No feature regressions from 1.4
 - No unhandled patches in the bug tracker
 - 101% key navigable.
 - etc.

May be important, but cannot be allowed to block 2.0, because they can
be fixed after or on top of GNOME-2.0, and the cost of losing momentum
with eternal release slippage is large.

Regards,
                                        Owen

(*) And we need to be ruthless in taking the simplest path to fixing
   such problems. "X crashes" ... "can we remove X?". "Menu item Y does nothing"
    "remove menu item Y".

(**) No, not for your grandmother.