GNOME 2.0 meeting

[Havoc Pennington <hp redhat com>]

[I sent this earlier and it appears to have hit the bit bucket in
 transit along with several other messages to other lists - someone
 may want to investigate logs/errors in the mailman homedir.
 Anyway, apologies if it shows up twice.]

Hi,

The board had a meeting Tuesday to discuss GNOME 2.0. This was an
informal discussion to see where we agreed, where we disagreed,
etc. to post an initial summary of issues to gnome-hackers. You're now
reading that summary. Daniel's also posting some minutes with what
specific people had to say, and Miguel couldn't make the meeting so
posted his thoughts earlier at
http://primates.ximian.com/~miguel/gnome-2.0/.

Again, this is a discussion-starter. We (we = the GNOME Project)
should reach a final decision at some point, but there are some weeks
to talk about it, so we have time to consider it carefully.

Timeline
===

All 7 people at the meeting said they thought that GNOME releases
should come at regular intervals, on the order of 9-12 months between
them. For GNOME 2, we agreed the release should be in this calendar
year. Miguel seemed to indicate the same on his web page.

Some reasons that were mentioned:

 - we should get fixes and enhancements to users on a regular basis
 - we need clear momentum/tempo, with constant incentive to 
   contribute to the core environment
 - we should refine the release process over time, which means we
   need to make releases while we still remember how it worked last 
   time
 - we should have basically the same group of contributors working on
   the start and end of the release, so that we don't lose 
   track of what's going on due to turnover
 - long release cycles let things get destabilized over time, 
   it's better to go through a bugfix period on a regular basis

For the 9-12 month interval, we mean major releases only. There's also
a need for point releases such as 1.4.1 during the interval between
major releases.

Release Focus
===

We should have one. To make regular releases, each release has to have
a clear focus and clear goals that are a subset of all the stuff we
might like to see eventually in a perfect world. Features that aren't
in the release goals need to be rejected by default. If a really cool
already-implemented feature appears, we can dynamically adjust the
release goals after some discussion, but we don't want features just
showing up in CVS half-finished and then delaying the release when
they turn out to be buggy, untranslated, undocumented, or whatever.
There was unanimous agreement on this point.

What it should be: more diverse views here. The most popular one is
that the release should be about polishing the end-user environment. 
This would include release goals such as the following:

 - a GUI style guide
 - accessibility; complete keybinding support
 - finishing a help system; ensuring apps are fully documented, and 
   have tooltips for all apps
 - stripping out some of the more unsightly apps in packages such 
   as gnome-utils. we shouldn't be shipping things that look 
   half-finished or that aren't really useful.
 - nice default setup, in terms of themes, applets, keybindings, etc.
 - full translations
 - dialog de-uglification, some people need help with their 
   box-packing
 - integration between GNOME bits, such as Nautilus, panel,
   session manager, etc.

That kind of thing, not an exhaustive list.

Another point made is that the release and release coordination should
focus on core GNOME itself. This means the key libraries (which Miguel
summarized nicely in his document) and the key core desktop pieces
such as panel, Nautilus, Sawfish. As focused as possible.

Process
===

With each release, process should be improving. This means we should
try to have the best possible idea at the start what we are going to
do and who's going to do it, and constantly track the current state of
the roadmap, todo list, and development team as it changes. If the
schedule slips for unavoidable reasons, then OK, but we should know
what's going on.

There are several elements of process. 

 - release coordination team
 - timeline for freezes and milestones
 - roadmap for specific features and bugs that need work,
   probably done via Bugzilla
 - procedure for API freezes, CVS branches, tarball releases, QA,
   etc., etc.
 - procedure for API review. We'd like to consider a public RFC
   process for API added to our libraries. Owen brought this up for
   GTK+.

Bugzilla has made a dramatic difference for GTK+ development. We've
gone from having no real idea what work remained for the 2.0 release,
to knowing exactly what needs doing. We've also gone from extremely
poor responsiveness to bug reports and patches to reasonably good
responsiveness. We can also point potential contributors to Bugzilla
and they can query for exactly what tasks need doing for the 2.0
release.

The use of Bugzilla as an issue tracker and coordination tool works
great for Red Hat Linux, Nautilus, and Mozilla as well. So there's a
strong sentiment that this should be adopted by all the components of
GNOME 2.0 and used to manage the release.

GNOME Office
===

A couple people mentioned GNOME Office as a feature of the release. My
opinion is that this should be a separate issue from the GNOME desktop
release, though the GNOME Office team may want to coordinate with the
desktop release. I'm not sure how many people would agree or disagree.
We didn't discuss this in detail.

Maciej suggests handling this in the same way we're handling the
"extra apps" release for 1.4.

Specifics
===

I'm guessing many people will agree with the general "a release this
year would be nice" concept, but there will be massive flameage
regarding exactly which features we are going to punt to make that
possible. During these flames, please keep in mind that there will be
other releases, and hopefully those will be fairly soon after this
one. Also, keep in mind that a feature can exist without being in a
GNOME release; especially with Bonobo, add-on components are no big
deal. Trying to cram everything in GNOME proper is not a good idea.

Disclaimer aside, the general feeling I got was that we do not have
time to do work on the libraries.  We've just finished or are about to
finish major devel platform add-ons (Bonobo, gconf, gtk 2, libxml2)
and should go with only minor changes to those just-finished versions.

As mentioned in the section on focus, people felt instead that this
release should focus on end user experience and environment polish.
Basically we take the stable branch, port to GTK 2, freeze the libs,
and work on end-user features.

Note that this is a reversal from the plans for GNOME 2 a year ago,
when it was going to be about the devel platform. In mail to
board-list after the phone meeting, Maciej argued that we should not
reverse those plans.

Summarizing a followup I posted, I think we get to pick two of the
following:
 a) keep gnome-libs and devel platform unstable through much of this 
    year to hack on it
 b) keep user environment unstable through most of this year to 
    hack on that
 c) release in 2001 (vs. say summer 2002)

So I would like to see us articulate which one we are not doing for
this release. Note that we can still work on a) or b) over the next
year even if it's not in the release, it just won't have to be
finished for this release, and the finished version will go out in a
later release.

In making a decision, it may be helpful here to get more concrete.  I
(and no doubt others) have some specific comments on Miguel's "Blue
Sky" for gnome-libs, and other specifics of the release, but will save
those for a later post, let's get some discussion of the general ideas
first.

Another helpful step might be to go ahead and roughly sketch out the
post-GNOME 2 releases, giving us an idea when punted features can go
in. So if people want to do that, please feel free.

Havoc


  



_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers