<?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>