[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 8:06:27
[Download RAW message or body]
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 <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic