| Re: [cross-project-issues-dev] JFace Generics |
Krzysztof,I'll draw your attention to https://bugs.eclipse.org/bugs/show_bug.cgi?id=411890 if you think EMF is an example of a stable mature project that can't do interesting innovative things to provide useful new functionality based on community contribution while maintaining binary compatibility. I'm not sure why Tom Schindl is absent in these stats: http://dash.eclipse.org/dash/commits/web-app/summary.cgi?login=y&year=x&top=modeling&project=modeling.emf.emf&company=individual
I'm quite sure that breaking binary compatibility in EMF would be an unmitigated disaster, given the current status quo for our technology stack. Now if as a community we had a discussion about the whole stack taking a big step forward, e.g., let's toss out all the mistakes we wish we hadn't made and fix them properly, without concern for binary compatibility, we could as a community move forward from that point. But I know with the initial e4 discussions, that approach was considered a no go. I get the sense that in this thread, many as you do would argue to the contrary. Be that as it may, that's nevertheless the status quo for the platform and hence for much of the stack, particularly technologies such as EMF near the bottom. So if providing 100% binary compatibility is a crime, I'm definitely a criminal. But let me be very clear, if, as a community, we decide that breaking API is necessary and good behavior, I'd be happy to join the new revisionist part.
In any case, as a project leader, one has many responsibilities, including the obligation to ensure that the framework remains logically cohesive and technically sound. Anyone who argues they have defined obligation to let contributors take the project wherever they wish and meanwhile arguing they have no obligation to consider the impact on, and the opinion of, the adopter community, is most certainly choosing to see only one side of the coin.
Regards, Ed On 01/09/2013 4:58 PM, Krzysztof Daniel wrote:
On Sat, 2013-08-31 at 09:07 +0200, Ed Merks wrote: Ed,John, Please me be equally provocative. Suppose I decide I'd like EMF to progress a lot faster, after all, it's very limiting maintaining all this binary compatibility and it would be so wonderful to fix mistakes of the past. So, all things considered (well, all things considered that matter, i.e., just my own opinion), I'm going to make changes to introduce EMF 3.0, and of course I'm going to release it into the train as I've always done. Unfortunately EMF's plugins are singletons, so everyone on the train will have have to consume what I provide; no EMF 2.10 won't be on the train. It will start use dependency injection right in the core, so adopters will depend on those bundles too; dependency injection is great. Yes, that means you too, Eclipse platform, you must live with whatever I decide it best for my project's future; just go read the rules and if in doubt ask John about the subject, he's stated his opinion very clearly. I'm well within my rights to disregard anyone's and everyone's feedback as I see fit. Of course I know you adopters won't all be pleased, but I can find one or two who are will be ecstatic, so clearly I'm right, and in any case, I'm not on this earth specifically to please anyone. I know it will be very hard for everyone to change their bundle constraints, and to use the new refactored bundling of EMF, but it's for the long term good of EMF, progress is king, and nothing you say will sway me from my course. And don't bother making any technical arguments because firstly, I'll throw those back it into your face and scream "progress and the committers are king," and secondly, I'll just argue that I'll find some way eventually, hopefully, probably, maybe, to address them all, so please be patient and expect and accept my half baked ideas in M2. I'm so looking forward to your feedback (which of course I can ignore as I see fit) as you help me find the flaws in my designs. And by the way, the more noise you annoyed adopters generate, the more I'll argue that my whole approach of simply inflecting all this upon you without warning and without recourse has worked a charm. Isn't that all simply charming? Everything I said above is 100% counter to what I've grown to expect from other projects at Eclipse and what I feel is expected (and yes required) of me personally as a steward for widely adopted technology. So I'm definitely not pleased by your provocative commentary. I suggest you be careful with that approach because in open source what goes around comes around. More constructively, I suggest you move this to a branch and provide branch builds for adopters; it's seems you've not made that decision yet. Technically you'll need to consider carefully the poor interaction between arrays and generics. To make to make sure it all pans out and to understand the cost of doing so, you ought to refactor the entire platform's code base, Equinox, JDT, and PDE included, to accommodate this new design. After all, how else can you assess whether the new approach really makes a significant portion of the code significantly better? While you're at it, you might decide to finally get rid of all your existing raw type warnings. If that all sounds daunting, consider carefully what you're asking of your adopter community. Regards, EdI'm just back from my vacation and did not really planned to take part in this discussion, because a sort of technical consensus seems to be achieved already, but I find your scenario really important, because it might happen. Some day, for some project. Maybe not necessarily for EMF, because of personally you being the guardian. It is good for EMF to have you as a commiter, but it is definitely not good to have nearly only you as a contributor [1]. EMF without you would instantly enter maintenance mode (aka "die"). Monolithic contributor group being significantly smaller than the adopter group resembles tyranny very much, and it is all OK (or even desired) as long as the dictator is the enlightened and active one (which happily is true for EMF), but, in general, larger consumer-contributor base would ensure that no sudden and drastic changes happen to the project. For this reason I find your scenario rather supporting John's statement: "[...] I have a clearly defined obligation to enable the project's contributors to make progress in the direction they want to take." :-). Of course it's up to a project to define how open it would like to be, but I believe one of the biggest sins of *any* development to limit project scope strict to dependency APIs, without caring for the entire stack (and providing 100% binary compatibility makes you a partner in the crime ;-), although some balance is necessary, of course). [1] http://dash.eclipse.org/dash/commits/web-app/summary.cgi?login=y&year=x&top=modeling&project=modeling.emf.emf&company=individual