Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] +1 to Miles view on the situation, reply to Ed Willinks remarks on status of GMF Tooling and OCL

Hi Philipp

Great news that GMF Tooling has been rescued; I thought it was still one man.

In one sense, OCL is not short of support; it has two active committers.

I put in perhaps 0.75 man years work/year as a result of only working part-time for my employer. Sometimes my employer funds conference attendance, but my attendance at the OCL workshop and at EclipseCon Europe was self-funded during annual leave. Some support for my personal expenses at least would be welcome. (Not just for me, but for all committers that lack corporate support; most notably the former Borland employees who haven't been able to attend EclipseCon for years.)

Adolfo (Open Canarias) puts in perhaps 0.1 man years/year and is a tremendous help in saving me worry about most of the excitements of Hudson builds.

The indirect cost of my commitment to OCL is that the rate of apparent progress on QVTd is minute, though behind the scenes the new Xtext-based and OCL-based tooling for OCL will facilitate a rapid realisation of QVTd and perhaps progress for QVTo and ALF too.

    Regards

        Ed Willink

On 19/12/2011 08:05, Philipp W. Kutter | Montages AG wrote:
Ed, Miles:

First a simple +1 on what Miles wrote.

It is exactly what I think, he expressed exactly the main problems.

Miles: the message is not at all negative, and each point should be followed up carefully in my opinion. Hope your flue gets better soon.


Two  remarks to what has been mentioned by Ed on GMF Tooling and OCL:

  - "For shoestring projects such as EMF core, UML2, OCL or GMF, users must consider whether they can risk dependency on almost a single individual."
    This statement is not true for GMF Tooling at all.

    GMF Tooling has a team of three FTEs working on it since a few month, and the sponsor, Avaloq Evolution AG, the leading Swiss Banking Software vendor plans to fund this team for the coming years. With Avaloq we created a mechanism for large enterprises to pay in a direct, formalized, way, taking into consideration their strategic needs and the needs of the people doing the development. The formalization is of course done as an ECore model ;-)

   We plan to use the GMF Tooling project to show that Miles thesis is correct, and to create so many advantages for the sponsor, that it becomes an example for a "disincentive for free-riding".


  - If the OCL project is short of real support, this is (or should be, in absence of workarounds...) a risk for at least 4 projects: QVTO, GMF Tooling, Acceleo, and UML2, who all are based on OCL! Of course, one can start to repeat the error done in GMF Tooling with Exapnd: to freeze a version. But this was an error, and it should not be repeated. The component leads of QVTO, GMF Tooling, Acceleo and UML2 should get together, describe the status of this dependencies, the possible workarounds they created, and requirements they would have to OCL to let it be a solid basis for their projects. I hope I'll find time to push this, but would welcome anyone else to take the initiative, to collect this list!



Today's Topics:

   1. Modeling dependencies (Miles Parker)


----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Dec 2011 13:47:02 -0800
From: Miles Parker <milesparker@xxxxxxxxx>
To: PMC members mailing list <modeling-pmc@xxxxxxxxxxx>,	Cross project
	issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: [cross-project-issues-dev] Modeling dependencies
Message-ID: <00ABF535-CF9F-4FF8-A5EB-B30D1AF744D8@xxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1


This all brings up a few thoughts.

1. For a mature project, what about providing an option for a project to declare a sealed build, and provide a permanent P2 site for future release trains? If the project does not have excessive dependencies on platform (this switch to e4 is something of a special case) or other changing components, then I can see the point that it _is_ kind of a formality to require the project to be on every subsequent release train. Why do we require Eclipse internal dependencies to all be on the release train when obviously we don't require that of external dependencies? :) As builds seem to be a constantly moving target, we're creating a lot of churn for projects that don't have functional changes. Perhaps there could be a process to support this?

2. We should continue to support development of model-based support for understanding these dependencies based on artifacts, not institutional memory, or as in this case no memory at all. Wayne and David and the Cloudsmith guys among others have really pushed things forward on this in lots of different ways, so +1 to that. With b3 process at least we require an email contact for a project to join the aggregator. :) And tools like the compliance reports are a huge improvement.

3. I must say that I see a deeper challenge than project organization and tracking; there is a basic problem of $$, and we should be clear about that. There is a reason that the websites, etc.. aren't up to date; it's because there isn't any support for it. It's great when individuals like Nicolas step up to literally put their money where there mouth is, but as Ed W. points out, it shouldn't come to that. I think it's important for us to talk openly about the greatest challenge for the modeling project. Modeling projects are building some incredibly cool technology -- industry leading in many cases -- and what's amazing about that is that much of it happens in a co-adaptive bottom-up way. As a complexity science guy, I think that's really cool. But we do have a significant problem with incentive structures. This is a problem for a diverse ecology that doesn't come up for the Firefoxes (how to make that plural?) of the world. 

Many of the core projects -- including EMF -- are supported by a very small group of people. And the people that are working on these projects often have to be very creative to come up with the money to support the projects and all to frequently end up working on them with little or no support at all. Given that these projects support a very broad set of technologies that create an enormous amount of value( and profit) for many enterprises, there is something wrong with that picture. When people find themselves scraping together 1k (+1 to Francis, I'm reminded) to fix a build dependency for other projects on which thousands of users and many companies depend, there is something very wrong with that picture. Some of the larger participants in the eco-system have gone out of their way to support these efforts -- I think we all know who they are; Itemis, Obeo, Ohloh.. -- and it's very much appreciated. But there are a lot of upstream consumers -- especially non-software tools v

e
 ndors -- that have the resources to support on-going development and don't. And then there is the user base; we're all open source developers, so we understand that we can't offer something for free and expect people to pay, but there is currently no mechanism for people to pay *even if they wanted to*. And there is no disincentive for free-riding. Perhaps some more thought could be given to how to address that in a positive way.

So that's my Saturday afternoon at home w/ stomach flu mini-rant. ;D I'm hoping it's not too negative but I think I'm mostly stating a pretty common frustration. OTOH, I have to say that the diversity and innovation in modeling could not have happened with a top-down approach and if the price of having a more bottom-up approach is difficulty in finding support for the project as a whole, than I'd take that trade-off.

cheers,

Miles


On Dec 17, 2011, at 5:34 AM, Ed Willink wrote:

Hi Philipp

The current system works.

For projects supported by major companies such as itemis or Obeo there is no problem. But when a major company such as Borland (QVTo, GMF) or IBM (EMF, UML2, OCL) retrenches or when a residual individual retires we get these panics and a solution is found.

A solution cannot be found until then because anyone genuinely keen to contribute is probably already on board. The panic is needed to stimulate companies to place a real value on 'free' software.

For shoestring projects such as EMF core, UML2, OCL or GMF, users must consider whether they can risk dependency on almost a single individual.

In the case of OCL, when the original IBM team retired, the resulting panic stimulated so much enthusiasm for rescue that the competing offers had to be mediated. Sadly little of this enthusiasm supports ongoing activities.

[I don't see the system improving much unless Eclipse employs its committers and companies make significant contributions to pay the corresponding salaries.]

   Regards

       Ed Willink
On 17/12/2011 12:55, Philipp W. Kutter | Montages AG wrote:
Perfect!

I wish you all Happy Holidays!

It is a great feeling that the OMG standards based projects are going strong and will all be on the Juno releasse train!

If there is a doubt in the future that any of these projects will not be on the release train, simply because nobody is there to fulfill the formalities of the project or the details of the newest build project, we can always help. As Miles mentions, this may need to add some people of other modeling projects to the committer teams.

Could the modeling PMC send out a mail and ask the modeling teams
a) who sees a risk they will not be on the release train, simply because of lack to fulfill the formalities and the build project
b) who would volunteer to help out for other projects.

As well, it might be a good policy, to have a backup plan, if a component lead is either not available, or ill, or otherwise gone in the very moment he needs to promote the project. Immagine an important project, with lots of dependencies does not release, simply because the component lead is in-available. The costs can be huge.

Thanks for the great work of the Eclipse Foundation,
Philipp



On 17.12.2011 01:44, Ed Willink wrote:
Hi Miles

There is no need to panic. In view of some delicacies, considerable correspondence has happened off-list.

Nicolas Rouquette has now resolved both the problem and the delicacies by his open email to these lists that you must have missed.

Thanks to Nicolas' generosity, QVTo will be available in Juno supported by the existing QVTo team.

The only process exception that may be needed is tolerance of a one or two day tardiness in setting the contribution flag.

I'm sure we all wish to thank Nicolas for being so helpful to Eclipse. Thank you Nicolas.

   Regards

       Ed Willink


On 16/12/2011 23:57, Miles Parker wrote:
Philipp,

You should identify QVTO leadership, which means M2M nee MMT, so that they can make the change in their portal. (This of course would have to be in the middle of a project renaming!) That would require all of MMT to join train, I don't know if it's possible to do this more fine-grained than that. PMC can flip the bit for MMT, but I don't think we should do that unless/until we have support from project leadership or at least active committers if they exist. Comments?

William, I'm cc'ing you because I note that you have contact with Fr?d?ric Jouault who is project lead..? Perhaps you could pass on his email to Phillip.

FWLIW, I'll support any process exception if needed/possible once that is sorted out. Phillip, thanks for taking the initiative on this. Why don't you report back to PMC list as you make progress?

cheers,

Miles



On Dec 16, 2011, at 12:29 PM, Philipp W. Kutter | Montages AG wrote:

Dear PMC.

I would like to notify that QVTO should flip the bit for Juno. I hope
this has already been done by the QVTO team itself.

In the unexpected case, that the current QVTO team will not have time to
trigger the newest ways of building the QVTO, I can guarantee
development time from the GMF Tolling component lead Michael Golubev,
who knows well the newest ways of building.

As well, there is a cummulative patch from Nicolas Rouquette, which we
would love to integrate in the new build, if the QVTO team has not yet done.

The GMF Tooling project has a strong dependency on QVTO and would fail
in their efforts to do their releases in the future, if QVTO build fails.

As well, the sponsor of the 3 FTE working on GMF tooling requests that
GMF Tooling as well as the project it depends on are remaining in Juno,
so we have a multiyear 3 FTE sponsorship at risk, if this does not happen.


We want to do all to support the current team to do the Juno builds.
There is a budget from Nicolas Rouquette and us, which would offer $
2000 to who ever in the QVTO team wants to do this. And we support with
development time from the 3 FTE working on GMF Tooling, if needed.

Please forward this message as well to the QVTO team, whom I do not know
personally. Please assure them of our full support. I did not find a mailing list for them.

And, as today is the deadline, please accept this notification, even if
formally it comes from the wrong side.

Regards,
Philipp


_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1890 / Virus Database: 2108/4684 - Release Date: 12/16/11




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1890 / Virus Database: 2108/4685 - Release Date: 12/16/11


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

------------------------------

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


End of cross-project-issues-dev Digest, Vol 71, Issue 63
********************************************************



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1890 / Virus Database: 2108/4688 - Release Date: 12/18/11



Back to the top