Skip to main content

WTP PMC Agenda/Minutes for June 22, 2010 Conference Call

WTP PMC Agenda/Minutes for June 22, 2010 Conference Call
Back

Call Info

Tollfree in the US: 877-421-0030
Alternate: 770-615-1247
Access code: 173098#
Full list of phone numbers

Call Time: 8:00 AM Pacific; 11:00 AM Eastern; 1500 UTC

Attendees

PMC Members

  • David Williams: Y
  • Naci Dai: N
  • Raghunathan Srinivasan: Y
  • Neil Hauge: R
  • Tim deBoer: N
  • Kaloyan Raev: Y

Announcements and General Business

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.

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

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.

Discuss Konstantin's move request to PMC

See original message.

See notes from our meeting on 6/8 wtih Konstantin

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

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.

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.

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 bug 167144). 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.

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 bug 94608 comment 36, ... there may have been more discussion on some mailing lists, but they could not be found after a brief search).

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.

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 proposal 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 email to technology PMC from October, 2008. 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.

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.

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.

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.

Related information and links:

Handy Links from past meetings

References

Other projects to watch:

Back to meeting list.

Please send any additions or corrections to David Williams.

Back to the top