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

List:       kde-devel
Subject:    Re: KDE Development Policy
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2002-03-09 13:11:55
[Download RAW message or body]

The first mail spoke for the three listed parties.  This mail does not, to 
my knowledge.

On Saturday March 09, 2002 01:17, Malte Starostik wrote:
> There are always compile problems. Most are fixed almost immediately, in
> many cases a clean rebuild or partial cleaning is enough.

But when on many consecutive days there's a stupid problem every day, it 
prevents any testing from being done, since one has to keep updating, and 
keep building.  And of course you can't avoid the total rebuild since of 
the necessity of getting BC changes in now, before the final release.

Hard freezes allow for testing.  Free for alls among a clique of 
developers do not.

> > 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?

Most recently, the admin breakage, but it applies to the constant stream 
of irresponsibile breakages that have gone in ever since the Nuernberg 
meeting and beyond.

> What do you think is the reason for all the patches currently posted to
> kde-core-devel for review? (4)

OK, let's hold this thought... very important.

> 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?

And now we contradict ourselves!  Now approval by those with SuSE pixie 
dust plays under an entirely different set of rules, while our so-called 
coordinator did not a thing about 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.

I don't blame just Dirk.  I blame every developer who broke the thing.  
Dirk didn't sign up to be the nanny of the CVS.

Finger pointing only helps figure out what to fix for 3.1, though.  All 
that can be done at this point for 3.0, the immediate concern, is to drop 
the idea of calling the next release RC 2 or final.  Call it beta 3, 
finally put a real freeze on the cvs, get some real testing, and have a 
KDE 3.0 everyone can be proud of.

I've now asked for it repeatedly, and the replies keep insisting the 
private meeting made things better, yet the only proof that's come out is 
the lie of a Release Candidate.

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

But you all didn't improve things... the cvs was less compilable 
afterward.  Ask any poor fool who got suckered into downloading RC 1, 
especially those with metered internet connectvitiy.

-- 
Neil Stevens
neil@qualityassistant.com

Don't think of a bug as a problem.  Think of it as a call to action.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]