development/pmc_call_notes/2010-06-22.html - www.eclipse.org/webtools - Git at Google

 <?xml version="1.0" encoding="ISO-8859-1" ?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
 <title>WTP PMC Agenda/Minutes for June 22, 2010 Conference Call</title>
 </head>
 <body>
 <h1>WTP PMC Agenda/Minutes for June 22, 2010 Conference Call</h1>
 <h2>Call Info</h2>
 <p>Tollfree in the US: 877-421-0030 <br />
 Alternate: 770-615-1247<br />
 Access code: 173098# <br />
 <a
 	href="http://wiki.eclipse.org/images/f/f6/WTP_status_phone_access.pdf">Full
 list of phone numbers</a><br />
 <br />
 <a
 	href="http://www.timeanddate.com/worldclock/custom.html?cities=224,207,1440,107
 &amp;month=06
 &amp;day=08
 &amp;year=2010
 &amp;hour=11
 &amp;min=0&amp;sec=0&amp;p1=207">Call
 Time: 8:00 AM Pacific; 11:00 AM Eastern; 1500 UTC</a></p>


 <h2>Attendees</h2>
 <h3>PMC Members</h3>
 <ul>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">David
 	Williams: Y</li>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Naci Dai: N</li>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Raghunathan
 	Srinivasan: Y</li>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Neil Hauge:
 	R</li>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Tim deBoer:
 	N</li>
 	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Kaloyan
 	Raev: Y</li>
 </ul>


 <h2>Announcements and General Business</h2>

 <p>Here is a timely antidote on our WTP collaboration reputation
 (what we have accomplished in the industry) ... WTP is often cited as a good
 example of competing companies managing to collaborate in open source.</p>

 <h2>Do we need to "finish" dicussing any general high level points
 from previous weeks?</h2>

 <p>Raghu mentioned it would be good to document more policies. e.g.
 api policy. There was general consensus that can be helpful to set
 expecations ... but, hard to cover all cases, so there's no substitute
 for the policy that agreement must be reached. There is actually quite a
 bit of diversity and seperate specialties in all subprojects ... Common
 Tools may be most extreme case, but is thought to be more a matter of
 degree, than qualitatively different. Tim sited example of Server Toosl
 ... where there's only one primary committer on Tomcat server adapters
 .... but they still discuss issues and come to agreement if there's any
 question on how to maintain compatibility, if a breaking change is
 required, etc. But we agreed it is good to keep discussing how to improve policies,
 processes, documentation, etc.</p>


 <h2 id="movediscussion"">Discuss Konstantin's move request to PMC</h2>
 <p>See <a
 	href="http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg01667.html">original
 message.</a></p>

 <p>See notes from our <a
 	href="http://www.eclipse.org/webtools/development/pmc_call_notes/pmcMeeting.php?meetingDate=2010-06-08#movenotes">meeting
 on 6/8 wtih Konstantin</a></p>


 <p>The PMC was torn and thought this issue deserved lots of
 discussion. The following are issues we discussed in meetings past few
 weeks.</p>

 <p>One reason we were torn, was that believe one of our first tasks
 is to make sure committers are happy and motivated to do great things
 for Eclipse in what ever way they see fit. On the other hand, the
 Eclipse rules of governance are important and need to be followed, and
 they are a critical part of why Eclipse works ... that is, they are part
 of what make it possible for competing companies to collaborate, each
 contributing committers, but with some degree of managing risk and
 protecting investments. Some good reason is required to change
 governance.</p>

 <p>Governance. It was explicit that a large reason behind the
 request to move this code, was a desire to change the governance of the
 code. It was generally agreed that this by itself is not a good reason
 to move code. Eclipse does have a unique system of governance compared
 to other Open Source Communities, and as a PMC we need to support and
 honor and apply those rules of governance as best as we know how. The
 overall, long term success of Eclipse depends on them. For example, when
 committers in a project do not agree on a code change, the status quo
 must prevails. We know that some think WTP is too conservative and
 allows too few changes if the changes might break adopters, but that is
 our philosophy or policy and from our point of view it is working as
 designed to ensure stability and adoption which in turn attracts and
 retains committers. Normally these rules of governance leads to good
 discussions, reviews, compromise, and improved solutions.</p>

 <p>History Note. we know that the whole issue of how to govern,
 package, deliver small platform-like function outside of the literal
 platform is a complex issue, and has a long history of being discussed
 and essentially unsolved (as discussed long ago in <a
        href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=167144">bug
 167144</a>). The WTP Common Tools subproject is our WTP solution to that
 problem, and while in theory there could be other solutions, that's the
 solution we have and have been operating with for many years and many
 releases.</p>

 <p>Move-from versus Move-to project. Moves of
 code/components/projects are often a good, even great, thing at Eclipse
 are fully justifiable, and even encouraged in some cases. In general,
 the PMC would support code moving out of (or into) WTP, if there was a
 good reason and it would be good for Eclipse, overall. Good reasons to
 do such a move, usually, involves moving to join like-minded developers
 or projects to enhance synergy between them. There appears to be none of
 that type of advantage in this case. As an example, one alternative home
 for this code, of &quot;like minded developers&quot; might be in the
 Eclipse Platform, but we know that this was pitched to them, considered,
 but not picked up by them (discussed some in <a
        href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94608">bug
 94608 comment 36</a>, ... there may have been more discussion on some
 mailing lists, but they could not be found after a brief search).</p>
 <p>Technical aspects: Part of the proposal includes a technical
 aspect -- developing a shim layer of v1 code calling out to v2 code so
 WTP code would not need to change what APIs it was calling, but the
 implementation of those APIs would change -- albeit slightly, subtly and
 probably perfectly compatibly, but, still, there is not zero risk for
 that type of change. This technical aspect is problematic for a number
 of reasons. For one reason, this is essentially asking the PMC for
 &quot;preapproval&quot; to make that kind of change to WTP code but it
 would not be appropriate for the PMC to dictate that kind of change on
 WTP committers. That's something that should result from discussions and
 agreements with clients and WTP committers, and they could decide if any
 investment or risk was justified by the potential benefit. Secondly,
 some believe the 1.x code is stable, and if anything should become more
 rock solid, and not risk anything that might result from a move or shim
 layer.</p>

 <p>History note: during the Creation Review of the Incubating
 Faceted Projects Technology Project. there was some concern that the
 proposal was essentially moving established function out of WTP. At that
 time, in the interest of seeing if a separate project would lead to
 broader adoption, the &quot;creation&quot; went forward, but it was made
 explicit in the <a href="http://www.eclipse.org/proposals/fproj/">proposal</a>
 that the committers of WTP would decide if and when WTP ever wanted to
 move to the new framework -- that it could not be forced upon them. For
 historical link, see <a
        href="http://dev.eclipse.org/mhonarc/lists/technology-pmc/msg01144.html">email
 to technology PMC from October, 2008</a>. To further complicate things, to
 put it bluntly, there is no apparent community or adopters of the
 Technology incubating Faceted Project code, even though it has existed
 for 1.5 years, so a skeptical person might say that experiment of a
 separate project has not worked to attract other adopters or an
 independent community or committers, as had been hoped.</p>

 <p>A minor point, just to address explicitly for completeness, one
 reason for the request was that it would be &quot;more efficient&quot;
 to have in one location. The example given at our 6/8 meeting was that
 there could be a common build. But, there doesn't seem to be anything
 substantial that is inefficient or that is preventing progress.</p>

 <p>One reason some PMC members cited for allowing the move was to
 keep the primary committer of this code motivated and interested to keep
 working on it, improving it, and maintaining it. Other's thought that
 the same issue was a reason to leave it where it was ... WTP as whole
 has a vested interest in maintaining the code, seeing it succeed, and to
 some degree, we always have the risk that committers might leave WTP (or
 Eclispe) for a wide variety of reasons (changing careers, companies,
 assignments, interests, etc.) so why not leave it with its only adopting
 project. We could all sympathize with this goal of helping committers
 stay motivated and help them achieve their goals, but did not agree on
 it being a reason to move code or change its governance.</p>

 <p>One of the reason for our concern and care in changing location
 or governance of this particular code is precisely because it has been
 successful in getting widely adopted in WTP -- it is a victim of its own
 success. It is a much used, much appreciated, central core piece of WTP
 and we believe that WTP is its correct home.</p>


 <p>Related information and links:</p>
 <ul>

 	<li><a
 		href="http://www.eclipse.org/projects/dev_process/development_process.php#6_3_7_Move_Review">Dev.
 	Process: Move Review</a></li>
 	<li><a
 		href="http://www.eclipse.org/projects/dev_process/Eclipse_Standard_TopLevel_Charter_v1.0.php">PMC
 	Responsibilities</a></li>

 	<li>See notes and links in our <a
 		href="http://wiki.eclipse.org/WTP_PMC_Policies">WTP PMC Policy
 	page</a>.</li>

 </ul>


 <h2>Handy Links from past meetings</h2>
 <h3>References</h3>
 <ul>


 	<li><a
 		href="http://wiki.eclipse.org/Team_thoughts_on_continuous_improvement_31">Continuous
 	Improvement Notes</a></li>
 	<li><a href="http://www.eclipsecon.org/2010/">EclipseCon 2010</a></li>

 	<li>FYI ... Eclipse Foundation has a relatively new <a
 		href="http://www.eclipse.org/home/categories/index.php?category=enterprise">"enterprise
 	page"</a>.</li>
 	<li><a
 		href="http://www.eclipse.org/projects/project-plan.php?projectid=webtools">WTP
 	3.2 Plans</a></li>
 </ul>
 <h3>Other projects to watch:</h3>
 <ul>
 	<li>WTP @ GSoC 2009. There are two project accepted:
 	<ul>
 		<li>Index search for Java EE metadata. See <a
 			href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=233505">bug
 		233505</a></li>
 		<li>Embed OpenEJB in J2EE Preview server adapter. See <a
 			href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=265952">bug
 		265952</a></li>
 	</ul>
 	</li>
 	<li><a href="http://www.eclipse.org/proposals/sca-tools/">SCA
 	Tools</a></li>
 	<li><a
 		href="http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg01400.html">EMFT
 	Texo project proposal</a></li>
 	<li><a
 		href="http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg06011.html">Maven
 	Integration</a></li>
 </ul>
 <hr />
 <p>Back to <a href="../index_pmc_call_notes.php">meeting list</a>.</p>
 <p>Please send any additions or corrections to David Williams.</p>
 </body>
 </html>
	<?xml version="1.0" encoding="ISO-8859-1" ?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
	<title>WTP PMC Agenda/Minutes for June 22, 2010 Conference Call</title>
	</head>
	<body>
	<h1>WTP PMC Agenda/Minutes for June 22, 2010 Conference Call</h1>
	<h2>Call Info</h2>
	<p>Tollfree in the US: 877-421-0030 <br />
	Alternate: 770-615-1247<br />
	Access code: 173098# <br />
	<a
	href="http://wiki.eclipse.org/images/f/f6/WTP_status_phone_access.pdf">Full
	list of phone numbers</a><br />
	<br />
	<a
	href="http://www.timeanddate.com/worldclock/custom.html?cities=224,207,1440,107
	&month=06
	&day=08
	&year=2010
	&hour=11
	&min=0&sec=0&p1=207">Call
	Time: 8:00 AM Pacific; 11:00 AM Eastern; 1500 UTC</a></p>


	<h2>Attendees</h2>
	<h3>PMC Members</h3>
	<ul>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">David
	Williams: Y</li>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Naci Dai: N</li>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Raghunathan
	Srinivasan: Y</li>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Neil Hauge:
	R</li>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Tim deBoer:
	N</li>
	<li style="margin: 0em 0.2em 0em 0em; padding: 0.0em;">Kaloyan
	Raev: Y</li>
	</ul>


	<h2>Announcements and General Business</h2>

	<p>Here is a timely antidote on our WTP collaboration reputation
	(what we have accomplished in the industry) ... WTP is often cited as a good
	example of competing companies managing to collaborate in open source.</p>

	<h2>Do we need to "finish" dicussing any general high level points
	from previous weeks?</h2>

	<p>Raghu mentioned it would be good to document more policies. e.g.
	api policy. There was general consensus that can be helpful to set
	expecations ... but, hard to cover all cases, so there's no substitute
	for the policy that agreement must be reached. There is actually quite a
	bit of diversity and seperate specialties in all subprojects ... Common
	Tools may be most extreme case, but is thought to be more a matter of
	degree, than qualitatively different. Tim sited example of Server Toosl
	... where there's only one primary committer on Tomcat server adapters
	.... but they still discuss issues and come to agreement if there's any
	question on how to maintain compatibility, if a breaking change is
	required, etc. But we agreed it is good to keep discussing how to improve policies,
	processes, documentation, etc.</p>



	<h2 id="movediscussion"">Discuss Konstantin's move request to PMC</h2>
	<p>See <a
	href="http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg01667.html">original
	message.</a></p>

	<p>See notes from our <a
	href="http://www.eclipse.org/webtools/development/pmc_call_notes/pmcMeeting.php?meetingDate=2010-06-08#movenotes">meeting
	on 6/8 wtih Konstantin</a></p>


	<p>The PMC was torn and thought this issue deserved lots of
	discussion. The following are issues we discussed in meetings past few
	weeks.</p>

	<p>One reason we were torn, was that believe one of our first tasks
	is to make sure committers are happy and motivated to do great things
	for Eclipse in what ever way they see fit. On the other hand, the
	Eclipse rules of governance are important and need to be followed, and
	they are a critical part of why Eclipse works ... that is, they are part
	of what make it possible for competing companies to collaborate, each
	contributing committers, but with some degree of managing risk and
	protecting investments. Some good reason is required to change
	governance.</p>

	<p>Governance. It was explicit that a large reason behind the
	request to move this code, was a desire to change the governance of the
	code. It was generally agreed that this by itself is not a good reason
	to move code. Eclipse does have a unique system of governance compared
	to other Open Source Communities, and as a PMC we need to support and
	honor and apply those rules of governance as best as we know how. The
	overall, long term success of Eclipse depends on them. For example, when
	committers in a project do not agree on a code change, the status quo
	must prevails. We know that some think WTP is too conservative and
	allows too few changes if the changes might break adopters, but that is
	our philosophy or policy and from our point of view it is working as
	designed to ensure stability and adoption which in turn attracts and
	retains committers. Normally these rules of governance leads to good
	discussions, reviews, compromise, and improved solutions.</p>

	<p>History Note. we know that the whole issue of how to govern,
	package, deliver small platform-like function outside of the literal
	platform is a complex issue, and has a long history of being discussed
	and essentially unsolved (as discussed long ago in <a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=167144">bug
	167144</a>). The WTP Common Tools subproject is our WTP solution to that
	problem, and while in theory there could be other solutions, that's the
	solution we have and have been operating with for many years and many
	releases.</p>

	<p>Move-from versus Move-to project. Moves of
	code/components/projects are often a good, even great, thing at Eclipse
	are fully justifiable, and even encouraged in some cases. In general,
	the PMC would support code moving out of (or into) WTP, if there was a
	good reason and it would be good for Eclipse, overall. Good reasons to
	do such a move, usually, involves moving to join like-minded developers
	or projects to enhance synergy between them. There appears to be none of
	that type of advantage in this case. As an example, one alternative home
	for this code, of "like minded developers" might be in the
	Eclipse Platform, but we know that this was pitched to them, considered,
	but not picked up by them (discussed some in <a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=94608">bug
	94608 comment 36</a>, ... there may have been more discussion on some
	mailing lists, but they could not be found after a brief search).</p>
	<p>Technical aspects: Part of the proposal includes a technical
	aspect -- developing a shim layer of v1 code calling out to v2 code so
	WTP code would not need to change what APIs it was calling, but the
	implementation of those APIs would change -- albeit slightly, subtly and
	probably perfectly compatibly, but, still, there is not zero risk for
	that type of change. This technical aspect is problematic for a number
	of reasons. For one reason, this is essentially asking the PMC for
	"preapproval" to make that kind of change to WTP code but it
	would not be appropriate for the PMC to dictate that kind of change on
	WTP committers. That's something that should result from discussions and
	agreements with clients and WTP committers, and they could decide if any
	investment or risk was justified by the potential benefit. Secondly,
	some believe the 1.x code is stable, and if anything should become more
	rock solid, and not risk anything that might result from a move or shim
	layer.</p>

	<p>History note: during the Creation Review of the Incubating
	Faceted Projects Technology Project. there was some concern that the
	proposal was essentially moving established function out of WTP. At that
	time, in the interest of seeing if a separate project would lead to
	broader adoption, the "creation" went forward, but it was made
	explicit in the <a href="http://www.eclipse.org/proposals/fproj/">proposal</a>
	that the committers of WTP would decide if and when WTP ever wanted to
	move to the new framework -- that it could not be forced upon them. For
	historical link, see <a
	href="http://dev.eclipse.org/mhonarc/lists/technology-pmc/msg01144.html">email
	to technology PMC from October, 2008</a>. To further complicate things, to
	put it bluntly, there is no apparent community or adopters of the
	Technology incubating Faceted Project code, even though it has existed
	for 1.5 years, so a skeptical person might say that experiment of a
	separate project has not worked to attract other adopters or an
	independent community or committers, as had been hoped.</p>

	<p>A minor point, just to address explicitly for completeness, one
	reason for the request was that it would be "more efficient"
	to have in one location. The example given at our 6/8 meeting was that
	there could be a common build. But, there doesn't seem to be anything
	substantial that is inefficient or that is preventing progress.</p>

	<p>One reason some PMC members cited for allowing the move was to
	keep the primary committer of this code motivated and interested to keep
	working on it, improving it, and maintaining it. Other's thought that
	the same issue was a reason to leave it where it was ... WTP as whole
	has a vested interest in maintaining the code, seeing it succeed, and to
	some degree, we always have the risk that committers might leave WTP (or
	Eclispe) for a wide variety of reasons (changing careers, companies,
	assignments, interests, etc.) so why not leave it with its only adopting
	project. We could all sympathize with this goal of helping committers
	stay motivated and help them achieve their goals, but did not agree on
	it being a reason to move code or change its governance.</p>

	<p>One of the reason for our concern and care in changing location
	or governance of this particular code is precisely because it has been
	successful in getting widely adopted in WTP -- it is a victim of its own
	success. It is a much used, much appreciated, central core piece of WTP
	and we believe that WTP is its correct home.</p>


	<p>Related information and links:</p>
	<ul>

	<li><a
	href="http://www.eclipse.org/projects/dev_process/development_process.php#6_3_7_Move_Review">Dev.
	Process: Move Review</a></li>
	<li><a
	href="http://www.eclipse.org/projects/dev_process/Eclipse_Standard_TopLevel_Charter_v1.0.php">PMC
	Responsibilities</a></li>

	<li>See notes and links in our <a
	href="http://wiki.eclipse.org/WTP_PMC_Policies">WTP PMC Policy
	page</a>.</li>

	</ul>


	<h2>Handy Links from past meetings</h2>
	<h3>References</h3>
	<ul>



	<li><a
	href="http://wiki.eclipse.org/Team_thoughts_on_continuous_improvement_31">Continuous
	Improvement Notes</a></li>
	<li><a href="http://www.eclipsecon.org/2010/">EclipseCon 2010</a></li>

	<li>FYI ... Eclipse Foundation has a relatively new <a
	href="http://www.eclipse.org/home/categories/index.php?category=enterprise">"enterprise
	page"</a>.</li>
	<li><a
	href="http://www.eclipse.org/projects/project-plan.php?projectid=webtools">WTP
	3.2 Plans</a></li>
	</ul>
	<h3>Other projects to watch:</h3>
	<ul>
	<li>WTP @ GSoC 2009. There are two project accepted:
	<ul>
	<li>Index search for Java EE metadata. See <a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=233505">bug
	233505</a></li>
	<li>Embed OpenEJB in J2EE Preview server adapter. See <a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=265952">bug
	265952</a></li>
	</ul>
	</li>
	<li><a href="http://www.eclipse.org/proposals/sca-tools/">SCA
	Tools</a></li>
	<li><a
	href="http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg01400.html">EMFT
	Texo project proposal</a></li>
	<li><a
	href="http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg06011.html">Maven
	Integration</a></li>
	</ul>
	<hr />
	<p>Back to <a href="../index_pmc_call_notes.php">meeting list</a>.</p>
	<p>Please send any additions or corrections to David Williams.</p>
	</body>
	</html>