[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pmf-dev] Basic rules of PMF and eclipse talks
- From: yves.yang@xxxxxxxxxxx
- Date: Tue, 15 Dec 2009 09:00:54 -0800
- Delivered-to: firstname.lastname@example.org
- User-agent: SquirrelMail/1.4.19
> Yves, in the case of your way to read the proposal is the one that
> understand :
> Does it mean that the initial list was exhaustive ?
> Does it means that new solution/technologies will be de facto excluded ?
> Does it means that we need to create a new eclipse project for the same
> purpose : UI modeling ?
It is said clearly that the project can be extended. But to extend the
scope and the content, we need to passe by PMC and community.
I propose we organize a Bof in eclipsecon with PMC members and all others.
You can ask them directly the questions. And make this kind of decision
together with PMC. Is it reasonable?
> 2009/12/15 <yves.yang@xxxxxxxxxxx>
>> > In general, projects are restricted from including things outside
>> > scope. But I don't think the things Olivier are bringing up are
>> > obviously outside the scope. Therefore, Yves, you need to explain
>> > why some things are considered OK to include in the project, and other
>> > things are not.
>> > So in the case of PMF, why is model-to-text transformations a natural
>> > part of the project, and model-to-model transformations not? In both
>> > cases, the point is ending up with artifacts (code, models, supporting
>> > files) that can be executed or interpreted by a runtime.
>> This template "JET" is in the proposal as a demonstrator. The proposal
>> passed by project review. It is accepted by PMC and by the Community.
>> change must be proved in the same way.
>> Best regards
>> Yves YANG
>> > Hallvard
>> > _______________________________________________
>> > pmf-dev mailing list
>> > pmf-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/pmf-dev
>> pmf-dev mailing list
> pmf-dev mailing list