Dirk Mueller wrote:
> Hi, 
> 
> CVS HEAD is open for commits again for KDE 3.2 release. 
> 
I must say that I am not happy to hear this.

I still am unable to compile three packages in KDE_3_1_0_RELEASE.

<irony> So, we won't really concern ourselves with the bugs in the 
current release which won't even compile, we will just rush on with new 
features. </irony>

I would like to suggest that I feel that this model of the development 
tree is WRONG -- that it contributes to buggy code.  Yes I know that 
many projects do it that way -- and many projects produce buggy code.

First I would like to suggest that we take a pause here.  Release 3.1.0 
has a certain significance when compared to the competition: Windows. 
It was after that release that Windows went into feature bloat and 
change for the sake of change and never mind fixing the bugs.  It 
finally reached the point before the release (or escape) of Windows 2000 
that the code was such a mess that nobody understood how it was supposed 
to work and a programmer with a phD in CS was assigned to try to fix it. 
  He and a team of professional programmers were unable to do the job.

My point is that we should be very careful not to in any way repeat the 
mistakes of MicroSoft Windows.

As I understand the current model, the release is branched off and 
becomes the less important while HEAD continues immediately with new 
development and becomes the more important. I see this as the first 
problem.  The current release should be the more important and work on a 
future release should be the less important.

One model I have seen is simply not to branch the current release for a 
certain period of time with new features being worked on separately to 
be  integrated into the current HEAD at the end of this post release 
development pause.  What I see as the most advantageous part of this is 
the bugs do NOT need to be fixed twice -- that the new features are 
added to the release after a period of bug fixing.

I would like to see this method made somewhat permanent.  That the 
current release remains HEAD until it is decided that the final minor 
release has been made and only then is it branched off.  Until that time 
all new features would be in a temporary branch and would have to be 
based on the new release.

And, yes I know that this would make it more difficult to add new 
features, but would also make it easier to fix the bugs.  And, would 
also require that the bugs be fixed in the current release.

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.

So, that is my manifesto.  I would appreciate it if I received no 
arrogant and flippant comments about this.  They do not in any way 
promote a useful discussion.

I also wanted to make a note here so that everyone that reads this will 
know:  I am a professional programmer retired on disability.  I studied 
Electrical Engineering & Computer Science in college.  There is much 
that I do not know about the KDE project.  But I know a lot more about 
computer programing than some of the self taught hackers that have been 
telling me that I don't know anything (yes that is an arogrant remark). 
  I don't appreciate it and you only make fools of yourself doing it.

--
JRT

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<