What are the community's goals for 2.0? [was Re: Getting serious about releasing]

[Luis Villa]

**This is long, if you are involved with the gnome2 work at all, please
read and respond to at /least/ the last paragraph.**

This is going to end up split into two emails. This one addresses a
general gnome question and so I've redirected it to gnome-hackers and
not desktop-devel. The other addresses release-specific issues and so
will remain targeted at desktop-devel.

Please note that this is basically a freelance email; I speak neither
for Ximian nor for Sun. I speak as somebody whose name will (hopefully)
be in the about box; that's it.

It's sort of a judgment call which bugs can be punted, but
I promise you have to punt on the scale of the appended punt-list or
we may as well go ahead and update the schedule to show a release in
September or later. Seriously.
So, if you think a bug I listed should really not be punted, either a)
fix it right away b) suggest a bug that I have as not puntable that
you'd punt instead or c) have the guts to go ahead and argue for a
September or later release. Please don't do c). ;-)

I'm going to do (c). Sorry. :)

We have two options right now:

(1) a 2.0.0 that has no major, individually embarassing bugs, but a
huge collection of bugs that make the overall level of quality
embarassing, but it Works For Us.

(2) waiting and having a 2.0.0 that is completely free of highly
embarassing bugs and has a very small number of bad bugs. It Works For
People Who Are Not Us.

I have yet to hear clearly say why (1) is a good idea. It is my belief
that the common belief is 'we have to release.' I still don't know why
'we have to release.' Reasons (that I consider not good) that I've
heard:

*'well, the kernel did it.' The 2.4.0 kernel was /vastly/ embarassing.
It made people question whether Linus was qualified to maintain the
kernel. I hope not to be associated with a similar fiasco.

*'we just need to have a release.' This is circular; we need to
release because we need to release.

*'we'll get more testing.' Trust me, we don't need more testing- we
already have more bugs than we can handle.

However, I have yet to hear anyone explain why (2) is a good idea
either. So, here are my reasons why I feel (2) (havoc's (c), but in
July) /is/ a good idea.

*There is a big fear that if we go for (2), we'll slip interminably;
Havoc's estimate is September. This is quite
simply not the case. This is unusual, but Sun's contract with
Ximian/Wipro guarantees that (2) is achieved (for all intents and
purposes) is no later than mid-July. So slipping until September will
not occur. Ximian, Wipro, and Sun will ensure that slippage is no later
than July. Yes, there will be puntage- we obviously can't fix
everything. But there will be a lot less puntage than Havoc has
proposed.

*If we go for (2), quite bluntly, we get a release we'll be proud to
put our names on. Option (1) (release Real Soon Now) I'd be embarassed
to show to my mother, because she's never used Linux and she'd find
bugs in 2-3 minutes. I shudder to think of the press and community
reaction we'd get. I was fucking proud of Evolution 1.0, and that was
because we waited until we got it right. I can't /wait/ to get my mom
using it eventually. That is not going to be the case with a 2.0
release that punts that many bugs.

So, I think we're faced with a very fundamental question: the GNOME
community can release something very soon that Works For Us, or we can
release something that Works if we're willing to wait.

/Personally/, speaking as an 'advanced' user, we're basically ready for
2.0. Speaking as a name in the about box, I /personally/ would be
completely embarassed to put my name on Havoc's proposed 2.0.0.

But I can't speak for the community. So, tell me- are you, the
community, happy with Works For Me? Would you prefer Works? Are there
reasons I'm not seeing why waiting is bad, or why not waiting is good? I
personally feel strongly, right now, that I want to wait for mid-July
and for Works. I do not want to settle for Works For Me. I want this to
be the best damn release we can have, and I'm willing to wait longer
until it is the release that Kicks a Lot of Ass. But I understand others
may not want to wait, and I'm willing to go ahead and put something out
there if others don't want to wait. I just don't understand why anyone
would want not to wait.

THIS IS THE LAST PARAGRAPH I PROMISED WOULD BE MOST USEFUL :)

So... what are the community's goals for 2.0.0? I won't feel offended if
people say 'get 2.0 out the door'; if that is what the community wants,
I'll work my ass off to work with Havoc and whoever else to triage
things to make a quick release that is as good as possible. If the
response is 'we want quality and are willing to wait until mid-July'
I'll work my ass off to make that happen as quickly as possible too. I
just want to know what the community wants so I and the rest of the
release planning folks can adjust our release and bugzilla strategy
appropriately. Right now I feel like we're making a lot of assumptions
about what the community wants, and I'm getting sick of making
assumptions- I want to know what the hackers want for 2.0, and I want to
act based on what people who have written code for 2.0 want.

Luis

[Steve Fox]

Post by Luis Villa
But I can't speak for the community. So, tell me- are you, the
community, happy with Works For Me? Would you prefer Works?

Speaking as a beta-tester (not a GNOME developer :), I would even be
embarassed if GNOME 2 went out in its current shape.

People will definitely judge GNOME based on the 2.0 release, no matter
how much "this is a developer's release" verbage accompanies the release
notes. User's simply don't care. 2.0 means the developers thought "we're
done".

The major distributions (Mandrake, SuSE, Red Hat) all just released new
versions (well, Red Hat's is coming very soon), so it's not like we need
to get something ready in time for them to ship it.

If anyone is "dying" to run GNOME 2 (and willing to tolerate bugs), they
can simply download Ximian's snapshots or use Mandrake's Cooker
packages.

[Matthias Warkus]

+++ Wed, Apr 24, 2002 at 12:40:11AM -0500 +++
Steve Fox e-mails me. Film at 11. Reply right now, after the break.

Post by Steve Fox

Post by Luis Villa
But I can't speak for the community. So, tell me- are you, the
community, happy with Works For Me? Would you prefer Works?

Speaking as a beta-tester (not a GNOME developer :), I would even be
embarassed if GNOME 2 went out in its current shape.
People will definitely judge GNOME based on the 2.0 release, no matter
how much "this is a developer's release" verbage accompanies the release
notes. User's simply don't care. 2.0 means the developers thought "we're
done".

A developers' release should me named GNOME 1.5 or GNOME 1.9 or such.
A developers' release with a trailing zero would be pretty stupid
marketing.

mawa

[Luis Villa]

Post by Matthias Warkus
+++ Wed, Apr 24, 2002 at 12:40:11AM -0500 +++
Steve Fox e-mails me. Film at 11. Reply right now, after the break.

Post by Steve Fox

Post by Luis Villa
But I can't speak for the community. So, tell me- are you, the
community, happy with Works For Me? Would you prefer Works?

Speaking as a beta-tester (not a GNOME developer :), I would even be
embarassed if GNOME 2 went out in its current shape.
People will definitely judge GNOME based on the 2.0 release, no matter
how much "this is a developer's release" verbage accompanies the release
notes. User's simply don't care. 2.0 means the developers thought "we're
done".

A developers' release should me named GNOME 1.5 or GNOME 1.9 or such.
A developers' release with a trailing zero would be pretty stupid
marketing.

Is there some way we can get away with a 1.9? If so, would that be
substantially different in some way from all the betas we've already
done? If so, how? These are honest questions; if we can do it well from
a release/PR perspective, it's not a bad solution, and certainly ties in
with what Owen is saying about library stability and API guarantees.

Luis

[Liam R. E. Quin]

Post by Luis Villa
So... what are the community's goals for 2.0.0?

Many people will upgrade from 1.2 or 1.4, and if their experience
is bad, they will maybe stop using Gnome for a while. Right now
I don't think that'd be good.

So Gnome 2 needs to be reasonably solid, fast, and not too
memory-intensive, when compared with 1.2 or 1.4.

An extra couple of months might mean gnome 2 doesn't get into
the next debian release, if their shedule is to be believed,
but when it does, make the wait worth-while! People don't
use features, they use software that may or may not have
features -- the experience has to be a positive one.

So, wait until the end of July.

Or that's my take at least.

Liam

[l***@peabody.ximian.com]

Post by Luis Villa
However, I have yet to hear anyone explain why (2) is a good idea
either. So, here are my reasons why I feel (2) (havoc's (c), but in
July) /is/ a good idea.
*There is a big fear that if we go for (2), we'll slip interminably;
Havoc's estimate is September. This is quite
simply not the case. This is unusual, but Sun's contract with
Ximian/Wipro guarantees that (2) is achieved (for all intents and
purposes) is no later than mid-July. So slipping until September will
not occur. Ximian, Wipro, and Sun will ensure that slippage is no later
than July. Yes, there will be puntage- we obviously can't fix
everything. But there will be a lot less puntage than Havoc has
proposed.
*If we go for (2), quite bluntly, we get a release we'll be proud to
put our names on. Option (1) (release Real Soon Now) I'd be embarassed
to show to my mother, because she's never used Linux and she'd find
bugs in 2-3 minutes. I shudder to think of the press and community
reaction we'd get. I was fucking proud of Evolution 1.0, and that was
because we waited until we got it right. I can't /wait/ to get my mom
using it eventually. That is not going to be the case with a 2.0
release that punts that many bugs.

1) Eck. Apologies for the horrible formatting. Should have trusted evo
to do it instead of doing it myself ;)

2) I forgot one item in this list: I know there is a sense of burnout
among some people in the community, but what I'm seeing in the numbers
and on the lists is increased interest in 2.0 and increased rates of
bug-fixing. Hell, even nautilus is getting random people spontaneously
picking bugs and fixing them :) If we really are building momentum, it
seems like we should be capitalizing on that and standing firm on our
quality goals, not giving in and cutting things just as (from where I
stand) things are getting good from an involvement perspective. I for
one find it exciting to be involved in something moving rapidly
towards kicking much ass and I think other people are beginning to
feel that way too. Compromising on quality seems to me like a very
quick way to damage that excitement and momentum.

Luis (again, speaking for myself as a contributor and user, not for
Ximian, Sun, or the release team)

[Bastien Nocera]

On Wed, 2002-04-24 at 08:03, ***@peabody.ximian.com wrote:
<snip>

Post by l***@peabody.ximian.com
2) I forgot one item in this list: I know there is a sense of burnout
among some people in the community, but what I'm seeing in the numbers
and on the lists is increased interest in 2.0 and increased rates of
bug-fixing. Hell, even nautilus is getting random people spontaneously

Fixing bugs is quite fun... Porting apps is a PITA when you've already
done it quite a number of times. Especially when nobody is helping out.

The games contain all the same things to port and it's pretty damn
boring. The other persons hacking on gnome-games ported GNect, jrb takes
care of aisleriot, but nobody else is doing porting.

Post by l***@peabody.ximian.com
picking bugs and fixing them :) If we really are building momentum, it
seems like we should be capitalizing on that and standing firm on our
quality goals, not giving in and cutting things just as (from where I
stand) things are getting good from an involvement perspective. I for

Well, I, for one, am losing momentum. Lack of feedback, general porting
boredom, and it's not like Gnome is putting any bread on my table.

Post by l***@peabody.ximian.com
one find it exciting to be involved in something moving rapidly
towards kicking much ass and I think other people are beginning to
feel that way too. Compromising on quality seems to me like a very
quick way to damage that excitement and momentum.

Cheers

[Luis Villa]

Post by Bastien Nocera

Post by l***@peabody.ximian.com
picking bugs and fixing them :) If we really are building momentum, it
seems like we should be capitalizing on that and standing firm on our
quality goals, not giving in and cutting things just as (from where I
stand) things are getting good from an involvement perspective. I for

Well, I, for one, am losing momentum. Lack of feedback, general porting
boredom, and it's not like Gnome is putting any bread on my table.

Fair enough. Am I misreading people? Is this common in the non-vendor
community? Kevin, Paolo, others? If so, that's a fairly good argument
for getting the thing out the door...

Luis

[Chris Lyttle]

Post by Luis Villa

Post by Bastien Nocera

Post by l***@peabody.ximian.com
picking bugs and fixing them :) If we really are building momentum, it
seems like we should be capitalizing on that and standing firm on our
quality goals, not giving in and cutting things just as (from where I
stand) things are getting good from an involvement perspective. I for

Well, I, for one, am losing momentum. Lack of feedback, general porting
boredom, and it's not like Gnome is putting any bread on my table.

Fair enough. Am I misreading people? Is this common in the non-vendor
community? Kevin, Paolo, others? If so, that's a fairly good argument
for getting the thing out the door...

I dont blame the developers for loosing momentum. It seems to me as a
user that every time someone stands up and says 'OK lets get organised
about releaseing, what can we punt?' Someone else says 'noooo we aren't
ready lets delay till blah' I for one am getting annoyed at my KDE using
friends pointing out how KDE has gone through 2 major releases and
GNOME2 still isn't out. That in my mind will kill not only developer
interest/momentum but also user interest.
Come on lets punt the bugs that dont need to be fixed and get it out the
door.

Chris

[ERDI Gergo]

I for one am getting annoyed at my KDE using friends pointing out how
KDE has gone through 2 major releases and GNOME2 still isn't out.

Although I don't use KDE, from what I've seen of it, they are
substantially more advanced (as far as what the user sees) than gnome
2[*]. So it's not just a matter of releases -- we could have made 2
releases in the same time frame, and the software itself would still suck
the same.


[*] Since I don't use GNOME 2 either, I think it's fair of me to compare
it to KDE ,)

[ERDI Gergo]

Post by ERDI Gergo
Although I don't use KDE, from what I've seen of it, they are
substantially more advanced (as far as what the user sees) than gnome
2.

And let's not forget about this point after 2.0. We may have a versatile
system with nice API's and a usable component model, if the end-user
doesn't see anything from it, we have, in some sense, lost (not against
anyone but against our goals).

[John Fleck]

Post by Luis Villa

Post by Bastien Nocera

Post by l***@peabody.ximian.com
picking bugs and fixing them :) If we really are building momentum, it
seems like we should be capitalizing on that and standing firm on our
quality goals, not giving in and cutting things just as (from where I
stand) things are getting good from an involvement perspective. I for

Well, I, for one, am losing momentum. Lack of feedback, general porting
boredom, and it's not like Gnome is putting any bread on my table.

Fair enough. Am I misreading people? Is this common in the non-vendor
community? Kevin, Paolo, others? If so, that's a fairly good argument
for getting the thing out the door...

I, too, am losing momentum, for reasons similar to Bastien. But my experience
argues for the opposite conclusion from the one Louie has drawn.

One reason for my frustration and loss of momentum has been a realization that
sometime soon we're going to put a "done" stamp and this thing and ship it,
even if it has not yet achieved the quality I would like.

A more formal recognition that we have a standard of quality, and that we are
willing to wait in order to meet it, would help my enthusiasm, not hurt it.

Cheers,

John

[iain]

Post by Luis Villa
Fair enough. Am I misreading people? Is this common in the non-vendor
community? Kevin, Paolo, others? If so, that's a fairly good argument
for getting the thing out the door...

Well, I'm not really burnt out (not in anyway like I was last
summer...). If I get burnt out, I give it a rest for a few days, and
then I'm okay to go for a while agin.

iain

[Bastien Nocera]

Post by iain

Post by Luis Villa
Fair enough. Am I misreading people? Is this common in the non-vendor
community? Kevin, Paolo, others? If so, that's a fairly good argument
for getting the thing out the door...

Well, I'm not really burnt out (not in anyway like I was last
summer...). If I get burnt out, I give it a rest for a few days, and
then I'm okay to go for a while agin.

That's what I'm doing as well... I took a break by making a GTK2 theme,
and a nautilus theme.

And I still process patches. I like patches :)

Cheers

[Glynn Foster]

Okay, every minute we spend reading this thread is about [on average] 1
less bug fixed. I agree that this is really useful stuff to talk about
and I really want to see a GNOME 2.0 within the next 1.5 months [1]. I
see that Jeff hasn't replied to this thread yet..so in the style of Jeff
perkypants Waugh -

GNOME 2.0 ROCKS!

Lets get back to bug fixing like rabbits [2]

Glynn ;)


[1] This is my prediction and I've wagered 20 euro on it
[2] Okay, so not quite the phrase that is usual..but it will do.

[Dick Porter]

Post by Luis Villa

So, if you think a bug I listed should really not be punted, either a)
fix it right away b) suggest a bug that I have as not puntable that
you'd punt instead or c) have the guts to go ahead and argue for a
September or later release. Please don't do c). ;-)

I'm going to do (c). Sorry. :)

I agree with Louie: we should release when the code is ready, unless of
course there are _really_ pressing reasons for shipping bugs.


Would it satisfy the "release it now" lobby if we start naming the beta
releases "Release Candidate", and API-freeze all included libraries? We
can then:

a) get some press attention now (and again later when we decide to call
it "ready" :) );
b) avoid the negative aspects of releasing with hundreds of known bugs,
some serious, some easily fixed. _I_ know it's going to be called a
developer release, but I doubt anyone installing it will think it is
anything less than an upgrade to 1.4; and
c) start encouraging third parties to port/develop GNOME 2 applications
while we're doing the final polishing.


Please lets not repeat the 1.0 release.

- Dick

[Sander Vesik]

Post by Dick Porter

Post by Luis Villa

So, if you think a bug I listed should really not be punted, either a)
fix it right away b) suggest a bug that I have as not puntable that
you'd punt instead or c) have the guts to go ahead and argue for a
September or later release. Please don't do c). ;-)

I'm going to do (c). Sorry. :)

I agree with Louie: we should release when the code is ready, unless of
course there are _really_ pressing reasons for shipping bugs.

Do we have a real reason to think the "code is ready" point will arrive?

Post by Dick Porter
Would it satisfy the "release it now" lobby if we start naming the beta
releases "Release Candidate", and API-freeze all included libraries? We
a) get some press attention now (and again later when we decide to call
it "ready" :) );
b) avoid the negative aspects of releasing with hundreds of known bugs,
some serious, some easily fixed. _I_ know it's going to be called a
developer release, but I doubt anyone installing it will think it is
anything less than an upgrade to 1.4; and

Hndreds is a bit incorrect - there is ~ 1200, but only a small percenatge
of them will pass a "we care about them for gnome 2.0" test.

Post by Dick Porter
c) start encouraging third parties to port/develop GNOME 2 applications
while we're doing the final polishing.

Either it is ready for consumption by people who at the same time aren't
hacking on gnome itself (in which case we can release it) or it is not
ready for consumption of people whop are not hacking on gnome, in which
case we cannot tell them that it is good time to port.

Post by Dick Porter
Please lets not repeat the 1.0 release.
- Dick

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[Havoc Pennington]

Post by Dick Porter
b) avoid the negative aspects of releasing with hundreds of known bugs,
some serious, some easily fixed. _I_ know it's going to be called a
developer release, but I doubt anyone installing it will think it is
anything less than an upgrade to 1.4; and

While I'm willing to be convinced of Luis's point, it needs pointing
out here that we ARE going to ship with hundreds of bugs; unless we
want to impose NASA-like code review and be here until 2015 and never
have any users.

Let's maybe qualify that as "showstopper bugs" vs plain "bugs" ;-)

Havoc

[Christian Fredrik Kalager Schaller]

Post by Havoc Pennington

Post by Dick Porter
b) avoid the negative aspects of releasing with hundreds of known bugs,
some serious, some easily fixed. _I_ know it's going to be called a
developer release, but I doubt anyone installing it will think it is
anything less than an upgrade to 1.4; and

While I'm willing to be convinced of Luis's point, it needs pointing
out here that we ARE going to ship with hundreds of bugs; unless we
want to impose NASA-like code review and be here until 2015 and never
have any users.

No users? Cool, I always wanted to run a hax0r only system :)

Christian

[Sri Ramkrishna]

Post by Dick Porter
Would it satisfy the "release it now" lobby if we start naming the beta
releases "Release Candidate", and API-freeze all included libraries? We
a) get some press attention now (and again later when we decide to call
it "ready" :) );
b) avoid the negative aspects of releasing with hundreds of known bugs,
some serious, some easily fixed. _I_ know it's going to be called a
developer release, but I doubt anyone installing it will think it is
anything less than an upgrade to 1.4; and
c) start encouraging third parties to port/develop GNOME 2 applications
while we're doing the final polishing.
Please lets not repeat the 1.0 release.

Yes, we'll never get over the stigma. As a beta tester myself GNOME2.0
currently while very fast and impressive visually is not a fully
functionally desktop.

I would say that we can judge the state of gnome2 by looking at the
number of unique bug reports that are filed per week. If there is a
excessively high number then we're in bad shape. (I'm not coding so I
don't know what would count as excessive, individual maintainers would
have to decide that) We need to reflect and decide what works
as a minimal functioning GNOME2.0 system. For instance, I would
throw out the menu editing stuff since it's currently broken as not
necessary as part of the user experience.

Once we have a core set of features that people want, release it as
a developer's only release 1.9999. Use long release numbers it sticks
in people's heads better than "Developer Release". I know it bugs
the hell out of me when I see it.

If we have a relatively small number of bugs coming then we're seeing
the same stuff and I would put move people around to tackle the bugs.

As for burn out, I think developers need to see a release soon in order to
at least get some sort of feedback. Long hours of toiling and then not
seeing anything gets tiring. So lets at least make some sort of 1.9999
release with some of the features disabled and then continue forward.

However, don't make a 2.0 until either you are completely stable and you
have at least feature comparisant with 1.4. People don't want to upgrade
and then not have all the same features they expect in 1.4. I know I
would be annoyed as a end user especially if I depend on them.

sri

[Sander Vesik]

Post by Sri Ramkrishna
Yes, we'll never get over the stigma. As a beta tester myself GNOME2.0
currently while very fast and impressive visually is not a fully
functionally desktop.
I would say that we can judge the state of gnome2 by looking at the
number of unique bug reports that are filed per week. If there is a
excessively high number then we're in bad shape. (I'm not coding so I
don't know what would count as excessive, individual maintainers would
have to decide that) We need to reflect and decide what works
as a minimal functioning GNOME2.0 system. For instance, I would
throw out the menu editing stuff since it's currently broken as not
necessary as part of the user experience.
Once we have a core set of features that people want, release it as
a developer's only release 1.9999. Use long release numbers it sticks
in people's heads better than "Developer Release". I know it bugs
the hell out of me when I see it.

If you personally were a user, would you give people who release something
as 1.9999 instead of 2.0 any less flack than otherwise? If so, then why?

If people *DID* have all those high expectations, why did we not hear the
screeming every time we released a beta (and some of them were
undescribably more broken compared to the present ones). Alternatively,
are are still buggy beyond comprehension but don't know yet because we
didn't release. We don't need to release to find bugs - we need to release
bugs that matter (and not just oddities thatare at the same time a
'blocker' and 'low priority').

Post by Sri Ramkrishna
If we have a relatively small number of bugs coming then we're seeing
the same stuff and I would put move people around to tackle the bugs.
As for burn out, I think developers need to see a release soon in order to
at least get some sort of feedback. Long hours of toiling and then not
seeing anything gets tiring. So lets at least make some sort of 1.9999
release with some of the features disabled and then continue forward.
However, don't make a 2.0 until either you are completely stable and you
have at least feature comparisant with 1.4. People don't want to upgrade
and then not have all the same features they expect in 1.4. I know I
would be annoyed as a end user especially if I depend on them.

complete stability and feature parity with 1.4 will not arrive for *MANY*
more moths and teher is nothing much you can do about that. It definately
won't be there in July.

Post by Sri Ramkrishna
sri

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[ERDI Gergo]

Post by Sander Vesik
If people *DID* have all those high expectations, why did we not hear the
screeming every time we released a beta

Maybe the people with high expectations don't want to install betas
because they expect them to be of substantially lower standard than the
finished product?

[Sander Vesik]

Post by ERDI Gergo

Post by Sander Vesik
If people *DID* have all those high expectations, why did we not hear the
screeming every time we released a beta

Maybe the people with high expectations don't want to install betas
because they expect them to be of substantially lower standard than the
finished product?

Well, I do hope they don't put of going to the grocery store on the hopes
that Heavenly Manna will rain down, as they will almost definately starve.
It is not reasonable to expect miracles to happen between teh beta and the
release.

Post by ERDI Gergo
--
.--= ULLA! =---------------------. `We are not here to give users what
\ http://cactus.rulez.org \ they want' -- RMS, at GUADEC 2001

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[ERDI Gergo]

Post by Sander Vesik
Well, I do hope they don't put of going to the grocery store on the hopes
that Heavenly Manna will rain down, as they will almost definately starve.
It is not reasonable to expect miracles to happen between teh beta and the
release.

All I'm saying is that we shouldn't dismiss the portion of our (future)
users who want to Just Use It and don't want to tinker with anything. For
example, I know I'm in this category when it comes to Linux kernels: I
have a very strict don't-fix-it-if-it's-not-broken policy, since I
couldn't care less about my underlying kernel (and thus I'm still using
Linux 2.2.19+ext3). I'm sure there are others who feel the same way about
their desktop.

[Jim Gettys]

Actually, the right criterion is:

"When the number of *NEW* bugs filed per week is significantly dropping,
you are ready to ship". (and you don't have show-stoppers left).

Doug Clark wrote several very nice papers on project management,
one of which was titled "Bugs are good".

As your user community grows, you get more and more duplicates
and therefore your total number of reports grows, even after fewer
new bugs are being found.

So understanding whether we're seeing fewer new bugs should go
into this equasion...

- Jim


So I ask the question: what does the rate of *new* bugs look like.

Post by Sri Ramkrishna
I would say that we can judge the state of gnome2 by looking at the
number of unique bug reports that are filed per week. If there is a
excessively high number then we're in bad shape. (I'm not coding so I
don't know what would count as excessive, individual maintainers would
have to decide that) We need to reflect and decide what works
as a minimal functioning GNOME2.0 system. For instance, I would
throw out the menu editing stuff since it's currently broken as not
necessary as part of the user experience.

--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
***@Compaq.com

[ERDI Gergo]

[If the main idea behind this has already been discussed, pay no attention
-- I didn't really track GNOME2 lately]

So what happened to the original idea of having a Core Library release? We
have all the paralell-installability(?) stuff worked out for the GNOME 2
libraries (right?) so we could just release the core libs, right? Core
libs as in (off the top of my head) Bonobo, GConf, libgnome* and GnomeVFS.

Of course, this is assuming most of the bugs are application-related,
which seems to be the case: looking at Havoc's list, most of them are
Nautilus/Panel/CApplets. So, just like we've already had our lowest layer
released (glib-atk-pango-gtk+), we could just climb one level higher and
do this again.

This way, our users experience no regression (since their end-user apps
remain the same) and third-party developers can begin their serious work.
So, everybody wins. Then we can release 'the Desktop' when the end-user
apps are ready.

This shouldn't take more time than doing the library+desktop thing
together since this is essentially just a prioritization(?) of the core
lib issues, so the sum of effort needed should stay the same.

So this is the part where I invite everyone to point out why I'm on crack
here.

[Luis Villa]

Post by ERDI Gergo
[If the main idea behind this has already been discussed, pay no attention
-- I didn't really track GNOME2 lately]
So what happened to the original idea of having a Core Library release? We
have all the paralell-installability(?) stuff worked out for the GNOME 2
libraries (right?) so we could just release the core libs, right? Core
libs as in (off the top of my head) Bonobo, GConf, libgnome* and GnomeVFS.

The original idea (as I understand it) was to call it a developer
release, but that included all kinds of non-developer stuff. It is my
humble opinion that as long we include nautilus, panel, control-center,
and sawfish, we can print DEVELOPER RELEASE on the foreheads of every
user and they are still going to think of it as a desktop release.

So... maybe the solution is to freeze/release the libraries very
shortly, make those a 'real' 2.0 developer release (i.e.,
libraries/daemons /only/), and say 'we'll release the desktop apps based
on those libraries/APIs/versions when they're ready'?

Luis

[Owen Taylor]

Observations:

* Just pushing the deadline out can often be a very bad way of getting
a stable release out.

- People lose interest
- People start hacking on cool post release features instead of
working on the release
- You get into a eternal cycle of "but we have to fix X" "but we have to fix Y"
"but we have to fix Z".
- Dependencies start shifting underneath you. ("Oh, but GTK+-2.2 will
be out then, we should use that.")

* There are stability guarantees that have to be made for:

- API
- File locations
- String freezes

That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."

I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

* If people are going to trust being able to build solutions on top of
GNOME, we need *two* reputations:

- Being able to deliver a quality product
- Being able to deliver on schedule.

It's easy to think of lots of examples of software products that failed
because of getting a bad reputation in one or the other areas.

We can't steal from one of these goals to satisfy the other.
So, we have to look elsewhere to figure out how to satisfy these two
goals; and this mostly means reducing the feature set, and waiting
on fixing useability/etc. bugs so that we can deliver stability.

* We are getting close on the crashing bugs. Many of the places where
GNOME-2.0 needs improvement need significant new implementation;
things like menu editing, mime types, and printing.

If we start trying to fix all these issues, then:

- We'll delay progress in all the areas that are feature complete for 2.0.
- We'll destabilize the code
- We'll rush in code that probably hasn't been fully tested

We need to get out a stable base and take baby steps from there.

I'm certainly not arguing that we should release something at the
GNOME-1.0 level of stability. And I don't think there is any danger
that we will ... GNOME-2.0 is already considerably more stable than
GNOME-1.0 was.

But we should have only three very simple goals:

- Someone sitting down and playing with the desktop shouldn't be able
to crash it or discover embarassing misbehavior. (*)
- The desktop should be useable as a day-to-day desktop for the
average current GNOME user. (**)
- We shouldn't be blocked from moving forward in the future.

Other goals such as:

- No feature regressions from 1.4
- No unhandled patches in the bug tracker
- 101% key navigable.
- etc.

May be important, but cannot be allowed to block 2.0, because they can
be fixed after or on top of GNOME-2.0, and the cost of losing momentum
with eternal release slippage is large.

Regards,
Owen

(*) And we need to be ruthless in taking the simplest path to fixing
such problems. "X crashes" ... "can we remove X?". "Menu item Y does nothing"
"remove menu item Y".

(**) No, not for your grandmother.

[Luis Villa]

Post by Owen Taylor
* Just pushing the deadline out can often be a very bad way of getting
a stable release out.
- People lose interest

Definite, legitimate fear. Hadess seems to indicate that this is
happening to him. Is this happening to other non-vendor people too? I
guess I'd hoped to get this type of feedback from /developers/- Dick,
Steve, your feedback is appreciated but you're not putting in the hard
hours right now :/ Paolo? KevinV?

Post by Owen Taylor
- People start hacking on cool post release features instead of
working on the release

I haven't seen this happen yet, but obviously if your last point is a
reality (and I have no sense if it is or not- which is why I'm asking
non-vendor people for feedback) then this will follow shortly.

Post by Owen Taylor
- You get into a eternal cycle of "but we have to fix X" "but we have to fix Y"
"but we have to fix Z".

Like I said there is a fairly hard date behind this, I /think/, but I
can't/don't speak for vendors here.

Post by Owen Taylor
- Dependencies start shifting underneath you. ("Oh, but GTK+-2.2 will
be out then, we should use that.")

Again, good reason.

Post by Owen Taylor
- API
- File locations
- String freezes
That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."

Should we do all of these hard in the near future, then, well before
2.0? We will be platform ready for 2.0 well before we are quality ready.
As it stands, the libraries are in fairly good shape and maybe ready for
.0, and the apps (sawfish, nautilus, and control-center in particular)
are just embarassingly not .0 quality yet, not by any reasonable
standards.

Post by Owen Taylor
I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

Like I said, I'm not and can't speak for Ximian/Sun. I'm just putting
out a date that is tied to their release and by which we can guarantee
some code quality.

Post by Owen Taylor
* If people are going to trust being able to build solutions on top of
- Being able to deliver a quality product
- Being able to deliver on schedule.
It's easy to think of lots of examples of software products that failed
because of getting a bad reputation in one or the other areas.
We can't steal from one of these goals to satisfy the other.
So, we have to look elsewhere to figure out how to satisfy these two
goals; and this mostly means reducing the feature set, and waiting
on fixing useability/etc. bugs so that we can deliver stability.

<personal hat on again for emphasis>
The list as hacked out by Havoc is not going to have stability. It's
going to have so many little, embarassing bugs that it's overall going
to be very embarassing. Period. There may be no big, nasty things you
can point at, but it's going to feel shaky, unpolished, and
unprofessional. We just /can't/ achieve both of your listed goals, Owen,
no matter how much punting and trimming we do. Sorry but that is how it
breaks right now, I think.
</>

Post by Owen Taylor
I'm certainly not arguing that we should release something at the
GNOME-1.0 level of stability. And I don't think there is any danger
that we will ... GNOME-2.0 is already considerably more stable than
GNOME-1.0 was.

It's more crash-free, yes. I (again personally) think we're past the
point where 'it doesn't crash' should be good enough.

Post by Owen Taylor
- Someone sitting down and playing with the desktop shouldn't be able
to crash it or discover embarassing misbehavior. (*)

The second part will take anyone about 2-3 minutes of playing with
nautilus or control-center at the moment. First part is substantially
harder, thankfully.

Post by Owen Taylor
- The desktop should be useable as a day-to-day desktop for the
average current GNOME user. (**)
- We shouldn't be blocked from moving forward in the future.

This sounds a lot like 'works for me' which is fine, if that is what the
community wants. I'm trying to get that sense from people who haven't
been intimately involved for ages.

Post by Owen Taylor
- No feature regressions from 1.4
- No unhandled patches in the bug tracker
- 101% key navigable.
- etc.
May be important, but cannot be allowed to block 2.0, because they can
be fixed after or on top of GNOME-2.0, and the cost of losing momentum
with eternal release slippage is large.

Don't disagree there.

Post by Owen Taylor
(*) And we need to be ruthless in taking the simplest path to fixing
such problems. "X crashes" ... "can we remove X?". "Menu item Y does nothing"
"remove menu item Y".

That's fine, to a certain extent. At the point we're at now that's going
to leave us with... well, I'll call it a feature-free desktop. We'll
have to remove most of control-center and large chunks of nautilus. Oh,
and we won't have a window manager. I think these are fairly large
regressions :)

</personal hat>
Luis

[Luis Villa]

<sent this once but for some reason appears not to have hit the list.
Sorry if this ends up being a double post.>

Post by Owen Taylor
* Just pushing the deadline out can often be a very bad way of getting
a stable release out.
- People lose interest

Definite, legitimate fear. Hadess seems to indicate that this is
happening to him. Is this happening to other non-vendor people too? I
guess I'd hoped to get this type of feedback from /developers/- Dick,
Steve, your feedback is appreciated but you're not putting in the hard
hours right now :/ Paolo? KevinV?

Post by Owen Taylor
- People start hacking on cool post release features instead of
working on the release

I haven't seen this happen yet, but obviously if your last point is a
reality (and I have no sense if it is or not- which is why I'm asking
non-vendor people for feedback) then this will follow shortly.

Post by Owen Taylor
- You get into a eternal cycle of "but we have to fix X" "but we have to fix Y"
"but we have to fix Z".

Like I said there is a fairly hard date behind this, I /think/, but I
can't/don't speak for vendors here.

Post by Owen Taylor
- Dependencies start shifting underneath you. ("Oh, but GTK+-2.2 will
be out then, we should use that.")

Again, good reason.

Post by Owen Taylor
- API
- File locations
- String freezes
That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."

Should we do all of these hard in the near future, then, well before
2.0? We will be platform ready for 2.0 well before we are quality ready.
As it stands, the libraries are in fairly good shape and maybe ready for
.0, and the apps (sawfish, nautilus, and control-center in particular)
are just embarassingly not .0 quality yet, not by any reasonable
standards.

Post by Owen Taylor
I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

Like I said, I'm not and can't speak for Ximian/Sun. I'm just putting
out a date that is tied to their release and by which we can guarantee
some code quality.

Post by Owen Taylor
* If people are going to trust being able to build solutions on top of
- Being able to deliver a quality product
- Being able to deliver on schedule.
It's easy to think of lots of examples of software products that failed
because of getting a bad reputation in one or the other areas.
We can't steal from one of these goals to satisfy the other.
So, we have to look elsewhere to figure out how to satisfy these two
goals; and this mostly means reducing the feature set, and waiting
on fixing useability/etc. bugs so that we can deliver stability.

<personal hat on again for emphasis>
The list as hacked out by Havoc is not going to have stability. It's
going to have so many little, embarassing bugs that it's overall going
to be very embarassing. Period. There may be no big, nasty things you
can point at, but it's going to feel shaky, unpolished, and
unprofessional. We just /can't/ achieve both of your listed goals, Owen,
no matter how much punting and trimming we do. Sorry but that is how it
breaks right now, I think.
</>

Post by Owen Taylor
I'm certainly not arguing that we should release something at the
GNOME-1.0 level of stability. And I don't think there is any danger
that we will ... GNOME-2.0 is already considerably more stable than
GNOME-1.0 was.

It's more crash-free, yes. I (again personally) think we're past the
point where 'it doesn't crash' should be good enough.

Post by Owen Taylor
- Someone sitting down and playing with the desktop shouldn't be able
to crash it or discover embarassing misbehavior. (*)

The second part will take anyone about 2-3 minutes of playing with
nautilus or control-center at the moment. First part is substantially
harder, thankfully.

Post by Owen Taylor
- The desktop should be useable as a day-to-day desktop for the
average current GNOME user. (**)
- We shouldn't be blocked from moving forward in the future.

This sounds a lot like 'works for me' which is fine, if that is what the
community wants. I'm trying to get that sense from people who haven't
been intimately involved for ages.

Post by Owen Taylor
- No feature regressions from 1.4
- No unhandled patches in the bug tracker
- 101% key navigable.
- etc.
May be important, but cannot be allowed to block 2.0, because they can
be fixed after or on top of GNOME-2.0, and the cost of losing momentum
with eternal release slippage is large.

Don't disagree there.

Post by Owen Taylor
(*) And we need to be ruthless in taking the simplest path to fixing
such problems. "X crashes" ... "can we remove X?". "Menu item Y does nothing"
"remove menu item Y".

That's fine, to a certain extent. At the point we're at now that's going
to leave us with... well, I'll call it a feature-free desktop. We'll
have to remove most of control-center and large chunks of nautilus. Oh,
and we won't have a window manager. I think these are fairly large
regressions :)

</personal hat>
Luis

[Sander Vesik]

Post by Owen Taylor
* Just pushing the deadline out can often be a very bad way of getting
a stable release out.
- People lose interest
- People start hacking on cool post release features instead of
working on the release
- You get into a eternal cycle of "but we have to fix X" "but we have to fix Y"
"but we have to fix Z".
- Dependencies start shifting underneath you. ("Oh, but GTK+-2.2 will
be out then, we should use that.")

Total agreement here! 8-)

Post by Owen Taylor
- API
- File locations
- String freezes
That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."
I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

While I don't speak for Sun, I don't think Sun would say "we will
quarantee that GNOME-2.0 is out by July", and seeing Luis send out a
message from which such could be implied was quite suprising to me. What
Sun wants to release isn't (AFAIK) entirely the same as the contents of
gnome-2.0 and what priorities for the various parts exists aren't the same
either. So no, we aren't guaranteeing a quality release in july, we aren't
highjacking the release to our own purposes and we aren't doing any other
unreasonable things either.

That said, naturaly, I'm not saying "Ximian can't say they will be working
on x, y and z for a deadline at D" - of course they can (at least as far
as I am concerned), but i'd like it if people excericed some care making
inferences from that to magic hapenning.

Post by Owen Taylor
Regards,
Owen
(*) And we need to be ruthless in taking the simplest path to fixing
such problems. "X crashes" ... "can we remove X?". "Menu item Y does nothing"
"remove menu item Y".
(**) No, not for your grandmother.

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[Luis Villa]

Post by Sander Vesik

Post by Owen Taylor
That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."
I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

While I don't speak for Sun, I don't think Sun would say "we will
quarantee that GNOME-2.0 is out by July", and seeing Luis send out a
message from which such could be implied was quite suprising to me.

My apologies; I thought it made it quite clear that this was a personal
email, and apparently I did not. Again, apologies if I made this
unclear- this is /definitely/ all with my 'community QA person' hat on
and not a Ximian or Sun hat on.

That said- Sun has committed a huge amount of manpower between now and
that date, the vast majority of which will be directed towards fixes
that will immediately impact the community's codebase. I don't think it
is unreasonable for the /community/ to wait for that work to be
completed and take advantage of it for the community release.

To put it another way: I don't personally believe that the 2.0.0 release
that Havoc outlined will be good enough for any vendor to ship*.

<b>If it isn't good enough for any vendor to ship, is it good enough for
the community to ship? Or should the community have high/higher
standards?</b>

I don't know the answer to that question, but it seems to be crucial,
and the community has to decide on it. I /personally/ feel that if it
isn't good enough for vendors it shouldn't be good enough for the
community, but people have cited legitimate concerns in this thread
about why maybe that shouldn't be the case.

*This is based on my assessment of the quality of the codebase and the
observed waiting periods of vendors in the past, /not/ inside knowledge
of the distros' or Ximian's plans.

Post by Sander Vesik
So no, we aren't guaranteeing a quality release in july, we aren't
highjacking the release to our own purposes and we aren't doing any other
unreasonable things either.

I hope no one drew that inference! Sun (and I say this very strictly as
a community member) has been a role model for vendor-community
interaction with their GNOME2.0 work, and has never pushed the community
or the release team about dates. Advised and consulted (as Havoc and I
are doing right now) definitely, but not exerted any undue pressure.

Luis

[Havoc Pennington]

Post by Luis Villa
To put it another way: I don't personally believe that the 2.0.0 release
that Havoc outlined will be good enough for any vendor to ship*.
<b>If it isn't good enough for any vendor to ship, is it good enough for
the community to ship? Or should the community have high/higher
standards?</b>
I don't know the answer to that question, but it seems to be crucial,
and the community has to decide on it. I /personally/ feel that if it
isn't good enough for vendors it shouldn't be good enough for the
community, but people have cited legitimate concerns in this thread
about why maybe that shouldn't be the case.

Again dodging the main issue (I'll try to pick sides on it later ;-)
my view having experience on the vendor side is that it's both
impossible and undesirable for the community to ship a
vendor-acceptable release.

The reason is that a vendor-acceptable release pretty much requires

- a hard-core freeze for a reasonably long time, this just stifles
community development. The freeze is needed for stability,
for strings, for docs. Even if it was a good idea to shut
down the efforts of 300 people for two months, I doubt we
can manage to do it.

- resolving integration-with-the-OS issues. There are tons of small
bugs and misfeatures that get fixed in this area.

I don't really see it as worthwhile for the community to worry about
doing these things, because it damages feature development and the
community isn't going to remove the need for vendors to do their own
freeze and integration work anyway.

To me the community release should be focused on complete
functionality, and good stability, but should aim for the 99% you can
get without having long freezes, leaving the last 1% to be done in a
vendor branch. Otherwise you lose a lot of the momentum of the
community release.

I think it's great that we have the sun-patches module, I'm thinking
of doing a similar thing for RH, and also putting the RH translation
freeze-and-branch in GNOME CVS instead of on i18n.redhat.com. i.e. I'd
like to see these last-1% branches out in the open and always folded
back when appropriate.

Red Hat 7.2 and Ximian GNOME are both a bit more than 1% branches
right now, and I don't want to repeat that for 2.0, though.

Havoc

[Luis Villa]

Post by Havoc Pennington
Again dodging the main issue (I'll try to pick sides on it later ;-)

Hehe... I'm at least partially playing devil's advocate myself; through
the course of the discussion we've now heard a lot of positive reasons
why we should ship early so I'm satisfied the discussion has been
constructive, and I'm glad I started it, regardless of the conclusion.

Post by Havoc Pennington
my view having experience on the vendor side is that it's both
impossible and undesirable for the community to ship a
vendor-acceptable release.

<snip> All very reasonable.

Post by Havoc Pennington
To me the community release should be focused on complete
functionality,

How does this fit with completely dropping features that don't work, as
per the back-and-forth with Sander? I'm still very worried that in the
current state large chunks of nautilus and control-center will have to
be dropped or released unusably broken, which doesn't fit with 'complete
functionality.'

Post by Havoc Pennington
[community release] should aim for the 99% you can
get without having long freezes, leaving the last 1% to be done in a
vendor branch. Otherwise you lose a lot of the momentum of the
community release.

Where is 99%? Are we there yet? I don't personally think we're there (or
even particularly close), but I can see that very reasonable people
would disagree with me on that, and I'd very willing to be overruled on
that count.

Post by Havoc Pennington
Red Hat 7.2 and Ximian GNOME are both a bit more than 1% branches
right now, and I don't want to repeat that for 2.0, though.

If that is to be the case for 2.0, then either:

1) 2.0.0 needs a lot more work

or

2) we're going to have to push 2.0.0 and admit that the 'real' .0 is
2.0.1*. If that is the case, and we accept that the community wants to
get it out and work on other things, who is going to do 2.0.1?

Luis

*It was pointed out to me last night that 1.4.1 hasn't exactly happened
particularly quickly.</understatement> Anyone care to comment on why? I
was 'just a user' for 1.4.0 so I really don't know why.

[Sander Vesik]

Post by Luis Villa

Post by Sander Vesik

Post by Owen Taylor
That block people from doing the final stabiliziation for a vendor
release until the upstream has said "this is it."
I don't think it's reasonable for Ximian/Sun to say "we will guarantee
that GNOME-2.0 is out by July". But once GNOME-2.0 is out, it's
much more reasonable to say "we will have a GNOME-2.0 based product
we feel comfortable shipping by July."

While I don't speak for Sun, I don't think Sun would say "we will
quarantee that GNOME-2.0 is out by July", and seeing Luis send out a
message from which such could be implied was quite suprising to me.

My apologies; I thought it made it quite clear that this was a personal
email, and apparently I did not. Again, apologies if I made this
unclear- this is /definitely/ all with my 'community QA person' hat on
and not a Ximian or Sun hat on.

Well, by handing out dates by which things will happen, and mentioning
company names you already introduce inherent bias. This doesn't magicly go
away by saying "hey, i'm just a freelance int his mail". You are also
handing out an implcit "we will keep up with the bug rate" certificate,
and that may or may not be true.

Post by Luis Villa
That said- Sun has committed a huge amount of manpower between now and
that date, the vast majority of which will be directed towards fixes
that will immediately impact the community's codebase. I don't think it
is unreasonable for the /community/ to wait for that work to be
completed and take advantage of it for the community release.

Possibly - but they should have sufficent information for that decision,
not merely "there is a deadline here sun wants lots of bugs fixed". I
cannot give that information (all the pages read "proprietary. internal
use only"), and even if i could, it would only be an indication of
towards what people will be working, not a guarantee that that set of
things will get done.

Post by Luis Villa
To put it another way: I don't personally believe that the 2.0.0 release
that Havoc outlined will be good enough for any vendor to ship*.

"Any release gnome will ever put together will not be good enough for a
vendor to just ship" - appeared to be the consensus on GUADEC. It could
have been the people present had special high quality requirements in mind
(or didn't speak up), but the highest figure I heard was "95% there". Some
would call this the "code vs product" distinction.

Post by Luis Villa
<b>If it isn't good enough for any vendor to ship, is it good enough for
the community to ship? Or should the community have high/higher
standards?</b>

A vendor will never ship what it gets - it will always throw its QA at the
problem, packport a couple of bugs that got fixed just after the release
and so on. This will be always true, no matter how hard you work or
how long you delay.

Post by Luis Villa
I don't know the answer to that question, but it seems to be crucial,
and the community has to decide on it. I /personally/ feel that if it
isn't good enough for vendors it shouldn't be good enough for the
community, but people have cited legitimate concerns in this thread
about why maybe that shouldn't be the case.
*This is based on my assessment of the quality of the codebase and the
observed waiting periods of vendors in the past, /not/ inside knowledge
of the distros' or Ximian's plans.
Luis

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[Havoc Pennington]

Hi,

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.

Havoc

[Ettore Perazzoli]

Post by Havoc Pennington
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.

IMHO GTK suffered from more than feature creep. The developers just
stopped caring about 1.2 and went on rewriting everything... So of
course it took forever, it didn't get tested by the GNOME community, and
went out late.

What we need is more synergy between GTK and GNOME. GNOME horribly
suffered from the fact that, for a long time, GTK 1.2 was completely
unmaintained, and GTK 2.0 was completely unusable and required a huge
amount of work to port things to. So of course the porting work started
late, and there was not enough time to do proper planning of the new
features and concentrate on making the desktop kick ass from a user's
perspective.

For a long time, we just waited for GTK to be "done". So I think it's
kind of funny that, after spending all this time to let the GTK
maintainers make GTK "Perfect", we are now arguing that the desktop can
go out unpolished and incomplete.

Although, I am not completely disagreeing with you on the fact that we
should just be releasing the damn thing. ;-) I am just pointing this
out in the hope that we won't be making the same mistake again.

Post by Havoc Pennington
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.

Very true.

[Owen Taylor]

Post by Ettore Perazzoli

Post by Havoc Pennington
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.

IMHO GTK suffered from more than feature creep. The developers just
stopped caring about 1.2 and went on rewriting everything... So of
course it took forever, it didn't get tested by the GNOME community, and
went out late.
What we need is more synergy between GTK and GNOME. GNOME horribly
suffered from the fact that, for a long time, GTK 1.2 was completely
unmaintained, and GTK 2.0 was completely unusable and required a huge
amount of work to port things to.

Next, time I really need to try *not* spending ~30% of my time
maintaining the stable branch while working on the development
branch. And see how people like that.

Yes, I don't have time or plans for a 1.2.11 now, but retractively
saying that GTK+-1.2.x was unmaintained while we worked on GTK+-2.0 is
inaccurate and unfair.

Would it be nice if someone else had been around to work on GTK+-1.2.x
while I was doing GTK+-2.0 work? Of course. I'm sure if someone
without the necessary skills and experience was willing to take on the
job, we'd have had more maintenance on the 1.2.x branch and a faster
2.0.0 release. Nobody was.

Post by Ettore Perazzoli
For a long time, we just waited for GTK to be "done". So I think it's
kind of funny that, after spending all this time to let the GTK
maintainers make GTK "Perfect", we are now arguing that the desktop can
go out unpolished and incomplete.
Although, I am not completely disagreeing with you on the fact that we
should just be releasing the damn thing. ;-) I am just pointing this
out in the hope that we won't be making the same mistake again.

I hope that mistake you are referring to is not that we spent a lot of
time making sure that the new GTK+ API's actually worked well and will
work well going forward.

Maybe you are saying that the mistake was letting the desktop *become*
unpolished and incomplete just because GTK+ was undergoing major
work. I'd agree with that.

Feature addition to GTK+ was mostly done almost 18 months ago. By cutting
work before that point, we could have sped GTK+-2.0 up, and before
that point, it wouldn't have been reasonable to work on porting the
desktop to GTK+.

But getting GTK+-1.2 to compile against GTK+-2.0 has never been hard,
and even before we stopped adding features, it continually compiled
and worked in CVS. So there is no reason that people couldn't have
ported the GNOME-1.4 desktop as is to GTK+ quite ago, and worked from
there, without ever having had the intermediate "can't compile, can't
run" stage that we were in for quite a while. (But are well away
from now!)

Anyways, I don't want to start pointing fingers. And keep the turn-around
times short is an important goal for 2.x releases of GTK+.

I'm just all-in-all quite happy with how the GTK+-2.0 release cycle
went and the end product, and am a little upset at the implication
of irresponsibility in your mail.

Regards,
Owen

[Ettore Perazzoli]

Post by Owen Taylor
Next, time I really need to try *not* spending ~30% of my time
maintaining the stable branch while working on the development
branch. And see how people like that.

I was not implying that that would have been a good idea either.

Post by Owen Taylor

Post by Ettore Perazzoli
For a long time, we just waited for GTK to be "done". So I think it's
kind of funny that, after spending all this time to let the GTK
maintainers make GTK "Perfect", we are now arguing that the desktop can
go out unpolished and incomplete.
Although, I am not completely disagreeing with you on the fact that we
should just be releasing the damn thing. ;-) I am just pointing this
out in the hope that we won't be making the same mistake again.

I hope that mistake you are referring to is not that we spent a lot of
time making sure that the new GTK+ API's actually worked well and will
work well going forward.

Of course not. :-)

The work on the GTK+ API has been great and now we have a much better
platform to work on, but at the same time, GTK+ could have tried to
solve fewer problems at the same time, and then we would have had a
shorter development cycle and people would have not been waiting for the
2.0 release of GTK+ for such a long time.

Post by Owen Taylor
Maybe you are saying that the mistake was letting the desktop *become*
unpolished and incomplete just because GTK+ was undergoing major
work. I'd agree with that.

That's also part of the problem. It was not my intention at all to put
all the blame on the GTK+ developers. But sure having a shorter GTK+
release cycle would have helped that as well.

The thing is, for a while the GTK+ world and the GNOME world have been
kind of separate universes. GTK+ had its own schedule and its
particular set of priorities, and they were not necessarily the same as
GNOME's. I think that really hurt the project; the long release cycle
of GTK+ might have been good for GTK+, but it was no good at all for
GNOME.

All I am asking for is that, in the future, we make sure that the two
camps are on the same track. Which is what is already mostly happening
to the best of my knowledge -- but I pointed this out as Havoc's message
seemed to blame the featuritis and delay attitude on the GNOME part,
which I think is a bit unfair.

Post by Owen Taylor
Anyways, I don't want to start pointing fingers. And keep the turn-around
times short is an important goal for 2.x releases of GTK+.

Yeah, I am really glad that that's what is going to happen.

Post by Owen Taylor
I'm just all-in-all quite happy with how the GTK+-2.0 release cycle
went and the end product, and am a little upset at the implication
of irresponsibility in your mail.

I apologize if my message came out as an accuse of irresponsibility.
That's really not what I meant to do.

[Havoc Pennington]

Post by Ettore Perazzoli
All I am asking for is that, in the future, we make sure that the two
camps are on the same track. Which is what is already mostly happening
to the best of my knowledge -- but I pointed this out as Havoc's message
seemed to blame the featuritis and delay attitude on the GNOME part,
which I think is a bit unfair.

Just to clarify, when I was talking about GNOME and featuritis/delay,
I would normally consider GTK part of GNOME. I did not mean "GNOME
vs. GTK" but "GNOME vs. other unrelated software projects on the net"

My comments are based on a relatively long view of things going back
well before I'd even worked on GTK.

Havoc

[Alex Larsson]

Post by Luis Villa
(1) a 2.0.0 that has no major, individually embarassing bugs, but a
huge collection of bugs that make the overall level of quality
embarassing, but it Works For Us.
(2) waiting and having a 2.0.0 that is completely free of highly
embarassing bugs and has a very small number of bad bugs. It Works For
People Who Are Not Us.

I think this is a highly biased description of our options. Let me give
you the opposite view (note: It's not my personal belief that either of
these views are correct).

We have to options right now:

(1) a 2.0.0 that has no major, individually embarrasing bugs, is basically
stable but has a large collection of small bugs (many of which were even
in Gnome 1.4). A user can use this desktop and mostly get his work done.

(2) We postpone 2.0.0 indefinately, waiting for "all the bugs to get
fixed". But nobody is interested in working on the boring blocker bugs
(after all, gweather was broken since 1.0, why should I care about it
now). We slowly slip our release dates, eventually past the next Mandrake
(insert random distro here) internal feature freeze date. They take a look
at gnome 1.4 (latest stable), compare it to KDE 3.1 (KDE is good at doing
regular stable releases), laugh and decide to drop gnome support. After
the firste distro drops gnome everyone else soon follows suit. No users
see the new gnome code, so everyone assumes it's a stagnant project. Gnome
becomes a footnote in the annals of history. RIP.

See the difference?

Anyway. Personally I don't think May 22 is quite possible. And I'm willing
to delay it a bit to stableize the release. But I strongly belive that we
must be punting feature requests, drop broken features that nobody is
actively fixing, and punt non-crasher bugs in non-critical components.

Not delivering a stable release can hurt us very badly. Remember, there
will be more releases. This one doesn't have to be everything to everyone.

[Sander Vesik]

Post by Alex Larsson
Anyway. Personally I don't think May 22 is quite possible. And I'm willing
to delay it a bit to stableize the release. But I strongly belive that we
must be punting feature requests, drop broken features that nobody is
actively fixing, and punt non-crasher bugs in non-critical components.

Yes - and I think it is quite a bitmore important to discuss *when* is a
possible date, not just "we delay it" and "no we will not delay it". May
22 is probably not a good time (hey, I can think of several things with
say docs that would not be in a good shape due to the hurry), but I don't
think mid-july is good either.

Post by Alex Larsson
Not delivering a stable release can hurt us very badly. Remember, there
will be more releases. This one doesn't have to be everything to everyone.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
He's a globe-trotting dishevelled cat burglar searching for his wife's true
killer. She's a cosmopolitan tempestuous lawyer in the witness protection
program. They fight crime!

Sander

I see a dark sail on the horizon
Set under a dark cloud that hides the sun
Bring me my Broadsword and clear understanding

[Luis Villa]

Post by Alex Larsson
(1) a 2.0.0 that has no major, individually embarrasing bugs, is basically
stable but has a large collection of small bugs (many of which were even
in Gnome 1.4). A user can use this desktop and mostly get his work done.

It is my (again personal) belief that the currently suggested collection
of small bugs will (1) collectively be kernel-2.4.0 level embarassing
and (2) be a total turnoff to new users. It'll be fine for old-school
gnome folks, and if that is what the community thinks the target
audience is, yay, great, like I said- I'll work my ass off for it.

Post by Alex Larsson
(2) We postpone 2.0.0 indefinately, waiting for "all the bugs to get
fixed".

I never said indefinitely but whatever :)

Post by Alex Larsson
But nobody is interested in working on the boring blocker bugs
(after all, gweather was broken since 1.0, why should I care about it
now).

As said in other emails, this is a definite and real fear. My personal
sense is that people are not yet at that stage but I admit that I don't
know that for a fact, which is why I'm looking for feedback.

Post by Alex Larsson
We slowly slip our release dates, eventually past the next Mandrake
(insert random distro here) internal feature freeze date. They take a look
at gnome 1.4 (latest stable), compare it to KDE 3.1 (KDE is good at doing
regular stable releases), laugh and decide to drop gnome support. After
the firste distro drops gnome everyone else soon follows suit. No users
see the new gnome code, so everyone assumes it's a stagnant project. Gnome
becomes a footnote in the annals of history. RIP.

My concern is that if we rush they'll do the exact same thing when
comparing gnome 2.0 and kde 3.1.

Post by Alex Larsson
Anyway. Personally I don't think May 22 is quite possible. And I'm willing
to delay it a bit to stableize the release. But I strongly belive that we
must be punting feature requests

We've been punting feature requests for ages; I'm sorry that my reports
suck too much so they included those. I fear that led to confusion, and
it was unintended. As Havoc will tell you I've been first in line to
scream at new features for some time. Please, please ignore anything
that is marked enhancement :)

Post by Alex Larsson
drop broken features that nobody is actively fixing

The vendors /will/ be fixing at least some of those; like I said to Owen
if we drop all of those right now we'll have a basically non-functional
desktop.

Post by Alex Larsson
and punt non-crasher bugs in non-critical components.

Again, lots of little bugs add up to a seriously embarassing release for
people who are new to gnome. Yes, we need to be punting stuff. But I've
been (effectively) punting stuff for months- take a look at all the
GNOME2 bugs that /aren't/ 'high' priority. The sum total of that list
will scare you.

Luis