July 32 is upon us...

[Seth Nickell <snickell stanford edu>]

The long and short is that I don't think we can make the July 32
deadlines without removing some current work.

Correct me if I have perceived incorrectly, but I believe we designed
the GNOME schedule at GUADEC to accomodate some slippage. We knew we
were being extremely aggressive, and we have done extremely well (esp.
considering that many of us had second thoughts post-GUADEC and started
to think we wouldn't even manage to be close to the schedule). APIs for
major modules seem to be most of the way there, but we aren't really
there yet in all areas.

I propose one of three things occur, or perhaps a combination thereof:

1) We push the freeze date back to Aug 15
2) We freeze as much of the modules as we can. Module maintainers will
be responsible for submitting a list of frozen header / idl files and
being *very aggressive* in putting things on the list.
3) We freeze the API to changes, but allow for additions

The important thing about this freeze date is it marks the point where
application developers can begin to work. The first option means there
will be two more weeks where the APIs are not frozen, pushing the whole
schedule back. The second option means that application developers can
start work, but will have the inconvenience of having to periodically
consult a list before they use particular calls. However, given the size
of the porting task I think this is reasonable. Option 3 should not
hinder porting at all, except insomuch as these missing APIs are
considered critical to application developement. If any missing APIs are
that critical, we are forced to push back the freeze date anyway.

As Maciej points out, we have APIs that we'd probably need to remove for
lack of adequate testing if we hold fast to the 32nd date (for example,
it means I will probably remove the metadata API from GnomeVFS, delaying
having useful metadata for yet another release). Two weeks does not seem
like a very long time, but it could give us the space we need to improve
the development side of the release a lot. I personally favour a
combination of option 1 and option 2.

As a writing professor of mine once said after looking at the sleep
deprived students and stack of last minute papers before him "Take these
papers back, and bring me the paper you wanted to write tomorrow". I
know this can be a slippery slope problem, but that does not inherently
mean we can't push the freeze around a little, we just have to excercise
discretion.

-Seth