Home » Archived » Tigerstripe » Why the EMO Approved the Tigerstripe Creation Review
| Why the EMO Approved the Tigerstripe Creation Review [message #5288] |
Sat, 29 December 2007 20:21  |
 Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
This post is in response to the four -1 comments on bug 213493
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493) and Ed Merk's
blog entry
( http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html).
The goal of this essay is to explain why the EMO determined that these
-1s are not justified
( http://www.eclipse.org/projects/dev_process/development_proc ess.php#6_3_Reviews)
and thus has approved the Tigerstripe project creation.
1. _________ THE EMO IS NEUTRAL _________
Before explaining the EMO's reasoning, I need to respond to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c8 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c14 wherein the EMO
is accused of being "both an involved participant in the discussion as
well as the arbiter in the final decision making". Would this be true,
it would be a problem, however upon careful review of the public record
(in the newsgroup
http://www.eclipse.org/newsportal/thread.php?group=eclipse.t echnology.tigerstripe
and on the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493 and
on Ed's blog
http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html),
I found only eight statements by the EMO:
1.1. "Welcome"
http://www.eclipse.org/newsportal/article.php?id=1&group =eclipse.technology.tigerstripe#1
1.2. A much shorter version of this longer essay explaining why the EMO
discounts the concerns raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c2
1.3. A summary of the votes so far
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c3
1.4. A retraction of the summary of the votes so far
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c6
1.5. A clarification of the process
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c10
1.6. A thank you https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c11
1.7. An explanation of the EMO's role
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c13
1.8. Another explanation of the EMO's role and reasoning
http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html#c4904527224415955081
None of these statements are even close to being "an involved
participant in the discussion". Thus, on the face of the evidence, I
maintain that the EMO (me) has maintained a careful position of
neutrality and final decision authority as outlined in the processes and
bylaws.
2. _________ THE EMO'S POSITION STATEMENT _________
Next, a few words about the EMO's position on new project creation, not
just this project, but for all projects:
2.1. The EMO can only approve a new project creation if the project fits
within the purposes of the Eclipse Foundation
( http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf).
2.2. There is no single "official modeling story" or "single MDD vision"
from the Eclipse Foundation. No person or group at Eclipse is in charge
of determining what is, or is not, an Eclipse modeling story. The same
goes for any other technology.
2.3. There is no single location for "modeling" projects just like there
is no single location of "widget" projects or "new language IDE"
projects. E.g., SWT has widgets, Nebula has widgets, eRCP has widgets,
DLTK creates new IDEs, IMP creates new IDEs, and CDT creates new IDEs, etc.
2.4. "Competing" projects is not a problem. It's not the best state
(better would be cooperation), but it's also not a problem. We've had
competing projects before and we will again. We believe that the larger
Eclipse community will vote with their feet and choose the best solutions.
2.5. The EMO believes that "code talks, B.S. walks" and that the best
way for a project to prove itself is to operate and deliver as an open
source project. Projects that are open will attract more attention,
contribution and users (e.g. EMF); projects that are closed with wither
and die (e.g., ALF).
The main issue that raises concern for the EMO is when a new proposal is
not clearly interested in becoming an open source projects with open,
transparent, and inclusive participation.
3. _________ THE EXPLICIT NEGATIVE VOTES _________
The comments associated with the explicit negative votes are:
3.1. The current approach will fragment the community
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
3.2. The current approach will marginalize Tigerstripe
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
3.3. Technology from M2T and M2M should be used
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
3.4. A slow migration from an existing code base to an undetermined goal
is far from ideal https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
3.5. Hard to explain to users which modeling technology to use
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7
3.6. A modeling thing that is not in the modeling top-level
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
3.7. Doubts about the project team and their willingness to use existing
Eclipse modeling technology
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
3.8. Must not duplicate existing modeling projects
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
Unfortunately, Marcelo's -1
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c17) did not
include a justification, so it will be addressed later.
Addressing each of these explicit statements in order:
3.1. For reasons 2.2 and 2.4, the EMO does not consider this a problem.
We believe that different expert groups (such as the Modeling PMC) will
provide different distros and solutions that appeal to different user
and adopter communities. Eclipse is not in, nor can it be in, the
position of providing a single solution to modeling.
3.2 For reason 2.5, that's a problem for the project and the PMC. The
EMO believes that projects should be given a chance to succeed or fail.
3.3. While this is a good point, for reason 2.4, the EMO doesn't see
this as a blocking issue. We also note that the Tigerstripe team has
said that they will migrate to existing Eclipse modeling technologies
( http://www.eclipse.org/newsportal/article.php?id=29&grou p=eclipse.technology.tigerstripe#29,
http://www.eclipse.org/newsportal/article.php?id=28&grou p=eclipse.technology.tigerstripe#28,
http://www.eclipse.org/newsportal/article.php?id=34&grou p=eclipse.technology.tigerstripe#34,
http://www.eclipse.org/newsportal/article.php?id=6&group =eclipse.technology.tigerstripe#6,
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c18).
3.4. The EMO agrees that this is not ideal, but "not ideal" is not
grounds for rejecting a new project. We have many new projects that
arrive with an existing code base and evolve from there. Aperi, Babel,
EPF, IMP, and Mayanstall are recent examples.
3.5. For reason 2.2, the EMO does not accept this as a reason to reject
a project.
3.6. For reason 2.3, the EMO does not accept this as a reason to reject
a project. Additionally, the Tigerstripe team did approach the Modeling
PMC first and that PMC rejected them
( http://www.eclipse.org/newsportal/article.php?id=5&group =eclipse.technology.tigerstripe#5,
http://www.eclipse.org/newsportal/article.php?id=18&grou p=eclipse.technology.tigerstripe#18,
http://www.eclipse.org/newsportal/article.php?id=14&grou p=eclipse.technology.tigerstripe#14).
3.7. See answer to 3.3. The EMO believes that the Tigerstripe team is
serious about migrating – their public statements say that they are. The
EMO cannot find any public information to justify this reason for a veto.
3.8. For reason 2.4, the EMO does not see this as a problem.
4. _________ THE ARGUMENTS AGAINST NOT STATED IN VETOS _________
I went through all the discussions and gathered all the negative
comments. In this section, I explain why the EMO does not consider these
comments to be blockers for a project creation.
4.1. In
http://www.eclipse.org/newsportal/article.php?id=2&group =eclipse.technology.tigerstripe#2
it was stated that Tigerstripe is inferior technology. Similar questions
were raised in
http://www.eclipse.org/newsportal/article.php?id=15&grou p=eclipse.technology.tigerstripe#15,
http://www.eclipse.org/newsportal/article.php?id=27&grou p=eclipse.technology.tigerstripe#27
and
http://www.eclipse.org/newsportal/article.php?id=23&grou p=eclipse.technology.tigerstripe#23.
For reason 2.5, the EMO does not consider inferior technology to be a
disqualifying issue. Additionally, in
http://www.eclipse.org/newsportal/article.php?id=5&group =eclipse.technology.tigerstripe#5
the Tigerstripe team disputes the "its all inferior" claim.
4.2. In
http://www.eclipse.org/newsportal/article.php?id=26&grou p=eclipse.technology.tigerstripe#26
and
http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html
it was stated that Tigerstripe is a brand name which gives it a
threatening appearance. The EMO Executive Director and Legal staff have
resolved the Tigerstripe naming issue (it is being transferred to the
Eclipse Foundation). It seems then that this complaint is that because
Tigerstripe is well known it will threaten the existing Eclipse modeling
projects that are less well known. (Sorry, but the argument wasn't
clearly stated.) The Tigerstripe team replied
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c18) that this was
the best way to avoid losing their existing community while adding on a
new Eclipse community. The EMO does not consider this a problem: either
Tigerstripe will help the Eclipse brand or Tigerstripe will fade away
and be replaced by existing Eclipse modeling sub-brands. Either outcome
is good.
4.3. In
http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html
there is concern that the proposal does describe all the extension
points. The EMO's position is that "yes, it would be nice if all the
extension points were known apriori, but we've never required that level
of detail from new projects before".
4.4. In
http://www.eclipse.org/newsportal/article.php?id=18&grou p=eclipse.technology.tigerstripe#18,
http://www.eclipse.org/newsportal/article.php?id=14&grou p=eclipse.technology.tigerstripe#14
and
http://www.eclipse.org/newsportal/article.php?id=36&grou p=eclipse.technology.tigerstripe#36
existing expert Eclipse committers point out that the Tigerstripe
migration plan will require migrating their users at least twice and
that such migration and API refactorings are very hard to do. This is a
serious concern, perhaps the most legitimate critique of the proposal I
found. However, the solution proposed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c17 (that the
project go to Sourceforge and come back later) is so anti- the open
culture we want to encourage at Eclipse that I was almost speechless.
Better was the comment in
http://www.eclipse.org/newsportal/article.php?id=15&grou p=eclipse.technology.tigerstripe#15
that the integration was not early enough in the plan. The EMO felt that
the Tigerstripe team's responses (that they want to migrate and that
they know it is hard and they look forward to advice on the issue)
showed the correct intentions and attitude.
4.5. Another solid critique was in
http://www.eclipse.org/newsportal/article.php?id=33&grou p=eclipse.technology.tigerstripe#33,
a statement that the writer would prefer to the see the Tigerstripe
pieces provided as components rather than a single unified tool. This is
also a strong criticism of the proposal because Eclipse is about
"extensible frameworks and exemplary tools", not about "free tools". The
EMO expects the Tigerstripe team to move in this direction.
4.6. And finally, the question in
http://www.eclipse.org/newsportal/article.php?id=11&grou p=eclipse.technology.tigerstripe#11
of "how will this benefit the Eclipse community?". This is answered by
http://www.eclipse.org/newsportal/article.php?id=13&grou p=eclipse.technology.tigerstripe#13,
http://www.eclipse.org/newsportal/article.php?id=39&grou p=eclipse.technology.tigerstripe#39
and
http://www.eclipse.org/newsportal/article.php?id=37&grou p=eclipse.technology.tigerstripe#37,
statements of support from Eclipse committers and Tigerstripe community
members.
5. _________ THUS THE EMO HAS APPROVED TIGERSTRIPE _________
The EMO appreciates the discussion that has happened around this new
project. We believe that the discussion has clarified the proposal
(narrowed the scope), improved the project plan (clarified the goals),
and focused the project team (they understand more about what it means
to be part of Eclipse). All of this is good.
The EMO does not, however, believe that any of the discussion has
provided a valid reason to disqualify Tigerstripe from being an Eclipse
project. Thus the EMO has approved and provisioned the Tigerstripe project.
|
|
|
| Re: Why the EMO Approved the Tigerstripe Creation Review [message #5355 is a reply to message #5288] |
Sat, 29 December 2007 20:55  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------080006080008000307080008
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Bjorn,
Thanks for being so incredibly conscientious to address all the concerns
in great detail.
And thanks also to Eric for directly addressing my biggest concern by
way of sharing his initial prototype design for a Tigerstripe DSL! Here
it is represented as a class diagram.
Bjorn Freeman-Benson wrote:
> This post is in response to the four -1 comments on bug 213493
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493) and Ed Merk's
> blog entry
> ( http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html).
> The goal of this essay is to explain why the EMO determined that these
> -1s are not justified
> ( http://www.eclipse.org/projects/dev_process/development_proc ess.php#6_3_Reviews)
> and thus has approved the Tigerstripe project creation.
>
> 1. _________ THE EMO IS NEUTRAL _________
> Before explaining the EMO's reasoning, I need to respond to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c8 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c14 wherein the
> EMO is accused of being "both an involved participant in the
> discussion as well as the arbiter in the final decision making". Would
> this be true, it would be a problem, however upon careful review of
> the public record (in the newsgroup
> http://www.eclipse.org/newsportal/thread.php?group=eclipse.t echnology.tigerstripe
> and on the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493
> and on Ed's blog
> http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html),
> I found only eight statements by the EMO:
>
> 1.1. "Welcome"
> http://www.eclipse.org/newsportal/article.php?id=1&group =eclipse.technology.tigerstripe#1
>
> 1.2. A much shorter version of this longer essay explaining why the
> EMO discounts the concerns raised
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c2
> 1.3. A summary of the votes so far
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c3
> 1.4. A retraction of the summary of the votes so far
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c6
> 1.5. A clarification of the process
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c10
> 1.6. A thank you https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c11
> 1.7. An explanation of the EMO's role
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c13
> 1.8. Another explanation of the EMO's role and reasoning
> http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html#c4904527224415955081
>
>
> None of these statements are even close to being "an involved
> participant in the discussion". Thus, on the face of the evidence, I
> maintain that the EMO (me) has maintained a careful position of
> neutrality and final decision authority as outlined in the processes
> and bylaws.
>
> 2. _________ THE EMO'S POSITION STATEMENT _________
> Next, a few words about the EMO's position on new project creation,
> not just this project, but for all projects:
>
> 2.1. The EMO can only approve a new project creation if the project
> fits within the purposes of the Eclipse Foundation
> ( http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf).
>
>
> 2.2. There is no single "official modeling story" or "single MDD
> vision" from the Eclipse Foundation. No person or group at Eclipse is
> in charge of determining what is, or is not, an Eclipse modeling
> story. The same goes for any other technology.
>
> 2.3. There is no single location for "modeling" projects just like
> there is no single location of "widget" projects or "new language IDE"
> projects. E.g., SWT has widgets, Nebula has widgets, eRCP has widgets,
> DLTK creates new IDEs, IMP creates new IDEs, and CDT creates new IDEs,
> etc.
>
> 2.4. "Competing" projects is not a problem. It's not the best state
> (better would be cooperation), but it's also not a problem. We've had
> competing projects before and we will again. We believe that the
> larger Eclipse community will vote with their feet and choose the best
> solutions.
>
> 2.5. The EMO believes that "code talks, B.S. walks" and that the best
> way for a project to prove itself is to operate and deliver as an open
> source project. Projects that are open will attract more attention,
> contribution and users (e.g. EMF); projects that are closed with
> wither and die (e.g., ALF).
>
> The main issue that raises concern for the EMO is when a new proposal
> is not clearly interested in becoming an open source projects with
> open, transparent, and inclusive participation.
>
> 3. _________ THE EXPLICIT NEGATIVE VOTES _________
> The comments associated with the explicit negative votes are:
>
> 3.1. The current approach will fragment the community
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.2. The current approach will marginalize Tigerstripe
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.3. Technology from M2T and M2M should be used
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.4. A slow migration from an existing code base to an undetermined
> goal is far from ideal
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.5. Hard to explain to users which modeling technology to use
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7
>
> 3.6. A modeling thing that is not in the modeling top-level
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> 3.7. Doubts about the project team and their willingness to use
> existing Eclipse modeling technology
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> 3.8. Must not duplicate existing modeling projects
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> Unfortunately, Marcelo's -1
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c17) did not
> include a justification, so it will be addressed later.
>
> Addressing each of these explicit statements in order:
>
> 3.1. For reasons 2.2 and 2.4, the EMO does not consider this a
> problem. We believe that different expert groups (such as the Modeling
> PMC) will provide different distros and solutions that appeal to
> different user and adopter communities. Eclipse is not in, nor can it
> be in, the position of providing a single solution to modeling.
>
> 3.2 For reason 2.5, that's a problem for the project and the PMC. The
> EMO believes that projects should be given a chance to succeed or fail.
>
> 3.3. While this is a good point, for reason 2.4, the EMO doesn't see
> this as a blocking issue. We also note that the Tigerstripe team has
> said that they will migrate to existing Eclipse modeling technologies
> ( http://www.eclipse.org/newsportal/article.php?id=29&grou p=eclipse.technology.tigerstripe#29,
> http://www.eclipse.org/newsportal/article.php?id=28&grou p=eclipse.technology.tigerstripe#28,
> http://www.eclipse.org/newsportal/article.php?id=34&grou p=eclipse.technology.tigerstripe#34,
> http://www.eclipse.org/newsportal/article.php?id=6&group =eclipse.technology.tigerstripe#6,
> and https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c18).
>
> 3.4. The EMO agrees that this is not ideal, but "not ideal" is not
> grounds for rejecting a new project. We have many new projects that
> arrive with an existing code base and evolve from there. Aperi, Babel,
> EPF, IMP, and Mayanstall are recent examples.
>
> 3.5. For reason 2.2, the EMO does not accept this as a reason to
> reject a project.
>
> 3.6. For reason 2.3, the EMO does not accept this as a reason to
> reject a project. Additionally, the Tigerstripe team did approach the
> Modeling PMC first and that PMC rejected them
> ( http://www.eclipse.org/newsportal/article.php?id=5&group =eclipse.technology.tigerstripe#5,
> http://www.eclipse.org/newsportal/article.php?id=18&grou p=eclipse.technology.tigerstripe#18,
> http://www.eclipse.org/newsportal/article.php?id=14&grou p=eclipse.technology.tigerstripe#14).
>
>
> 3.7. See answer to 3.3. The EMO believes that the Tigerstripe team is
> serious about migrating
|
|
| |
| Re: Why the EMO Approved the Tigerstripe Creation Review [message #561907 is a reply to message #5288] |
Sat, 29 December 2007 20:55 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080006080008000307080008
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Bjorn,
Thanks for being so incredibly conscientious to address all the concerns
in great detail.
And thanks also to Eric for directly addressing my biggest concern by
way of sharing his initial prototype design for a Tigerstripe DSL! Here
it is represented as a class diagram.
Bjorn Freeman-Benson wrote:
> This post is in response to the four -1 comments on bug 213493
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493) and Ed Merk's
> blog entry
> ( http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html).
> The goal of this essay is to explain why the EMO determined that these
> -1s are not justified
> ( http://www.eclipse.org/projects/dev_process/development_proc ess.php#6_3_Reviews)
> and thus has approved the Tigerstripe project creation.
>
> 1. _________ THE EMO IS NEUTRAL _________
> Before explaining the EMO's reasoning, I need to respond to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c8 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c14 wherein the
> EMO is accused of being "both an involved participant in the
> discussion as well as the arbiter in the final decision making". Would
> this be true, it would be a problem, however upon careful review of
> the public record (in the newsgroup
> http://www.eclipse.org/newsportal/thread.php?group=eclipse.t echnology.tigerstripe
> and on the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493
> and on Ed's blog
> http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html),
> I found only eight statements by the EMO:
>
> 1.1. "Welcome"
> http://www.eclipse.org/newsportal/article.php?id=1&group =eclipse.technology.tigerstripe#1
>
> 1.2. A much shorter version of this longer essay explaining why the
> EMO discounts the concerns raised
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c2
> 1.3. A summary of the votes so far
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c3
> 1.4. A retraction of the summary of the votes so far
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c6
> 1.5. A clarification of the process
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c10
> 1.6. A thank you https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c11
> 1.7. An explanation of the EMO's role
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c13
> 1.8. Another explanation of the EMO's role and reasoning
> http://ed-merks.blogspot.com/2007/12/can-tiger-change-its-st ripes.html#c4904527224415955081
>
>
> None of these statements are even close to being "an involved
> participant in the discussion". Thus, on the face of the evidence, I
> maintain that the EMO (me) has maintained a careful position of
> neutrality and final decision authority as outlined in the processes
> and bylaws.
>
> 2. _________ THE EMO'S POSITION STATEMENT _________
> Next, a few words about the EMO's position on new project creation,
> not just this project, but for all projects:
>
> 2.1. The EMO can only approve a new project creation if the project
> fits within the purposes of the Eclipse Foundation
> ( http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf).
>
>
> 2.2. There is no single "official modeling story" or "single MDD
> vision" from the Eclipse Foundation. No person or group at Eclipse is
> in charge of determining what is, or is not, an Eclipse modeling
> story. The same goes for any other technology.
>
> 2.3. There is no single location for "modeling" projects just like
> there is no single location of "widget" projects or "new language IDE"
> projects. E.g., SWT has widgets, Nebula has widgets, eRCP has widgets,
> DLTK creates new IDEs, IMP creates new IDEs, and CDT creates new IDEs,
> etc.
>
> 2.4. "Competing" projects is not a problem. It's not the best state
> (better would be cooperation), but it's also not a problem. We've had
> competing projects before and we will again. We believe that the
> larger Eclipse community will vote with their feet and choose the best
> solutions.
>
> 2.5. The EMO believes that "code talks, B.S. walks" and that the best
> way for a project to prove itself is to operate and deliver as an open
> source project. Projects that are open will attract more attention,
> contribution and users (e.g. EMF); projects that are closed with
> wither and die (e.g., ALF).
>
> The main issue that raises concern for the EMO is when a new proposal
> is not clearly interested in becoming an open source projects with
> open, transparent, and inclusive participation.
>
> 3. _________ THE EXPLICIT NEGATIVE VOTES _________
> The comments associated with the explicit negative votes are:
>
> 3.1. The current approach will fragment the community
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.2. The current approach will marginalize Tigerstripe
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.3. Technology from M2T and M2M should be used
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.4. A slow migration from an existing code base to an undetermined
> goal is far from ideal
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c1
>
> 3.5. Hard to explain to users which modeling technology to use
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7
>
> 3.6. A modeling thing that is not in the modeling top-level
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c7 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> 3.7. Doubts about the project team and their willingness to use
> existing Eclipse modeling technology
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> 3.8. Must not duplicate existing modeling projects
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c16
>
> Unfortunately, Marcelo's -1
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c17) did not
> include a justification, so it will be addressed later.
>
> Addressing each of these explicit statements in order:
>
> 3.1. For reasons 2.2 and 2.4, the EMO does not consider this a
> problem. We believe that different expert groups (such as the Modeling
> PMC) will provide different distros and solutions that appeal to
> different user and adopter communities. Eclipse is not in, nor can it
> be in, the position of providing a single solution to modeling.
>
> 3.2 For reason 2.5, that's a problem for the project and the PMC. The
> EMO believes that projects should be given a chance to succeed or fail.
>
> 3.3. While this is a good point, for reason 2.4, the EMO doesn't see
> this as a blocking issue. We also note that the Tigerstripe team has
> said that they will migrate to existing Eclipse modeling technologies
> ( http://www.eclipse.org/newsportal/article.php?id=29&grou p=eclipse.technology.tigerstripe#29,
> http://www.eclipse.org/newsportal/article.php?id=28&grou p=eclipse.technology.tigerstripe#28,
> http://www.eclipse.org/newsportal/article.php?id=34&grou p=eclipse.technology.tigerstripe#34,
> http://www.eclipse.org/newsportal/article.php?id=6&group =eclipse.technology.tigerstripe#6,
> and https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493#c18).
>
> 3.4. The EMO agrees that this is not ideal, but "not ideal" is not
> grounds for rejecting a new project. We have many new projects that
> arrive with an existing code base and evolve from there. Aperi, Babel,
> EPF, IMP, and Mayanstall are recent examples.
>
> 3.5. For reason 2.2, the EMO does not accept this as a reason to
> reject a project.
>
> 3.6. For reason 2.3, the EMO does not accept this as a reason to
> reject a project. Additionally, the Tigerstripe team did approach the
> Modeling PMC first and that PMC rejected them
> ( http://www.eclipse.org/newsportal/article.php?id=5&group =eclipse.technology.tigerstripe#5,
> http://www.eclipse.org/newsportal/article.php?id=18&grou p=eclipse.technology.tigerstripe#18,
> http://www.eclipse.org/newsportal/article.php?id=14&grou p=eclipse.technology.tigerstripe#14).
>
>
> 3.7. See answer to 3.3. The EMO believes that the Tigerstripe team is
> serious about migrating
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 21:55:07 GMT 2024
Powered by FUDForum. Page generated in 0.03375 seconds |
] 
Search
Help
Register
Login
Home
