|Re: [tools-pmc] Requesting exception for patch feature shipped by Object Teams|
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  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  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  http://wiki.eclipse.org/OTIndigo  (against p2): https://bugs.eclipse.org/316702 "More feedback on what's installing"
--- End Message ---
Back to the top