Re: [tools-pmc] [objectteams-dev] Requesting exception for patch feature

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Just to make sure my position is clear. I have no problem with the
fork. As Ed has experienced with EMF and as we often discuss in the
CDT community about the Platform, it is necessary at times. All I'm
objecting to is putting it on the train without the approval of the
project you are forking, in this case JDT.

There are other ways to get releases to users. The train has it's
flaws, and this is probably one of them. You're best to avoid it with
your circumstance anyway.

Doug.

On Wed, Nov 17, 2010 at 8:41 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
> 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
>>
>>
>
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
>