From kde-core-devel Sat Mar 09 19:56:25 2002 From: Andreas Pour Date: Sat, 09 Mar 2002 19:56:25 +0000 To: kde-core-devel Subject: Re: KDE Development Policy X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101570384026429 Score: 5 (Insightful) "Aaron J. Seigo" wrote: > > On March 9, 2002 09:36 am, Navindra Umanee wrote: > > Simon Hausmann 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