Hi Michael, > Well - it looks like that on the face of it. However - while I > absolutely loathe the process, I can (perhaps) live with it - if it > actually worked :-) Sadly it is totally dysfunctional. If 1 (one) > interaction can take of the order of months to occur, the spec. process > which mandates another order of magnitude more interactions, puts any > feature inclusion into the multiple year time frame. My problem > primarily is with responsiveness & inclusion. > ... > Well, (apparently) my sarcasm has at least got people to discuss this > problem that has been festering, un-fixed for some years now. My feeling > is that some parts of Sun are in fact eager for the process to be > burdensome - precisely to raise the barrier to entry, and ensure that > (to their mind) "only the best" work gets included. To my mind this is a > tragedy and a sure-fire recipe for continuing to not attract any > developers. I sometimes think that some people are also in fact quite > pleased that eg. it's impossibly difficult for the average developer to > build on 2 platforms before getting their CWS included, (which would > explain the almost total lack of action wrt. making this easier to do).
What should I say - that's not the way it should be, that's not the way I expect it to be, and that's not the way I've been briefed to go. I agree with you that those hurdles experienced by contributors are a big reason for not attracting more developers. However, I see chances that we get changes to the better here, since my personal impression is that the awareness for all those hurdles, and the fact that they prevent a growing community, is raising. All I can seriously recomment is: keep fighting. Both for people from "outside Sun" as well as "inside Sun" :). >>Or are there chances we find a compromise? > > I'd love to find a compromise, but this has to be part of a bigger > discussion as to why OpenOffice.org is failing to attract a meaningful > developer community - and who owns that problem; or if it even is a > problem. (There seems to be substantial doubt in a lot of people's minds > here). > > There also appears to be a "free labour" perception of volunteers in > certain places: that these people can be asked to do arbitrarily > unpleasant things, and that they will do them. I'd like to persuade > people this is (emphatically, and clearly) not the case. Continue persuation :) I will do myself, as I did in the past, since I heartly believe that we cannot throw all full-blown processes at a newcomer who does a small fix/feature. This doesn't mean those processes/requirements are unnecessary or stupid, it just means that we should allow people to grow and learn, and not do everything right and complete in the first step. > That if Sun QA > wants to include all this process for Quality reasons, then -it- must > shoulder the burden [ at least for volunteer contributions ]. > ... >> Somehow I think this particular feature *should* have had some >> more QA, in other words: some involvement of more parties. > > > Well - my attitude here is rather different :-) in the time that it > took to create the CWS, commit the code, go through QA etc. I had in > parallel done a number of other improvements / fixes, and subsequently > then fixed a number of other issues which were kindly reported when (you > guys) started using it in the milestone - all of which are committed to > gtkquickstart2 - which FWIW improves the usability, makes the settings > instant apply, etc. and starts to be a rather nice solution. Well, and that's a fundamental misunderstanding on your side, sorry. That's explicitly *not* how OpenOffice.org works. The whole idea of child workspaces is closely coupled to the idea of having a stable master build. In ideal, we would be able to ship every master build (in reality, that's not the case, but we're much better than some years ago). That's an explicitly stated goal of the OpenOffice.org project: We don't break the master, we finish implementations in a child workspace, until they're really finished. Other projects have other means for ensuring quality. For instance, Mozilla has a *very* rigid code review process. OpenOffice.org's mean for ensuring quality is the "finish it on a child workspace" policy. There's no room here for "put it in and let it evolve". You might want to question this idea and policy, but please not by silently undermining it. > Having a formalised process (1 paragraph necessary?) for quickly > including code into OO.o that is disabled in all Sun builds, and quickly > getting fixes / changes into that etc. would be much appreciated. This > is something we have been wanting for some years now; but no action. That's still not the way to go here. What I personally dislike about our specification/iTeam processes is the fact that a specification is a fire-and-forget thing. Unless we embed this into a context (e.g. a document management system which helps us keeping documents up-to-date, searchable, and the like), the specification *document* itself is very prone to become useless over time. However, what I really *really* like about this process is the exchange of ideas and arguments. In my experience, sitting down (or meeting in IRC) with a small (!) number of people having experience with and/or interest in a particular feature is invaluable. You always gain insights you wouldn't have had alone. And finally, this means you deliver a better feature. So, I still think that "put it in quickly and disable it in Sun builds" is the wrong way to go. Especially since this effectively means a fork, in the long run. If 10 percent of the code are not used in default builds provided at www.openoffice.org, than that's a (distro-specific) fork, not more. As an example: If you've had used such a process for the quickstarter port, this would still have been an unfinished feature in a master build. (I did mention that "Use systray quickstarter" makes me expect that when I check it, the QS is started immediately, didn't I? There's room for improvement from a user experience point of view, that's why iTeams are recommended to contain a user-experience-trained person.) What I would like to see is - the awareness inside Sun that contributors must have the less hurdles the more unexperienced they are - all Sun people living this :) - the awareness outside Sun that "Just Do It (TM)" is an advertising slogan, but not the philosophy of OpenOffice.org development. - you living this :) - the awareness that both things are good for our users, finally. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
