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,
Ed
On 30/08/2013 8:52 PM, John Arthorne wrote:
I hope everyone realizes I was being a bit provocative just to prove a
point (I think I learned this from you Doug ;) Committers are
generally pretty reasonable and will always try hard to keep adopters
satisfied. Adopters are obviously very important to any project and
their views should always be considered. I'm hopeful in this
particular case we'll find a middle ground that allows progress to be
made without further unnecessary disruption for consumers. My main
goal was refuting the assertion that "adopters have to be pleased" and
that committers are not permitted to make disruptive changes if
adopters don't like it. The final decision on direction for any
Eclipse project will be made by its own contributors.
John
From: Doug Schaefer <[email protected]>
To: Cross project issues <[email protected]>,
Date: 08/30/2013 01:43 PM
Subject: Re: [cross-project-issues-dev] JFace Generics
Sent by: [email protected]
------------------------------------------------------------------------
John, you are right by the letter of the law. But I think the point
is, if the contributors want the platform to be successful, they have
to be sensitive to the needs of adopters. They're who make a platform
successful. If they aren't then who are they building the platform
for? (And as much as we don't like to talk about it, I really hate the
real answer to that question).
For Eclipse to be a successful platform going forward that has to
change. Or, yeah, we could just fork it. A lot of us who build
products on it already have. But no one is suggesting that's the right
thing to do in the long run. Or are we?
Doug.
*From: *John Arthorne <[email protected]_
<mailto:[email protected]>>*
Reply-To: *Cross project issues
<[email protected]_
<mailto:[email protected]>>*
Date: *Friday, 30 August, 2013 11:05 AM*
To: *Cross project issues <[email protected]_
<mailto:[email protected]>>*
Subject: *Re: [cross-project-issues-dev] JFace Generics
Eike Stepper <[email protected]_ <mailto:[email protected]>> wrote
on 08/30/2013 05:59:14 AM:
> >The project is it's contributors not it's API.
>
> That sounds a little as if Eclipse projects are only playgrounds for
> "the cool kids". I think a project is successful if
> what it produces (including the APIs) is successful, i.e. widely
> adopted. The adopters have to be pleased, not the contributors.
You're definitely wrong about this part. Committers and contributors
will always have the final say. An adopter that is not contributing
has *absolutely* no say in the direction of the project. This is not
my opinion - this is clearly defined in the Eclipse charter, by-laws,
and dev process, and is the same for most other open source projects.
The historic platform contributors (e.g., IBM), placed extremely high
value on stability and compatibility. If those committers are gone and
a new set of committers arrives that values innovation and change over
stability and compatibility, then that's the direction the project
will take. If adopters don't like that direction, then they need to
get involved to influence the direction, fork the project, etc. Even
as a PMC member I have no right to value the needs of adopters over
contributors - quite the opposite I have a clearly defined obligation
to enable the project's contributors to make progress in the direction
they want to take.
John_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
