Fast is good, and I'm all for making things
as easy as possible. However, there are certain
openness and transparency requirements mandated
by the EDP. Section 4.6 states, in part:
"The initial project leadership is appointed and
approved in the creation review. Subsequently,
additional Project Leads must be elected by the
project's Committers and approved by the
Project's PMC and the EMO(ED)."
Further:
"In the unlikely event that a member of the
Project leadership becomes disruptive to the
process or ceases to contribute for an extended
period, the member may be removed by the
unanimous vote of the remaining Project Leads
(if there are at least two other Project Leads),
or unanimous vote of the Project's PMC."
HTH,
Wayne
On 10/06/2011 11:14 AM, Ed Merks wrote:
Mickael,
Yes, I like a fast approach too. I'm just not
sure the EMO will approve it. We'll need them
to comment about what's a suitable process in
this somewhat dysfunctional situation. It it
might well be faster to start a thread "Proposed
New GMF Tooling Leader" and get all the active
committers to +1 the proposal. Then it's
absolutely clear that the will of the committers
is demonstrated and recorded.
Regards,
Ed
On 06/10/2011 5:23 AM, Mickael Istria wrote:
Ed,
I think it will make things more complex/long.
Changing project lead of GMF Tooling is already
something that should have been done lots of
monthes ago, and that has always been delayed
for several reasons.
Then I am in favor of a faster approach: Anthony
makes Michael Golubev project lead (with both
Anthony's +1 and mine, the vote is OK), and when
it is done, we'll probably think about removing
Artem committer status on GMF Tooling.
Does it sound "legally" good enough?
On 05/10/2011 19:55, Ed Merks wrote:
Anthony,
Could the committers have an election? Perhaps
anyone who doesn't vote can be decommiterized...
On 05/10/2011 10:04 AM, Anthony Hunter wrote:
Hi Team,
I have not heard from Artem that he wants to
lead GMF Tooling anymore nor have I heard from
anyone speaking on his behalf.
Michael Golubev will be the new GMF Tooling
project lead. I will work with the modeling PMC
and the EMO to make the change.
Cheers...
Anthony
From: Anthony Hunter/Ottawa/IBM@IBMCA
To: "GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx> ,
Date: 09/13/2011 09:35 AM
Subject: [gmf-dev] GMF-Tooling project
lead
Sent by:
gmf-dev-bounces@xxxxxxxxxxx
Hi Team,
" Anthony, could you please approve upgrading
the version of GMF-T to 3.0 for the Juno
release? "
Well, I suppose the project lead would approve
first. I am thinking Artem is not around again.
We are still waiting for his approval for the
release review. I am thinking it may be in the
best interest of the project for Artem to step
down as project lead and we make Michael Golubev
the project lead. To be fair, we need to give
the community a bit of time to reply back any
concerns.
Michael, is it great that you now have a team of
three of GMF Tooling. I have no opinion either
way if GMF Tooling is 3.0 in Juno. I would
proceed with the project plan and allow the
community to comment.
Cheers...
Anthony
From: Michael Golubev
<golubev@xxxxxxxxxxxx>
To: "GMF Project developer discussions."
<gmf-dev@xxxxxxxxxxx> ,
Date: 09/13/2011 08:06 AM
Subject: [gmf-dev] GMF-Tooling in Juno
-- can we plan for 3.0 (major) release
this year
Sent by:
gmf-dev-bounces@xxxxxxxxxxx
Hello,
While we are waiting for a release review for
GMF-T 2.4, I would invite everyone to put
efforts into the planning for next release.
I am glad to confirm that for this year we have
got a sponsorship from Avaloq Evolution AG,
which is willing to support team of 3 developers
working specifically on GMF-Tooling.
I am creating the draft proposal of the project
plan now, will commit it shortly and post the
main proposed topics here for discussion.
However, it is already clear for me that in
order to deliver the new features we need Juno
release to be a major one, thus 3.0 instead of
2.x.
The reason is, we will have to change models
significantly, and we will not be able to
provide automatic backward compatibility with
the models created for 2.4.x
(we will of course follow the transition
procedure from the past of GMF-T and will
develop 'Migrate Model' actions to support
migration of existing models).
Anthony, could you please approve upgrading the
version of GMF-T to 3.0 for the Juno release?
Also I am not sure how we can add into the
Bugzilla the new set of milestones (no matter
whether it is 3.0 M2, M3... or 2.5 M2, M3...).
If someone know how to do that please advice me,
it would help with pushing the project plan
proposal into Bugzilla.
Regards,
Michael
--
Michael "Borlander" Golubev
Eclipse Committer (GMF, UML2Tools)
at Montages Think Tank, Prague, Czech Republic
Montages AG
Stampfenbachstr. 48, CH-8006 Zürich
tel:
+41 44
260 75 57
mob:
+420 602
483 463
_______________________________________________
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
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
--
Mickael Istria
R&D Engineer, Eclipse Plug-in RCP
Developer
PetalsLink - Open Source SOA
My blog -
My Tweets
