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.

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.

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?

[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).

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.

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?

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)

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?

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".