Hi Mathias, >> I'd say we need a set of highly proficient and highly respected >> architects, whose opinion should, at least, be weighted high. > > No, please not!
Actually I wasn't kidding as much as Thorsten supposed :-\ No, I do not really think that a formal process such as "3 out of those 5 people have to agree to your change" works out. On the other hand, I agree to Thorsten that changing (published?) UNO API should *require* discussion at least, and not left to the discretion of a single developer. And for "respecting the architects" ... this can be informal, too. If certain people join such a discussion, then I'd certainly weight their opinions higher than other's. And if a few such people disagree with such a change for good reasons, then the lead of the project where the change is made should have the right to reject it, justified by exactly this disagreement of those people. Something like this ... > Every code change can break something, so why should API changes be > treated differently? We should keep it simple. The only difference > should be that arbitrary code changes can be done at any time while API > changes can only be done at certain points in time. > > We could say: API changes (including changes of language bindings) can > be made in every major release, and you can change everything you want. I agree to Stephan here that this is way too generous. > Of course (as for every code change) you should do that accountably and > talk to other developers that will be influenced by your changes and you > should try to make your changes in a way that the potential work of > others is minimized. Come on. We both know the time and resource and whatever constraints on an ordinary developer's work. Letting everybody chose, at his own discretion, between the easy way which will have noticeable negative impact on a lot of extensions, and the difficult way which will minimize those impact - in a lot of situations, the former will be chosen. "It must be done quickly because of <very_good_reason>, so let's take the short way. We care for the side effects later." Know this from somewhere? An besides that, looking at the quality of some of our (also more recent) APIs, I indeed think that a lot of them could have benefited from being discussed in early stages. Establishing a culture of discussing UNO API before bothering our users with it would be a Really Good Thing (TM). Approaching this from another side ... When you do a user interface change, there usually are extensive discussions about it, possible alternatives, pitfalls, problems, solutions ... specifications ... That's for a good reason (well, most of the time), because all our users are, or can be, affected by it. What is it that makes us developers think that API users are less important than UI users? Why can we, at our own discretion, decide how to best alienate API users, while we need UX experts and long discussions for deciding how to alienate UI users? Yes, the average developer has more API design expertise than UI design expertise. Nonetheless, API design greatly benefits from feedback from other experts, as does UI design. Sure, we have less API users than we have UI users. But they are multipliers, and as other successful examples show - Firefox, Microsoft - cuddling them is key to the success of the product. And in my very personal opinion, we certainly won't cuddle API users when we open the door for each and every API change, without discussion, constrained by the usual "you must finish this feature by yesterday" imperative. We *really* should have some gate keeping, because our UNO API is too important. Not necessary a strictly formal one, but even the requirement for a public discussion will serve a certain gate keeping purpose ... > Let things evolve and > assume that all participants in the development process act reasonably. Assume? Well ... no, that would be too misanthropic ... :) > A bad API change should be treated as any other code change or patch > that we have nowadays: if you see a problem with it, raise your concerns > and discuss. If the bad API change is found in a released product, there's no gain in raising concerns and discussing. It's even worse than finding a bad UI change in a released product: the latter can easily be corrected in the next version, the former can't, or only at the cost of introducing additional legacy/compatibility burdens. Sorry, I stay with this: API should be as good as reasonably possible *before* put into the MWS, or even a release. And this requires discussion, most of the time. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
