Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmf-dev] GMF Tooling in Indigo?

Thanks Artem for this clarification and your incredible job in the last few years.
You are one of the most brilliant software Java Architect in the decade :-)

An important point which has not been discussed is the time needed to fully understand the GMF framework.
If I remember well we asked some of us very good developer to look at GMF in 2006 and they needed 3 months to become beginners, 6 to be able to create projects and 12 to be able to fully understand the architecture.
Having just one man for few months is not therefore sufficient because the learning curve is longer than the provided budget.
I think Mr Istria that more than automated test a vision of the architecture is more important today in order to have a real project and not just a yearly upgrades.

What is really stupid today is that when we visit customers they considered GMF  as a competitor of ISV therefore companies buy less software thinking they can do the job by them self.
Actually companies can do the job using any Eclipse open source project and it would certainly be stupid for them not to consider this alternative.
Our ISV  problem we faced is that I remember a huge contract which could have been signed by Omondo and finally the customer have decided to select GMF and develop by himself.
We lost 50% of our yearly revenue because of that decision. Few years later this GMF project failed but we have unfortunately never recovered our lost revenue.
This big company has also never contributed to any GMF bugs and was just waiting fixes coming from the Eclipse community because they have sold a dreaming free software vision to their management.

We have today two fantastic modeling GMF and EMF projects and a no desire from sales/marketing ISV management to  invest because of software revenue drop.
Customers are still waiting out of box open source paid by magic fairies sponsors and ISV refuse anymore to pay the bill.
We hope that this non sense vision will stop but have few hopes today :-(
We would like to be able to get budget to sponsor these two open source projects in a win to win relation which seems to be impossible today because companies refuse to sponsor ISV.
This is my penny to this discussion which is unfortunately a loose to loose relation for open source projects and ISV today !!
WE (e.g Open source and ISV) need to be united or sooner or later only cloud applications will  remain and we will be all out of business.
Unemployment will keep growing among developers etc...
 
Vlad Varnica
Omondo


Mickael Istria wrote:
Hi Artem,

Is this page up-to-date: http://eclipse.org/indigo/planning/SimultaneousReleaseOverview.php?action=""> ? If yes, that's quite encouraging for keeping GMF-Tooling in Indigo! Except the continuous monitoring, there seem to be only a few things to do.
The first thing would be to choose an offset, announce it on the cross-project list, and update the dev.eclipse.org/org.eclipse.indigo.build/gmp-gmf-tooling.b3aggrcon to remove the enabled="false" flag. By the way, do you know why this flag was set up?

Regards,

Le 07/12/2010 04:58, Artem Tikhomirov a écrit :
Hi Mickael,

 I didn't mean to enumerate each and every activity one needs to accomplish, moreover, one of the point I made is that I do not know (nor find too much fun to know) all of them. These were just to show there're certain routine activities even for projects already on the train, and they require one's dedication. By dedication here I mean proactive, rather than reactive steps (latter is when one sits and waits until someone else tells him there's something wrong and only then does something about it).

 Nevertheless, given there's strong interest in keeping the project on the train, I think the further discussion is fruitless, we just need to do our best ;)

Best wishes,
Artem Tikhomirov

On Fri, Dec 3, 2010 at 10:02 AM, Mickael Istria <mickael.istria@xxxxxxxxxxxxxx> wrote:
Ok,

I don't really see any huge difficulty here that would require a big amount of time. Please take a look at my comments below and tell me if I am wrong.

First of all, there's a requirement to track cross-project dev list (and be ready to react to relevant issues; and being able to tell relevant from irrelevant, which requires certain dedication to the cross-project topic).
While there is no problem with the GMF-Tooling build, there shouldn't be a lot of issues to resolve?

  Another very important aspect is to ensure the project "does no harm" - i.e. one has to download (install from p2 repo) various installations, check they are installed correctly, run different scenarios, make sure actions are there, capabilities are reasonable, editors do not conflict and a lot of other things. And this is an activity one has to do few times during the release cycle.
Let's say that this task is about taking an Indigo IDE, installing a platform such as the one I currently use (PDE, JDT, SVN, GMF...), and run some model generation to check whether everything is fine. It's about one hour for each test, and test at least for every milestone. Is is OK?

One more example - from time to time, there are new plug-ins get added, and one needs to make sure they follow guidelines, get a copy of about file, etc.With few accountable developers this might not be a big issue, nevertheless, the sad reality is one needs to pay attention to (and control) all these bloody details.
When a new plugin is contributed, someone must check all the necessary stuff (NLS, license, about, api...). But there is no additional work for already existing plugins, is there? We can think that there won't be a lot of new bundles added. Also, do you know a way to monitor all the checkins in the codebase (subscribe to a mailing or something like that)? That would be very helpful to save time.

Regards,
--

Mickael Istria
R&D Engineer

BonitaSoft - Open your processes
email : mickael.istria@xxxxxxxxxxxxxx

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.

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


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


--

Mickael Istria
R&D Engineer

BonitaSoft - Open your processes
email : mickael.istria@xxxxxxxxxxxxxx

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.


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


Back to the top