Re: [tools-pmc] Requesting exception for patch feature shipped by Object

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi Doug and listeners,

Thanks for commenting.

On Tuesday, November 16, 2010 04:44:43 pm Doug Schaefer wrote:
> I have to agree with Gunnar and Dani Megert. You can't patch another
> project on the train without their approval.

While I don't have an official approval, there has always been very 
close cooperation, to the extent that the JDT/Core team recently
invited me to help them as a new committer in their team.
I will certainly discuss issues with the colleagues from JDT/Core.

> You are essentially
> forking the JDT, which is fine on it's own, but the JDT team owns the
> JDT that's on the train

I think we all agree that the JDT must have full control over what's
installed when a user selects "Eclipse Java Development Tools".
This is not affected by our patch feature (unless via a bug in the aggregator).

>  and need to own the patch.

I'm not 100% sure what you are saying by this.
Is that a legal statement? A statement that the JDT/Core must retain
the option to publish patches without interfering with other patches?
A statement about responsibility and blame assignment?
I'd love to answer more specifically, once I better understand what you mean.

> And at the end of
> the day you need to work with the JDT team to provide a mechanism so
> that there isn't a patch/fork,

I have reasons to believe that this is impossible. Should I elaborate?

> or at least a patch that the JDT team is happy with.

I will discuss this.

> Or find another way to release Object Teams that
> doesn't involve the train.

Is there a specific guarantee associated with the train that you
see violated by the fact of using a patch feature?

Interestingly, nobody spoke up when I initially announced this on 
various channels (incl. the attached mail).

If possible, could you point out where you see that users of the train could
be negatively impacted by this specific patch? Note, that in this request
I'm not asking for general permission that patching should be fine in all
cases, but I'd like to demonstrate that our particular patch does no harm.

thanks for your time,
Stephan

--- Begin Message ---

• From: Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>
• Date: Sun, 3 Oct 2010 14:44:42 +0200
• User-agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; )

Hi Tools PMC, 
hi Mentors,

I would like the Object Teams Project to join Indigo during the M3 frame.

It appears that we will set a precedent in some regards, so I'm asking you
what should be the suitable forum for discussion.

I've created a wiki page [1] for our preparation for Indigo, where some
issues are marked red - they might call for some discussion, specifically:

"API
 o todo: document non-standard usage 
    o usage of internal classes 
    o aspect binding to bundle 
      o decapsulation 
      o interception 
    o patch feature for org.eclipse.jdt.core ..."

Technically, both the usage of a patch feature and the OT/Equinox
technology create non-standard dependencies/relationships.
We want to be as open as possible, which is why I also filed bug 316702 [2]
which aims at a very general solution, not just for Object Teams.
I'd love to see a lively discussion on that bug, BTW.

On a more formal notion, which of these issues will require approval
by some body of the Eclipse community, and which body would that be?

thanks,
Stephan


[1] http://wiki.eclipse.org/OTIndigo
[2] (against p2): https://bugs.eclipse.org/316702 
     "More feedback on what's installing"

--- End Message ---