Re: July 32 is upon us...

[Havoc Pennington <hp redhat com>]

Hi,

Dropping foundation-list - that list is for discussion of the
foundation and/or foundation policies, there's no need to put release
engineering on there.

I guess I'd feel like we knew what to do if there were a list of open
API bugs. For example, I can look at the "2.0 API freeze" milestone
for GTK, and see that there are 25 open issues, and what they are.

This doesn't help hugely in date prediction since some of the bugs are
blocking on people with unpredictable delivery times, but at least we
know what we are punting if we punt, and so on.

See http://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&op_sys_details=&op_sys_details_type=substring&version_details=&version_details_type=substring&namedcmd=GLib%2FPango%2FGTK+open+API+freeze+bugs&cmdtype=runnamed&newqueryname=&order=%27Importance%27&form_name=query

Do we have anything like that kind of knowledge of what's going on
with the gnome library stack? Or are we just guessing?  Is anyone
really smart enough to have all outstanding issues for oaf, bonobo,
gconf, gnome-libs, gnome-vfs, etc. kept in their head?

I find it hard to have a strong opinion in either direction on
extending the release date, without specific information on what's
missing, planned, and so on. What does a delay give us? How broken are
things if we don't delay?

Perhaps we should just take the plunge and port apps, allowing APIs
used by one app for now to keep changing (e.g. only panel will be
using .desktop file parser, only Nautilus the metadata thing), and
require lib maintainers to fix panel and nautilus anytime they break
something; that should at least slow down library change, get some
testing, and start to move toward a GNOME 2 release.

Or maybe the right thing to do is postpone this decision 1 week,
freeze all CVS modules and hacking for that week, and get maintainers
to create relevant milestones and get their bugzilla in sync with
reality instead of madly writing code. Then we know what's going on
and can make a rational choice. ;-)

Yeah I know that won't happen, but if we actually care about getting
things right it might make sense...

Havoc