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
<dschaefer@xxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
08/30/2013 01:43 PM
Subject:
Re:
[cross-project-issues-dev]
JFace Generics
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <John_Arthorne@xxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: Friday, 30 August, 2013 11:05 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] JFace Generics
Eike Stepper <stepper@xxxxxxxxxx>
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|