[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tools-pmc] [objectteams-dev] Requesting exception for patch feature shipped by Object Teams
|
Stephan,
Comments below.
Stephan Herrmann wrote:
Hi, me again,
As comments on bug 330312 mostly converge on strict rules,
I must renew my request. Some of yesterday's comments
mean BIG PANIC for the Object Teams project. For that reason
it is difficult for me to keep emotions out off this, but I'll try.
Yesterday I thought you were premature about asking for an exception,
but as the comments continue to come in, I can certainly understand that
you have cause for concern. It's interesting that you raised this issue
months ago without a peep from anyone...
Some comments say that some gurus should help the Object
Teams project to find a better architecture that achieves the
same without doing bad things. Please understand that after
more than 7 years of intensively studying the alternatives and
engineering a solution that finally is well maintainable, I am not
very confident that anybody will just wipe away the conflict after
glancing at the issue for a little while. Do you have any
suggestions how this idea could be made real?
Of course outsiders always tend to think there are simple solutions to
complex problems. It always feels a little insulting, but one must
accept that it takes everyone a while to fully appreciate the details...
Some comments say, that the rules should not only be applied
to the release train but to any release. This raises the question
whether being at Eclipse is actually a viable option for the Object
Teams project. Until yesterday I thought we're overdue for
graduation, today we're nowhere.
I see your emotions are trickling through. It's ironic that emotions
make people so uncomfortable when ultimately they're the force that
drives us all. I suppose we're way more comfortable with the illusion
of rationality...
David said, the fact that the JDT is open-source does not mean
it's OK to fork that code, because this may have bad impact on
the JDT and the community. So let's weigh the alternatives:
(a) the fork happens within the community and we all join forces
for minimizing any risks involved. Or:
(b) the fork is forced to move away from Eclipse.org and both
sides just mind their own business.
What's the effect on collaboration?
What's the message sent to the public?
As Jeff mentioned on the bug, part of this is about enabling
innovation (thanks Jeff).
I can imagine folks trying to fork EMF. I'm sure there'd be an
emotional reaction on my part. I'd want to work closely with folks to
avoid that. Though in the end, things like EMF for GWT and to a far
lesser extend EMF for RAP really do end up forking the code...
In this one question I'd like to generalize (following my point
in https://bugs.eclipse.org/330312#c12 ):
To some degree the Object Teams project represents a significant
part of the software engineering research of the past decade:
Advances in programming language design based on Java.
There are *countless* languages in this field, *many* of which would
deserve a JDT-qualitity IDE. Where are they? Will any be attracted
to Eclipse if a pioneer is forced to withdraw? (Yes, I know there is
one brave exception: AspectJ, which had the luck of support by IBM).
What's the message Eclipse sends to academia?
It's a bad message. We should try to resolve all problems. Failing
that we should agree to disagree, when necessary, and then mitigate any
damage that might cause.
Regarding the risks I can only invite you to specifically discuss
the situation of Object Teams and the JDT/Core. I insist in saying
that things look different if you put aside global principles and
really look at the specifics (after all this is a request for an
exception).
I agree. Rules are great as a general guide, but the devil is in the
details and reason must prevail in each specific situation.
Please let's define a controlled experiment, in which the damage
incurred (if any) and the benefits produced will be evaluated so that
we all learn together and maybe draft a map of some uncharted
waters.
I'm sure if we all avoid digging in our heels, we can arrive at
something that balances the benefits and the risks...
Lot's more to say but I'll shut up for now.
may I hope for some courage?
Hope is always the last thing to die. In the end, things like the
success of the release train depend more on good will and cooperation
than on rigid rules and strict enforcement. That latter generally don't
produce the former...
Stephan
