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

List:       kde-core-devel
Subject:    Re: KDE Development Policy
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-03-09 9:12:58
[Download RAW message or body]

On March 9, 2002 09:36 am, Navindra Umanee wrote:
> Simon Hausmann <hausmann@kde.org> wrote:
> > How many people do you think would have downloaded and applied Michael's
> > patch to test it? :)
>
> I think the real issue here is a PR/communication issue.  Just like

agreed. i think that is 80-90% of the issue ... one of the responsibliites of 
the RC should be to facilitate communication ... i don't think that happened 
as well as it could have, but we are dealing with developers here not MBA 
Management Folk (thank god!)

the other 10% - 20% of the issue is sticking to the plan at hand ... here are 
some examples that reflect my opinion (and only my opinion) on this matter of 
sticking to a plan:

When ... in a feature freeze and a new feature goes in, and some developers 
are for its inclusion and some not, the RC needs to quash any questions about 
it and step up and say, "No, sorry, this will wait for 3.1." Saying "No" is 
damn hard, but nobody will lose respect or get hurt feelings for it being 
said and it is often what stands between a never ending or buggy release and 
one that goes smoothly.

When ... important and fundamental issues are not being dealt with, the RC 
needs to encourage (and get) the right people talking and coding to address 
those issues early on instead of letting them go until last minute. This 
avoids stressing the developers and avoids decisions being made without 
enough time to think or test.

When ... a devel cycle starts, every infrastructure component needs to be run 
over like a checklist: "Do we need to update basic component X? If so, why do 
we need to and what do we need to have it capable of at the end? Who will do 
this?" And by "infrastructure component" I mean things like the build system. 
Such a meeting should take no more than a couple of hours in person, on the 
phone or on IRC and it will help ensure that changes that need to be made are 
made appropriately early on in the release schedule.


That said, I don't feel that 3.0 is in jeopardy. I think that it is coming 
through just fine. I think it has been harder on the developers than it had 
to be, and I think it was harder on the schedule than it needed to be. But 
the road to 3.0 was no mean feat given what had to be accomplished. I also 
think that expecting someone (Dirk, in this case) to jump into a new role 
with both feet and land perfectly is unrealistic: of course there will be 
adjustments and learning to do on all sides, both developer and RC. Change 
requires adaptation and learning by everyone.

In the end, the struggles of 3.0 will not be lost if we get a solid 3.0 out 
the door and learn from this process for next release, and eventually for 
when we need to chart through these same waters to a 4.0 release a few years 
from now.

So, some positive thoughts, because all such conversations should end with a 
few of them:

 o KHTML and KJS are absolutely rocking!
 o KOffice is looking better all the time!
 o quality components like kprint and kssl are what make KDE komplete!
 o DCOP is maturing into quite the scripting tool!
 o valgrind has been immensly helpfull in tightening down the bolts!
 o the artwork is only improving!
 o the speed is only increasing!
 o the KDE developers have been working double plus hard!
 o the world is awaiting 3.0 and the legions of KDE fans can't wait to get a 
taste of it!

I think that in the end Konqi and Katie will be proud ... 

-- 
Aaron Seigo, who is waiting over coffee for his morning build of KDE to finish
[prev in list] [next in list] [prev in thread] [next in thread]