On Jan 3, 2012, at 11:34 AM, Ed Willink wrote:
It should somehow be possible to just reuse old builds when nothing has changed.
Yes, I think so too. Though I can see the arguments for having a unified current build, I'm not sure why older P2 compatible builds cannot be used. Unfortunately Buckminster insists on the ridiculous narrow version ranges for EMF that guarantee that nothing pragmatic works.
If this was the case, there would be no need for QVTo to rejoin the chain. The Indigo build would do for Juno.
I'm not sure it would, because EMF has -- presumably legitimate -- dependencies on 4.x, which is only available on Juno. And as only 2.8 is available on Juno, that means making a number of changes in the builds for *build-time* dependencies on 4.x. NB Until 2 days ago there was no Juno GEF build, and the world didn't end. Regards Ed Willink On 03/01/2012 19:18, Miles Parker wrote: On Jan 3, 2012, at 8:22 AM, Ed Merks wrote:
Pierre,
The train's schedule is not likely to change and it's something I think is a key aspect to Eclipse's overall success. How much change ends up on the train each year is another issue. In theory one should be able feed older content into the train, at least if all the frameworks on which you rely remain binary compatible from release to release. That is certainly something EMF aims for each time, but things like UML and OCL seem to evolve more rapidly and not necessarily as cleanly, and that affects their downstream clients. And of course it's certainly reasonable to feed nothing into the maintenance releases if there's no time and no high demand for fixes.
In my experience, even the maintenance releases are not without issues. (I couldn't get into SR1 for example, just no time to update and fix some little things as I've had a lot of other priorities.) For small projects with limited resources, just managing the various issues that come up is a major challenge.* The issue is that downstream clients essentially pay the price for incompatibilities or glitches that affect builds, not to mention the normal changes that just need some tweaking. Which means digging into a lot of other projects internals that we're just not familiar with and trying to insert ourselves into other project's cultures and tempo. This is sort of backwards, as the M3 types are generally those projects that have the least resources. OTOH, we also tend to have the fewest users, so arguably that is less important to the eco-system as a whole. Hopefully Polarsys will help -- this is the first I'd heard of it but it sounds promising.
*I'd estimate that I've spent ~160 hours / year (4 person-weeks) on maintaining the builds in the last calendar year, with easily 240 hours in prior years. And I want to note that issues are not only with Modeling dependencies -- they can be with any Eclipse project. For me for example that means BIRT and all of the attendant web stuff that that brings in, GEF3D, XPand and XText, even though I don't actually use most of that.
Just an observation / winge.. not really a complaint per se. But I would note for people that might complain about small projects taking up valuable Eclipse Foundation resources, perhaps we make up for it in that we've providing testing and QA for non-Eclipse hosted downstream build consumers. :)
Builds themselves remain a huge expensive and complex overhead, but supporting timely fixes for industrial users is also a key to inspiring confidence. There just needs to be consistent, long term, reliable funding for producing builds and for responding to changes in base frameworks.
Amen.
Regards,
Ed
On 02/01/2012 10:57 AM, GAUFILLET, Pierre wrote:
Hi everybody!
This is one of the reasons why Polarsys& LTS IWG are being set up: taking care of / helping to organize the maintenance aspect (even if innovation is not forgotten) of Open Source Components.
As said in the conversation, it is especially true for stable frameworks like EMF, on which most if not all Eclipse modelling features are based, but which does not always bring direct value to industrial users.
Maybe also that releasing trains once (and three times with the Service Releases) a year is too frequent given the available means.
---
Pierre
-----Message d'origine-----
De : modeling-pmc-bounces@xxxxxxxxxxx [mailto:modeling-pmc-bounces@xxxxxxxxxxx] De la part de Ed Merks
Envoyé : dimanche 18 décembre 2011 10:08
À : PMC members mailing list
Objet : Re: [modeling-pmc] [cross-project-issues-dev] Notifcation to let QVTO contribute to Juno
Ed,
Yes, one of the fundamental problems is that people will pay for new
things, and individuals will fall all over themselves to be new
committers on projects, but people often don't want to pay to maintain
old things and often don't spend so much effort supporting old things.
We're a shiny-and-new-oriented culture that looks to fashionable change
for keeping it all exciting and new. Better that old things be
forgotten or maybe we can recycle them to ease our conscience...
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4720 - Release Date: 01/03/12
_______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/modeling-pmc
|
