2.2 features: sanity check

[Havoc Pennington <hp redhat com>]

Hi,

I've seen lots of feature suggestions for 2.2 go by that have _no
chance_ of making it in. Realize the feature freeze is in 1.5 months!

As we've said many times in the past, things slated for 2.2 basically
have to be near-finished already, or really small gizmos (maybe
recently-used documents for example, or launch feedback) that we can
expect to get done in the next month.

Remember, the idea is that when the feature freeze date arrives, we go
with what we have and release; and any feature that did not make the
date catches the next release. If we're religious about this -
time-based releases - then there's always another release within 6
months that you can make with the feature.

What does this mean? It means we already need to be getting serious
and realistic about what can happen, and making tight reality-based
feature lists.

The highest priority decisions, in my mind, are whether to jump to
some of the new already-widely-used modules: metacity, vte.  Then
whether to add some of the things proposed by the release team. 

Honestly I think the fastest way to get these decisions made is for
someone to write up a really good, comprehensive discussion of 
the status of the modules in question, why we should add them, etc. -
whether you call this a GEP or not, it needs to happen, so that people
can inform themselves and we can build consensus.

Some example features I think might be feasible:

 - metacity
 - vte
 - fontconfig/Xft2
 - multihead support
 - unbreak the nautilus list view - apparently requires
   shoving some small GtkTreeView API into GTK? let's coordinate
   with owen and jrb
 - develop a plan for multimedia; I'm hoping it includes rhythmbox 
   and gstreamer in 2.2, but if they're not ready, they move to 2.4 - 
   that's life.
 - implement launch feedback (I'm on it)
 - lots of small little features (e.g. I added 'choose an encoding' to
   gnome-terminal, there are assorted tasklist requests, etc.)  

In other cases, the 2.2 target is probably to have a prototype, with
the final version in 2.4 or later - for example, the file selector,
even if someone starts hacking it in earnest right away, is only going
to happen in libegg and a few guinea pig apps - it won't be widely
deployed until 2.4. Similar for James's proposal for a new toolbar.

For purposes of 2.2, our goal should be to decide what _is_ ready, not
what we wish were ready. ;-) The 2.2 feature list should be created by
going out and looking at what people have either already done or are
actively working on for completion in the next few weeks. This task
should be pretty concrete and straightforward.

Havoc