Re: 2.3 Proposed Features

[Andrew Sobala <aes gnome org>]

On Tue, 2003-02-04 at 19:54, Christian Meyer wrote:
> Hi!
> 
> On Mon, 3 Feb 2003 20:56:50 -0500
> Havoc Pennington wrote:
> 
> > The concern is that holding a freeze for much longer than we have in
> > the past starts to slow forward progress because CVS is frozen for too
> > long.
> 
> OK, 6 - 8 months should be ok then.
>  
> > Some bugs can. Bugs that are "design bugs" or "big hard bugs" ("need
> > to rewrite the MIME system") really can't. Also UI bugs can't, you'll
> > break docs and i18n. These can only be fixed by moving the release
> > cycle forward quickly. That's why we want to release often.
> 
> Hmm, so when I'm trying to fix a UI issue (I don't want to paste the URL again
> ;-) )
> it results in breaking docs?
>  

No, that _one particular_ bug doesn't. Havoc was talking generally about
UI changes.

> > I've heard this argument once already for breaking the 2.2 feature
> > freeze, and 2.2 isn't even out yet. And I've gotten it many many times
> > in the past.
> 
> I see.
> 
> > 6 months is fine, 7.5 months is fine, 9 months is IMO too long.  Plus
> > the plan needs to leave margin for error; if you definitely want to
> > make 7, put 6 in the plan.
> 
> Ok, i can really live with that, now that you've explained it :-)
> 
> > Waiting for GTK 2.4 potentially delays us 12 months, so it's just
> > right out.
> 
> ..which is really bad.
> 

>From whose perspective, and why? Because of toolbars (again)?

A longer-than-GNOME GTK release cycle could bring us some more kick-ass
APIs for new GTK features. That could really benefit us in the long
term. Pros and cons, you know.

> > There's no benefit to a longer cycle as long as we insist on the
> > dogfood rule, as we must and should. If developers can always use CVS
> > HEAD as their daily desktop, then it's never more than a standard
> > freeze cycle away from release.
> > 
> > If a change involves breaking dogfoodability, that change simply does
> > not go in until it's fixed.
> 
> Fixing UI stuff shouldn't bread that rule ;)
> 
> > You realize that closing all bugs in bugzilla would take about 5
> > years. *If* we didn't add any features in the meantime. And I'm not
> > exaggerating when I say 5 years. I'm probably underestimating.
> 
> I wasn't talking about fixing all bugs, just about the annoying and
> nasty/visible ones.
> 

The annoying and nasty bugs _are_ being fixed. Mainly by people who find
them annoying or nasty and want to fix them. This sounds like the
typical line ... "Send a patch" ... and, although I hate that response,
it's true. You have to find someone who wants to fix a bug, and has the
time to do so, or fix it yourself, if you want a bugfix in an open
source project.

> > The goal is never bug-free. The goal is to be better than what people
> > are using now. i.e. the metric is whether you are improving people's
> > experience, and by how much, how quickly.
> > 
> > If you have something that is significantly better, not releasing it
> > is wrong. One criterion for significantly better is no showstopper
> > bugs, such as major crashes or regressions. But "zero bugs" certainly
> > isn't a criterion.
> 
> You're definitely right, but life should be easier for developers, too. Thus,
> the current toolbar "problem" should also be fixed.

IMHO, the right place to start would be to also talk to KDE (+other
tookkit) developers and come to a consensus about correct toolbar
spacing. Then right this into the HIG, which is going cross-toolkit in
the future. Then make patches for all the *nix toolkits. Only then will
you have this "problem" fixed.

-- 
Andrew Sobala <aes gnome org>