[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: HEAD open for commits
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2002-11-29 13:38:44
[Download RAW message or body]

Stephan Kulow wrote:
 > Am Friday 29 November 2002 13:31 schrieb James Richard Tyrer:
 >
 >> Aaron J. Seigo wrote:
 >>
 >>>> Whether it is with commercial software or open source software,
 >>>> users do not like to hear that the bug has been fixed (or will
 >>>> be fixed) in the next major release.  They should not hear
 >>>> that.  Major releases are for new features NOT for bug fixes.
 >>>
 >>> no, minor releases are for both bug fixes and feature
 >>> enhancements. revision releases are bug fixes, not features.
 >>>
 >>> (release numbers are major.minor.revision)
 >>
 >> Sorry, I don't totally speak UNIX either.
 >>
 >> Commercial software is usually: version.major.minor {with letters
 >> added on for revisions}
 >>
 >> So, I will try it again:
 >>
 >> Whether it is with commercial software or open source software,
 >> users do not like to hear that the bug has been fixed (or will be
 >> fixed) in the next minor release.  They should not hear that.
 >> Minor releases are for new features NOT for bug fixes.
 >>
 >> But my point is that you shouldn't have to wait for the next minor
 >> (the middle number) release for a bug fix.
 >>
 >
 > You have the right to have your opinion on that. But frankly for KDE
 > 3.1 we fixed roughly 1000 bugs

You miss my point which is that many of these bug should have been fixed
previously.

 > and it was a hell lot of work. So better give these bug fixes and new
 > features to the users and continue the work.
 >
??? :-|  My point is that some of the bug fixes should have gone out sooner.

 > Writing software is evolution and if you wait till one release is
 > perfect, you will have lost all users because they got tired of their
 > bugs

I was really tired of seeing the same minor bugs in 3.0 that were in 
2.0.  Even more discouraged when one of them appeared to get worse.  Yes 
it is finally fixed.

 > and lack of features

I don't think that we need to worry about lack of features anymore.  We 
should worry more about feature bloat.  And I am sure that most users 
are more concerned about bugs being fixed than about having new 
features.  In the final analysis, if you don't fix the bugs but do pile 
on new features, will that make users happy?

 > and you will have lost all developers because fixing bugs stopped
 > making fun seven years ago.

You create a false dichotomy.  Clearly, this is an optimization 
question, and I am not suggesting that revision releases should be held 
up until all of the bugs are fixed.  Quite the opposite they should be 
released regularly.  If there was to be a pause, I would think that it 
should be measured in weeks and should result in the necessary revision 
releases.

So, I ask: how much work will be done on 3.0.x after 3.1.0 is released?

What I am suggesting be held up is the full fledged development of the 
next minor release, and that it should be based on the current release, 
not a separate branch.  CV allows you to do this, you can have a 
development model that you can't even draw on paper.  Yes it would be 
more difficult.

It is not a question of waiting till it is perfect.  Just one of when 
you stop on one release and start on the next, and how you organize this 
transition.  Yes, some preliminary work should be underway on the next 
minor release.  But I seriously question announcing that the major focus 
of development has shifted to the next minor release even before this 
one is out the door.

--
JRT



 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]