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

[David M Williams <david_williams@xxxxxxxxxx>]

I agree with Doug. We need to find another
way to help the Object Team project. 

I think the principle of a project  (JDT
in this case) owning their namespace is sacrosanct as is the principle
that committers in a project control their own project. 

I'll probably write some more in bug
330312 once I proof read my initial
thoughts, but it seems clear and obvious to me that no one in Eclipse can
"reuse" a namespace that  has already been assigned from
the Eclipse Foundation. Thus, I do not support the PMC asking the Planning
Council for any sort of exception (for release train,  or even a release).


My apologies to the ObjectTeam project,
if we did not review your
project proposal closely enough.
But even re-reading it now, there's a lot of ways to interpret "The
current OT/J compiler is a source-level branch of the Eclipse Compiler
for Java" so not sure I would have ever caught it by reading. 

I hope we can find some (easy) alternatives
for you. Is there a bug open where some changes could be made to JDT to
allow you to reuse their bundle as is? If that is not feasible, I fear
the only alternative is to rename your compiler so it has its own namespace.


I'm glad this issue has come up now.
I think as Eclipse gets larger and more complicated, this issue of conflicting
namespaces would have come up sooner or later, but as Eclipse gets larger
and more complicated, that seems all the more reason to have clear namespace
ownership. 

Thank you, 






From:      
 Doug Schaefer <cdtdoug@xxxxxxxxx>
To:      
 Tools PMC mailing list
<tools-pmc@xxxxxxxxxxx>
Date:      
 11/16/2010 01:11 PM
Subject:    
   Re: [tools-pmc]
Requesting exception for patch feature shipped by Object Teams
Sent by:    
   tools-pmc-bounces@xxxxxxxxxxx

---

The issue at hand is whether the Tools PMC will bring
this to the
planning council. I am not going to vote in favor of this motion
unless the JDT folk approve. If someone else on the PMC feels strongly
about it they can and I'll simply abstain.

I do know that if someone else was trying to patch the CDT on the
train without the CDT community's approval, I'd be steamed. I don't
think it's healthy for the greater Eclipse community to open that
precedent.

Doug.

On Tue, Nov 16, 2010 at 12:43 PM, Chris Aniszczyk <caniszczyk@xxxxxxxxx>
wrote:
> Here are my two cents:
>
> I'm fine with OT forking JDT as they have a use case for it. We should
> grant them an exemption for this time around with the EXPECTATION
that
> they would work with the JDT to fix any issues by the next release
> (Stephan has even become a JDT committer which is great). This can
> serve as motivation for projects to fix issues as they wouldn't be
> allowed on the train next time around.
>
> In terms of p2, to ensure that no one installs the JDT "fork"
by
> accident... we would explicitly hide the feature when we organize
the
> content (this is relatively easy to do).
>
> On Tue, Nov 16, 2010 at 11:33 AM, Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
wrote:
>> I'm also curious as to what would happen if two people wanted
to patch the
>> same project? Or, if I installed the OT (and thus the patched
JDT came
>> along), and then JDT released a critical fix of their own? Would
that patch
>> be applied?
>> cheers,
>> ian
>>
>> On Tue, Nov 16, 2010 at 9:28 AM, Doug Schaefer <cdtdoug@xxxxxxxxx>
wrote:
>>>
>>> I think it's just too easy to get the patched version without
users
>>> knowing about it. That's why I firmly believe the owners of
the
>>> org.eclipse.jdt namespace need to approve any patches into
that
>>> namespace that come on the train.
>>>
>>> Doug.
>>>
>>> On Tue, Nov 16, 2010 at 11:46 AM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
>>> wrote:
>>> > My 2c.  We must be sure that when someone goes to
the train repo and
>>> > says (directly or indirectly) "I want JDT",
they get the unpatched JDT.  If
>>> > they choose (directly or indirectly) to install OT and
OT needs a patch,
>>> > great, but they should not get it "for free".
>>> >
>>> > If there are bugs in p2/b3/... that prevent the above
from being true
>>> > then they need to be fixed or the train repos must contain
patches from the
>>> > JDT team (in this case) that they intend all users to
have.
>>> >
>>> > Jeff
>>> > On 2010-11-16, at 2:34 PM, Stephan Herrmann wrote:
>>> >
>>> >> Dear Tools PMC,
>>> >> (Cc: our Mentors)
>>> >>
>>> >> Bug 330288 [1], which is actually a technical bug
in the b3 aggregator
>>> >> has triggered a discussion in bug 330312 [2], which
may or may not
>>> >> significantly influence the future of the Object
Teams project.
>>> >>
>>> >> I've actively tried to trigger this discussion for
a long time and I
>>> >> appreciate
>>> >> that it is happening now.
>>> >> However, if the rules proposed by Gunnar will be
enforced in the near
>>> >> future, perhaps as a pre-requisiste for participating
in the release
>>> >> train,
>>> >> this would potentially rule out our (Object Teams)
participation in the
>>> >> train.
>>> >>
>>> >> Therefor, and in order to keep special case considerations
out off that
>>> >> discussion, I precautionarily request an exception
from those future
>>> >> rules.
>>> >> If relevant I will ask you (the Tools PMC) to forward
this request to
>>> >> the
>>> >> Planning Council.
>>> >>
>>> >> I believe I have sufficient arguments for justifying
this exception.
>>> >> Please let me know, where and how I should communicate
these arguments.
>>> >>
>>> >> Thanks for considering,
>>> >> Stephan
>>> >>
>>> >>
>>> >> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=330288
>>> >>     Indigo repository does not include
all the versions of jdt.core
>>> >>
>>> >> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=330312
>>> >>     Rules for project patches in the train
>>> >> _______________________________________________
>>> >> tools-pmc mailing list
>>> >> tools-pmc@xxxxxxxxxxx
>>> >> https://dev.eclipse.org/mailman/listinfo/tools-pmc
>>> >
>>> > _______________________________________________
>>> > tools-pmc mailing list
>>> > tools-pmc@xxxxxxxxxxx
>>> > https://dev.eclipse.org/mailman/listinfo/tools-pmc
>>> >
>>> _______________________________________________
>>> tools-pmc mailing list
>>> tools-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/tools-pmc
>>
>>
>>
>> --
>> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
>> http://eclipsesource.com
| http://twitter.com/eclipsesource
>>
>> _______________________________________________
>> tools-pmc mailing list
>> tools-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/tools-pmc
>>
>>
>
>
>
> --
> Cheers,
>
> Chris Aniszczyk
> http://aniszczyk.org
> +1 860 839 2465
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tools-pmc
>
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc