Release dates


So sitting down to think about this a lot more, I can't get over the
following: the #1 problem with GNOME from a user standpoint right now
is that users are having to use something that isn't actively hacked
on by developers. Just ask Kjartan.

Some auxiliary points:

1. Perhaps we've been bad about regular releases because we always
   creep instead of punting things. We need to learn to punt.  GTK 2
   only came out when we finally said "god dammit, we are just going
   to punt a whole lot of stuff." And it wsan't the end of the world.
   GTK 2 does its job and works pretty well.

2. I don't think a late release means July; even with the puntage I've
   proposed, we already have a chance of slippage until July. I think
   a late release means September or worse. Wipro/Ximian/Sun are
   helping, but they aren't magic; and most of the current
   showstoppers are core-maintainer kind of issues, where we still
   have a limited number of hackers that can fix them.

   Based on the must-fix list, recently-arrived developers are mostly
   slowing us down by adding patches to noncritical bugs that core
   maintainers have to spend time on.

   Anyway, to feel confident in July we _already_ need to be punting
   way more stuff than we are.

3. We made a conscious decision to fool around with libraries and
   whatnot instead of working on the user desktop. With 20/20
   hindsight I think this was the largest mistake we could possibly
   have made. But in any case, we decided, on purpose, that the 
   user part would not be the focus. It's not OK to now delay 
   because we didn't like that decision.

4. Claiming GNOME 2 isn't nice is sort of bullshit anyway.  IMO it
   actually turned out to be pretty exciting, as I've written up in my
   "what's new" article and recent usability rant. Because we feature-
   creeped the user environment all over the place.

   We can have release notes about the most noticeable issues and
   promise to fix them in 2.0.1. People will get over it.

5. My punt list does not involve shipping an especially buggy release
   compared to what else is out there. Anyone who thinks so hasn't
   been watching GNOME 1.x reports over the last years, and didn't try
   KDE 3. If we fix the bugs I marked "not puntable" (and comparable
   bugs that come in) then we will have a solid release.

6. It screws users more to never release. Users are best served if you
   release something imperfect but follow up with lots of subsequent
   releases, including bugfix releases. GNOME 2 is better in many ways
   than 1.4, and by the time it hits distributions it will be quite
   good.  But this is ASSUMING we ship it.

   Part of the reason is that you need real-world feedback and testing
   and just plain _interest_ in the code.

7. I just haven't seen any actual examples of an open source project
   that's had success with the "release when there are zero bugs" kind
   of policy. Empirically, projects are best off keeping users always
   nearly synced to the actively-developed sources, and being
   responsive to bug reports, rather than doing lots of branch/freeze
   action and interminable waiting around for the last few bugs to be
   fixed. We're 2 years out of sync with our users, and the single
   biggest win right now will be to get back in sync.

Anyway, I kind of thought about what Luis was saying for a while, and
almost was convinced. But then I realized that there really is nothing
special about our current situation; it really is the same as every
large software project just before release. But some do the necessary
emergency punting, suck it up, and get the code out there, and some
don't. And the ones that don't are wrong, plain and simple.

We do not want to be Mozilla. 1% market share is not any fun. And
the "just one more month" today is not any different than the "just
one more month" Mozilla has had for the past 3 years, or that we've
had for the last two.

The way software gets shipped is that you just ship it, you take your
knocks, then you ship another version. And the only way we're going to
start serving users well is to learn how to do this.

I'm not personally embarassed by my punt list. I'm prepared to say
it's the right thing to do for users. And that's mostly because I'm
prepared to say that going 2 years with no release is categorically
more wrong than any release of any quality possibly could be. But at
the same time I don't think our release will be low-quality, I think
it will be a solid milestone showing big advances, which is exactly
what we've always said it will be.

People will whine on Slashdot, but has anyone ever achieved anything
by worrying about that?

IMO we should punt the bugs, start ABI-freezing and .0-releasing the
libraries, start disabling broken features, lock down the feature
freeze hard, go for the string freeze as soon as possible, and 
get it out the door.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]