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

List:       kde-devel
Subject:    Re: KDE Development Policy
From:       Malte Starostik <malte () kde ! org>
Date:       2002-03-09 9:17:07
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag 09 März 2002 08:48:08 schrieb Neil Stevens:
> KDE 3 has been mismanaged by the KDE developers.  The standards and
> practices of the KDE development community, those held in the
> successful KDE 2 series, have been abandoned.  The result has been a
> failed release candidate, growing developer discontent.  The future,
> though uncertain, is likely to bring the conclusion that KDE 3.0 was
> the highest profile KDE failure to date.
If you were fair, you would compare KDE 3.0 RC 1 with KDE 2.0 RC 1.
There have been numerous bugs in the early phase of the successful KDE 2 
series as well (1), (2) - just a random selection.

> When the evidence is brought together, the current state of KDE 3.0's
> development is easy to call a failure.  Release Candidate 1 and
> current cvs are plagued with problems including:
>
> 1) Packages missing from the release entirely (1)
> 2) Rampant compile problems
There are always compile problems. Most are fixed almost immediately, in many 
cases a clean rebuild or partial cleaning is enough.

> 3) Last-minute changes to build requirements that cannot be met by
> many developers without an operating system upgrade (2)
There have also been problems with the build system around KDE 2.0 RCs (3).

> 4) Many outstanding bugs (3)
Does the sentence "feel free to submit a patch" sound familiar to you?

> While these problems are bad enough, they in turn throw up further
> obstacles to a stable release:
>
> 1) When users and developers cannot build KDE, they cannot test KDE
I just built KDE from scratch today, without a single problem. I can't recall 
having I've applied any magic to get there.

> 2) When developers are locked out of KDE builds, they cannot
> contribute fixes.
Sorry? The sentence makes sense in itself; what are you referring to though?

> From the time of one week before KDE 2.2, until the final release, all
> changes to the source had to be reviewed on the KDE mailing lists
> (save, of course, trivial changes whose differences are included in
> the log message). (4)  The justification for these changes was
> explained very well by the KDE 2.2 release coordinator Waldo Bastian
> in a mail to the developers (5), in which he said "[Y]ou will have to
> respect release freezes" if you put your code into KDE.
What do you think is the reason for all the patches currently posted to 
kde-core-devel for review? (4)

> In contrast, the time leading up to KDE 3.0 RC 1 is best described as
> a flood of un-reviewed changes to the sources. (6)  The flood was met
> with excitement, to be sure, because the flood came from a rare
> opportunity for roughly 20 KDE developers to meet in person and
> develop.  This opportunity was not to be passed up, but it could have
> been handled differently.
As has been said before, the personal reviewal that took place there is of no 
less quality than reviewing patches posted to the mailing list. Sorry if you 
feel excluded, but would you really want to get a few hundred patches on 
core-devel a day for a week?
If you don't agree with a specific commit, you can always reply to the commit 
message, that's what kde-cvs is for. Or reply to the author, to 
kde-core-devel or whatever place you think appropriate. If someone broke your 
code, you can as well revert it.

> If the developers in in the meeting felt that avoiding the mailing
> list was the best way to maximize use of the meeting, then they easily
> could have proposed a delay in the KDE 3.0 release, to allow for more
> time to stabilize after the meeting, to allow for testers to catch up
> with their time of great productivity.
No problem if you just seriously ask for a delay of the release. If you don't 
feel comfortable with a group of developers committing a lot of bug fixes 
during a short time period, that's not at all a reason to depreciate Dirk's 
work as a release coordinator. If everyone waits for things to stabilize, 
things don't stabilize as everyone just waits.

On one hand you want bugs to be fixed, on the other you complain when someone 
does that. This sounds paradox at best.

(1) http://lists.kde.org/?l=kde-core-devel&m=97112910916901&w=2
(2) http://lists.kde.org/?l=kde-core-devel&m=97177733308130&w=2
(3) http://lists.kde.org/?l=kde-core-devel&m=97032595704386&w=2
(4) http://lists.kde.org/?l=kde-core-devel&r=1&b=200203&w=2

- -- 
Malte Starostik
PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A  27CD 5431 7745 D2F3 C787]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8idMVVDF3RdLzx4cRAlQ9AJ9peuJ/ChcPS+9vfscP1LpjJ+FjAgCfR7+8
OHmrLrlwyeFZAxXZbGz9+SY=
=BwM0
-----END PGP SIGNATURE-----

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