Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [emf-dev] EMF 2.3.3 GA?

Nick,

So, rather than saying "the way XSD is produced/consumed" I should perhaps have said "how XSD is produced and _where_ XSD is consumed"; as an MDT component, XSD updates should be hosted on the MDT update site, not the EMF one.

I agree that a package containing EMF and XSD is useful and it will continue to be useful. But producers/consumers of XSD should be able to create/obtain new releases of XSD independently of EMF releases.

I'll take a look at how much work it will be (has anyone actually assessed it?) to build XSD independently of EMF and come back to you if I have any questions/concerns.

Thanks,

Kenn Hussey
Program Manager, Modeling and Design Solutions

Embarcadero Technologies, Inc. | www.embarcadero.com 
82 Peter Street, Second Floor | Toronto, ON  M5V 2G5
Kenn.Hussey@xxxxxxxxxxxxxxx
Office: 416-593-1585 x9296 Mobile: 613-301-9105

-----Original Message-----
From: emf-dev-bounces@xxxxxxxxxxx [mailto:emf-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
Sent: Saturday, November 08, 2008 2:17 PM
To: Eclipse Modelling Framework
Subject: Re: [emf-dev] EMF 2.3.3 GA?

Didn't mean it to be harsh, only that I've pushed for two years to pass 
on your desire to the EMF PMC and your fellow committers, and no one has 
as yet jumped at the idea -- the spirit (releng) was willing, but the 
flesh (committers to do the test/example splitting) was weak. :)

I tried again this summer when we started the EMF 2.5 plan, hit the same 
response for the third time, and dropped it.

I agree, having XSD build independent of EMF would change the way it's 
produced. Would it really change the way it's consumed?

The only thing that would be noticeably different would be that XSD 
updates would be on the MDT update site instead of the EMF one; but for 
people who only download zips, EPP bundles, or update from the 
coordinated release update sites, there'll be no difference. And since 
to use XSD you need EMF, you'll get the updates either way. (Not to 
mention the fact that if you've already got XSD installed, an its 
features point to the EMF site, you won't get an MDT-site-located update 
until you update by hand to a new feature w/ the updated <update> tag 
pointing at the new URL.

I recently asked if we should change the packaging for EMF and XSD, and 
was told that people still want the aggregate "EMF & XSD All-in-one" zip 
[1], so we'd in theory still need to create that even if XSD was built 
separately, but producing an "EMF & XSD all in one" feature, akin to 
what Christian has for aggregating QTV into a single feature for Europa 
and Ganymede.

Bottom line -- I don't see anything different in the way XSD would be 
consumed. Have I missed something?

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=240223#c4

Nick

Kenn Hussey wrote:
> Wow. That was a little harsh. I'm happy to see such spirit!
>
> Believe me, I have MUCH less spare time than you seem to think. I'm only making observations because I care. If nobody really cared about the maintenance branch, it shouldn't have been created in the first place...
>
> The reasons I dared make an observation about XSD being built/released separately from EMF are
>
> 1. For the first couple of MDT releases I was promised it would happen ("not this release but maybe next release").
>
> 2. XSD is a subproject of MDT, not EMF.
>
> 3. A branch of EMF (core) should not be required to fix a bug in XSD.
>
> 4. Discussions about XSD releases should take place on the XSD and/or MDT mailing list instead of (or at least in addition to) the EMF list.
>
> To me, this has less to do with Eclipse policies/procedures and more about the way XSD is produced/consumed... and I'm willing (as seemingly one of the few that care) to begin the work to split the two. Thanks for the gentle nudge.
>
> Cheers,
>
>
> Kenn Hussey
> Program Manager, Modeling and Design Solutions
>
> Embarcadero Technologies, Inc. | www.embarcadero.com 
> 82 Peter Street, Second Floor | Toronto, ON  M5V 2G5
> Kenn.Hussey@xxxxxxxxxxxxxxx
> Office: 416-593-1585 x9296 Mobile: 613-301-9105
>
>
> -----Original Message-----
> From: emf-dev-bounces@xxxxxxxxxxx [mailto:emf-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
> Sent: Friday, November 07, 2008 1:45 PM
> To: Eclipse Modelling Framework
> Subject: Re: [emf-dev] EMF 2.3.3 GA?
>
> I disagree. It just shows a maintenance branch that no one really cares 
> about, and an untended bit of releng work on my part that should have 
> been done this summer.
>
> --
>
> As to your off-topic request, wanting to do XSD 2.5 builds independent 
> of EMF 2.5 is one thing. Supporting maintenance branches from 2 years 
> ago is another kettle of funky fish, and I'd be VERY happy if the 
> official Modeling Project policy on maintenance aligned with what the 
> Eclipse Platform does: you get from June to February for maintenance; 
> after that, maintenance is closed so that the focus can be on new 
> development in the HEAD branch.
>
> If you have a compelling customer need for why XSD has to be built 
> independent of EMF -- despite its pedigree of being a cross-project 
> build since its 1.x days, when the EMF project was in Tools and the XSD 
> project was in Technology -- please share it.
>
> Then, since you appear to be bubbling over with spare time, please begin 
> the work required to split the XSD tests & examples from the EMF ones so 
> that there are no criss-crossing dependencies between the projects. XSD 
> can depend on EMF, or EMF on XSD, but for separate builds they cannot 
> both depend on each other. I'm not |33+ enough, or free-time-equipped 
> enough, to be able to do that work; nor do I see a compelling technical 
> or consumer reason for it. (Eclipse policies are meant to empower 
> customers, developers, and Member companies, not to introduce extra 
> administrivia for its own sake.)
>
> When that's done, let me know and I'll re-evaluate the proposal to split 
> EMF and XSD into two builds.
>
> 'Till then,
>
> Nick
>
>
> Kenn Hussey wrote:
>   
>> This is case in point for the ability to do XSD builds/releases independently of EMF.
>>
>> Kenn Hussey
>> Program Manager, Modeling and Design Solutions
>>
>> Embarcadero Technologies, Inc. | www.embarcadero.com 
>> 82 Peter Street, Second Floor | Toronto, ON  M5V 2G5
>> Kenn.Hussey@xxxxxxxxxxxxxxx
>> Office: 416-593-1585 x9296 Mobile: 613-301-9105
>>
>>
>> -----Original Message-----
>> From: emf-dev-bounces@xxxxxxxxxxx [mailto:emf-dev-bounces@xxxxxxxxxxx] On Behalf Of Nick Boldt
>> Sent: Friday, November 07, 2008 1:28 PM
>> To: Eclipse Modelling Framework
>> Subject: [emf-dev] EMF 2.3.3 GA?
>>
>> Guys,
>>
>> Back on 2008/03/12, we released an M build for EMF/XSD 2.3.3 to fix a 
>> single XSD bug. It's 8 months later and I guess no one has really been 
>> beating down the door for this fix, since we never released it in an R 
>> build.
>>
>> http://www.eclipse.org/modeling/mdt/news/relnotes.php?project=xsd&version=2.3.x
>>
>> Is it time to do one simply to make the fix available to people who only 
>> watch the update sites, and to end the maintenance of EMF 2.3.x?
>>
>> I'd say yes -- any objections to spinning a final 2.3.3 GA next week?
>>
>> Nick
>>
>>   
>>     
>
>   

-- 
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash CBI

_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev


Back to the top