Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote:
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.
... good, I already felt watched :-)
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 ...
Unfortunately nothing is easy here, and it is neither black or white. So we should find a good balance. I have to admit that I do remember changing the API "somewhat" incompatible, though I believed that I had it under control ... sometimes this held, sometimes not.
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?
This is difficult ... I think that a good approach is, to be somewhat relaxed regarding adding/changing/removing APIs, though we may want to ensure that most of it is done e.g. in a major only.
Biggest problem I currently see is consistence, it may be OK for a (new) API to compete somewhat with another one, though over time we want to ensure to consolidate again.
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).
No doubt about this :-)
... ahh, isn't obvious that developers are smarter, brighter and more intelligent, so that they quasi implicitly and automatically understand the benefits of an API change :*) ?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.
This is the one source of improvement, the other one is time to iterate, no perfect API has ever fallen from heaven (or so).
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.
Just not scaring them away would already be an improvement ...
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.
We certainly should be time / conscience driven. There is no doubt that one can spend endless time refining an API etc., though real life feedback is only available after releasing it. And we certainly introduce bugs, inconsistencies and oddities. It is important that someone introducing or changing an API takes over responsibility, to refine it, to adapt it, to consolidate it and to communicate it. It is more important that the owner keeps responsibility than to ensure that we never ever break anything.
Ciao Frank
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
