Re: [modeling-pmc] [cross-project-issues-dev] Notifcation to let QVTO co

["GAUFILLET, Pierre" <pierre.GAUFILLET@xxxxxxxxxx>]

Hello everybody!

My point was not to propose changing the frequency of the release trains, but to underline the fact that our current means perhaps do not fit well with our objectives.

I join what Mike said: Polarsys aims for sure at providing SRx with x>=3 when needed on the very long term, but that is only one part of its goal. Organizing and sharing the integration/innovation efforts of the main branch of a selection of components is actually another part of it.

To Miles: thanks for these interesting data about your build effort. The time you have spent is consistent with our experience on TOPCASED.

------
Pierre

-----Message d'origine-----
De : modeling-pmc-bounces@xxxxxxxxxxx [mailto:modeling-pmc-bounces@xxxxxxxxxxx] De la part de Mike Milinkovich
Envoyé : mardi 3 janvier 2012 19:38
À : 'PMC members mailing list'
Objet : Re: [modeling-pmc] [cross-project-issues-dev] Notifcation to let QVTO contribute to Juno

I agree with Ed's point that the idea of shipping a release train annually
is unlikely to change. At least not any time soon. Across the entire Eclipse
community we need to balance the requirements of highly innovative, rapidly
changing projects, and very stable, mostly "done" projects. Polarsys and
Long Term Support will add long term and very long term release support to
the mix, but I don't think that takes away the need for an annual release
train.

Where Polarsys could, perhaps, really help out is to provide the stable
source of funding for builds and maintenance that Ed mentions.

Best wishes to all for a great 2012!

> -----Original Message-----
> From: modeling-pmc-bounces@xxxxxxxxxxx [mailto:modeling-pmc-
> bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
> Sent: January-03-12 11:23 AM
> To: PMC members mailing list
> Subject: Re: [modeling-pmc] [cross-project-issues-dev] Notifcation to let
> QVTO contribute to Juno
> 
> 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.
> 
> 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.
> There's no avoiding that and there's nothing unlikely to be any
possibility of
> telling the train to slow down...
> 
> 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.