From kde-core-devel Sat Mar 09 09:12:58 2002 From: "Aaron J. Seigo" Date: Sat, 09 Mar 2002 09:12:58 +0000 To: kde-core-devel Subject: Re: KDE Development Policy X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101570025419646 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