Planning Council/August 7 2013

Logistics

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 07, 2013, at 1200 Noon Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)

For all phone lines: Participant conference extension: 710 then enter pin 35498

Ottawa (local call in Ottawa) 1-613-454-1403
North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
Germany (local call anywhere in Germany) +49-692-2224-6059
France (local call anywhere in France) +33-17-070-8535
UK (toll free) 0800-033-7806
Switzerland (local call anywhere in Switzerland) +41-44-580-2115

SIP clients:

call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

**PMC (and Strategic) Reps**
Chris Aniszczyk	Technology (PMC)	Y
Dani Megert	Eclipse (PMC)	Y
Steffen Pingel	Mylyn (ALM) PMC	R
Brian Payton	Datatools (PMC)	R
Doug Schaefer	Tools (PMC)	Y
Adrian Mos (or Bob Brodt?)	SOA (PMC)
Ed Merks	Modeling (PMC)	Y
Ian Bull	Rt (PMC)	Y
Chuck Bridgham	WTP (PMC)
Gary Xue	Birt (PMC)
Wayne Beaton	Eclipse Foundation (appointed)
David Williams	(appointed Chair)	Y

**Strategic Reps**
Cedric Brun	OBEO (Strategic Developer)	Y
Neil Hauge	Oracle (Strategic Developer)	Y
Stephan Merker	SAP AG (Strategic Developer)	Y
Markus Knauer	Innoopract (Strategic Developer)	Y
Markus Tiede	BREDEX (Strategic Developer)	Y
Rajeev Dayal	Google (Strategic Developer)
(PMC rep)	Actuate (Strategic Developer)	X
(PMC rep)	IBM (Strategic Developer)	X

**Inactive**
[no name]	CA Inc. (Strategic Consumer)	X

Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time
D = delegated
X = not expected

Announcements

New Member: Dani Megert is now the Eclipse PMC representative to the Planning Council. Thanks to John for years of service. Thanks Dani for volunteering to take his place.

Luna Planning

Is there confusion/contradictions about "unreleased components in Sim. Rel. repo"? See bug 411977.

For reference, see current policy.

It was thought this one deviation was a "fluke" and no systematic action needed; that for the most part, everyone understands

a) can't release code under another project's namespace (can "include" it, if previously released)

b) if unreleased code is desired to use (it is, after all, EPL) you must "refactor" it into your own namespace, following the usual rules of attribution, maintaining copyright info, etc.

Are we "too lax" in versioning requirements? Especially for "maintenance"? See cross-project list posting. [To be honest, I do not recall what specific situation this is about?]

Ed explained the situation to us (involved versioning issues between XText and UML2) and it too sounded like a rare case that did not need to be "policed". But does highlight the importance of correct semantic versioning and not "adding features" with a mere "service increment".

I have started scheduling Luna milestones. I think first 4 or 5 will be similar to previous years.

* Appears that timing of EclipseCon in 2014 may effect how M6 is scheduled. It comes "the last week" of what would normally be M6, instead of M6 finishing first.

* See Luna/Simultaneous_Release_Plan.

Most favored completing M6 before EclipseCon, even though that is the "API Freeze milestone". DW to workout that schedule in time for reps to review with their projects before September meeting (and alternatives, if any seem to exist).

Can/should Planning Council say projects "should" contribute source to common repo? Or continue to "leave it up to projects" to decide?

See thread around http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09506.html

Possibly bug 414262

[Remember, we should make this decision based on principle, not the one request for an "Ultimate Package" (bug 414025), since a) we should always work on principles!, and b) this package may or may not come to fruition.]

It was generally agreed we should continue status quo of "leaving it up to project" ... let their adopters and community drive any changes needed/desired. Primarily, simply not to "add process or rules" to what many think is already too many rules and processes and additionally, it was commented, it is hard to "draw the line" ... what about "types of documentation", or "examples" ... i.e. there is no one answer that fits all projects.

Discuss more frequent "(un?) coordinated releases" or updates to common repo or updates to EPP packages. (Doug, Ian).

See Ian's summary at http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02168.html.

For some fun reading, I looked up the original bug on how we got to the names of "SR1/SR2" .. bug 227767

For reference, see current policy.

This item had a long discussion, covering many area, and for the most part, the status quo will be maintained for now.

A couple of things seemed to be agreed upon:

1) This is not something to change "this year" ... something longer term ... but, we need to continue the discussion and sort out the issues and solve them in some manner -- that is, there was no disagreement that the current schedule/rhythm does not satisfy all adopters and projects and we need to see if we can improve on that.

2) Other groups/projects are leaning towards "continuous delivery", why not us? (Or, do we already? :)"

3) The _main_ issue (in terms of "deliverables") -- I came to understand -- are the "EPP packages". That is, there is nothing preventing projects from releasing any time they would like to ... but the desire is that they'd like EPP packages updated at the same time. Otherwise, only "in-the-know" product adopters and a few savvy users know how to go to a project-specific repo to get updates (or, "new installs"). And ... some on planning council see that as a bad thing (ha ha ... mostly my humor :) ... but ... there are two sides to that story).

4) There appeared to be agreement that something like "monthly releases" was not feasible ... too many places for it to "go wrong" or cause lots of additional work for projects (or, suffer from reduced quality). [This was not literally discussed at meeting, but to add an editorial remark ... It seems hard enough to come out with 6 week milestones. It is unclear if anyone actually needed something as frequent as monthly or 6 week releases ... or if it was more a "marketing" thing? If so, could there be more/better/easier ways to "hype" milestones to get equivalent interest? If the desire really is so projects/adopters could release "whenever they were ready", then I'll just point out there is a lot of hidden assumptions being made in that case that in reality would cause the same headaches the "release train" is meant to solve -- primarily, it might appear to work fine the first time through, if everyone goes in order, but then suddenly a recent release, say of a commercial product, can not update a few months later to get the latest of some pre-req, due to some new feature/non-API use/deprecated API removal, subtle change in behavior, etc, and then they end up having to wait 4 to 12 months anyway to get the fixes needed so they can "get on" that, now old, version of the pre-req ... and perhaps by then that pre-req no longer works with some other pre-req that has since released. So, point is, anyone who really desires this needs to think through the hidden (long term) assumptions and "solve" them.] But, in general, "a mass repository" that may or may not work together did not seem to get much excitement from Planning Council, if I was hearing correctly.

A couple of items seemed to have very different points of view:

1) Is it a good thing to encourage "frequent feature/API updates" or a bad thing? Examples were given on both sides. On the one hand, it can be "hard on" adopters to react, if there are large changes requiring adopters to do a lot of re-testing/translating/marketing, etc. But, everyone sees the advantages of it, especially for a "young" project like EGit where they needed lots of quick improvements to be complete, and useful.

2) An interesting, contrasting, case was made about "core components" vs. "leaf components". To some, it seems clear that something like the core platform should only apply maintenance for SR1 and SR2 (to ensure only steady improvements in quality) but on the other hand, there are times that changes in the core platform is exactly what other projects want, such as CDT, ... such as having a new set of APIs added that allows them to come out with a better (from their point of view) off-cycle release even though "new API" can have unpredictable effects on other adopters. Hard problem to solve. [Just thinking aloud, perhaps some special versioning conventions and tight p2 constraints could allow relatively safe "forks" of something like core platform APIs, without impacting adopters that were not interested? In essence, CDT would release their own forked version of the platform ... just thinking out loud ... not a serious proposal.]

3) Not to mention, sometimes even the core Platform may want to add a new feature "off-cycle", such as if a new version of Java comes out "mid-year", perhaps they'd want to add "preliminary support" for it in SR2? Perhaps those types of cases provides some hint of how to codify the practice of adding features in a "service release" ... when ever possible, they should be done as "optional", additional features that adopters can take or leave. Not sure how to do that with core API changes, though ... short lived fragments that adopters can take or leave?

So, lots to (continue to) discuss. Perhaps fundamentally, what does "continuous delivery" mean for something consisting of 60-70 projects?

Dani did state that the Eclipse PMC discussed explicitly, and they want to keep the status quo. Even the names "Service Release". That while new features can be allowed in SR1 and SR2 (as per our existing policy) that it is not something to "encourage", in their view, ... they should be the exception rather than the rule ... and the focus on SRs should be on improving quality, not adding new features. (hard to do both, with fixed resources ... or, more accurately, without vastly increased resources :). New features should be "exposed" to public in a number of milestones, before released. [To editorialize again, perhaps we need to do a better job of encouraging use of milestones? I think some believe that a "release" is the only thing consumers/users will use enough to provide adequate feedback on a new feature.]

Doug did state explicitly that his "focus on IDE" efforts (and probable working group) were a whole separate issue and not in the Planning Council realm. (whew)

[post-call] Another comment I heard, on arch. council call, was that some adopters have been surprised to hear that "we" allow new features in SR releases at all -- while I think "we" want that to continue to be allowed, we should probably do a better job of documenting them, perhaps as a quasi-"exception process" so that it is more obvious to the community of "sim. rel. consumers" when it does happen ... and document better some of the basic information: what they change or add, if they are optional, etc.

Doug also wants to discuss him taking over the "releng role" and do aggregation builds using Maven/Tycho.

The focus is still on projects providing OSGi bundles in p2 repos, right? No matter what technology they used to get there?

What type of "project input" is required?

What type of "testing" is done that all is well formed and can be installed together and is repeatable?

In particular, how are "IDE" vs "runtime only" components treated separately?

What are concrete advantages?

Doug said he would try to work on some prototypes. But (if I heard him over the spotting phone connection correctly) this wouldn't be anything to prevent planning to use the b3 aggregator approach as we have been and continue with that until we know something more concrete, and then would be the time to re-discuss). The approach (again, if I heard right) basically makes use of a series of Jenkins (or Hudson) jobs, one successful job triggering the next, and progressively "building up" the repository. (I think is how he briefly described it). [Doug, please correct if I mis-heard any of this ... we didn't spend much time on it.]

Progress on Action Items

Editing of "Requirements Document"? (Dani and Neil)
GSoC project for "Development Channel"? (Wayne)
Improved "aggregator examples/doc". (dw -- no progress).

But, about to send out "aggregator builds and streams ready" message ... depending on outcome of other items.

[Orbit plan "by end of August". (dw -- no progress -- will likely be late, still "in September")]

There were no "in-meeting" updates to any of these items, except Dani said they should start the editing during M2.

Kepler Retrospective

Propose to start in August (if any extra time), finish in September.

No time for a retrospective, per se, we'll try again in September ... please discuss with your projects or members you represent to see if there is anything we should document about "what worked" and "what didn't work".

Next Meeting

September 4, 2013 - Regular First Wednesday Meeting

Reference

EclipseCon face-to-face follow-through action items. For original meeting notes, see Planning_Council/March_24_2013 and for discussion leading to action items, see Planning_Council/April_10_2013. For last status update, see Planning_Council/May_8_2013.

Luna Wiki page

Kepler Wiki page

Juno Wiki page

Planning Council/Indigo retrospective

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO