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

List:       kde-core-devel
Subject:    Re: KDE Development Policy
From:       Andreas Pour <pour () mieterra ! com>
Date:       2002-03-09 19:56:25
[Download RAW message or body]


Score:  5 (Insightful)

"Aaron J. Seigo" wrote:
> 
> 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]