Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tools-pmc] Requesting exception for patch feature shipped by Object Teams

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


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]
>>> >>     Indigo repository does not include all the versions of jdt.core
>>> >>
>>> >> [2]
>>> >>     Rules for project patches in the train
>>> >> _______________________________________________
>>> >> tools-pmc mailing list
>>> >> tools-pmc@xxxxxxxxxxx
>>> >>
>>> >
>>> > _______________________________________________
>>> > tools-pmc mailing list
>>> > tools-pmc@xxxxxxxxxxx
>>> >
>>> >
>>> _______________________________________________
>>> tools-pmc mailing list
>>> tools-pmc@xxxxxxxxxxx
>> --
>> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
>> |
>> _______________________________________________
>> tools-pmc mailing list
>> tools-pmc@xxxxxxxxxxx
> --
> Cheers,
> Chris Aniszczyk
> +1 860 839 2465
> _______________________________________________
> tools-pmc mailing list
> tools-pmc@xxxxxxxxxxx
tools-pmc mailing list

Back to the top