View source for Planning Council/May 06 2015

== Logistics ==

{| cellspacing="0" cellpadding="4" border="1"
|-
| Meeting Title: 
| '''Planning Council Conference Call'''
|-
| Date &amp; Time: 
| Wednesday, May 6, 2015, at [http://www.timeanddate.com/worldclock/fixedtime.html?year=2015&month=05&day=06&hour=12&min=0&sec=0&p1=179 1200 Noon Eastern]
|- valign="top"
| 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
* 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  ==

{| width="90%" cellspacing="15" cellpadding="5" border="0" align="center"
|- ||width="100%" valign="top" ||
|
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
|+ '''PMC (and Strategic) Reps''' 
|-
| John Arthorne (Acting)
| Cloud (PMC) 
| Y 
|-
| Chris Aniszczyk 
| Technology (PMC) 
|  
|-
| Dani Megert 
| Eclipse (PMC) 
| Y    
|-
| Steffen Pingel (Sam Davis)
| Mylyn (ALM) PMC 
| D      
|-
| Brian Payton 
| Datatools (PMC) 
|   
|-
| Doug Schaefer
| Tools (PMC) 
| Y  
|-
| Adrian Mos (Marc Dutoo )
| SOA (PMC) 
| 
|-
| Ed Merks 
| Modeling (PMC) 
|  
|-
| Ian Bull
| Rt (PMC) 
| Y  
|-
| Chuck Bridgham 
| WTP (PMC)  
| Y      
|-
| Wayne Beaton 
| Eclipse Foundation (appointed) 
| Y       
|-
| David Williams 
| (appointed Chair)
| Y       
|}
|
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
|+ '''Strategic Reps''' 
|-
| Cedric Brun
| OBEO (Strategic Developer) 
| Y  
|-
| Neil Hauge 
| Oracle (Strategic Developer) 
| Y       
|-
| Stephan Merker
| SAP AG (Strategic Developer) 
|    
|-
| Markus Knauer 
| Innoopract (Strategic Developer) 
| Y 
|-
| Rajeev Dayal 
| Google (Strategic Developer) 
|  
|-
| (PMC rep)
| Actuate (Strategic Developer) 
| X
|-
| (PMC rep)
| IBM (Strategic Developer) 
| X
|}
|- ||width="100%" valign="top" ||
| 
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
|+ '''Inactive''' 
|-
| [no name] 
| CA Inc. (Strategic Consumer) 
| X
|-
| [no name] 
| Birt (PMC) 
| X
|}
|}

<small>Note: "Inactive" refers to [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic 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.</small> 

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

== Announcements ==

* Neon is Mars+1 name! 

== Previous meeting minutes ==

* Review [[Planning_Council| previous meeting minutes]] if you'd like.

== Mars Planning ==

* Any issues?

== Progress on Action Items ==

* Improving user experience in finding right function to install. For latest ideas, see 
: {{bug|459905}} - Create a Marketplace for the simultaneous release. 
: ''Overall, would be "driven" by Eclipse Foundation, but they would need help from top level projects, and the Planning Council.''
: For the latest ideas, see [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02416.html Wayne's recent note to mailing list].

== New Business ==

=== Do we need to improve wording in [[SimRel/Simultaneous_Release_Policy_FAQ| Policy of new projects joining in SR's]] ===
 
: - Its original intent was to say "Yes, new projects and features can join SRs" -- without requiring Planning Council exception, if they meet the requirements set out in that policy.

: - But, as we clarified some wording/sections, especially the one about "no major releases", intended to avoid breaking API changes (for train, and adopters), that seems to be oriented towards only "new features", but, in a way, rules out "new projects" (since, by technical definition, would be a "major" version change from "nothing" to "1.0.0"?) But, I do not believe was the intent. After all, if it is completely new API, it would hardly have the ability to break anyone (at least, at API level ... "fitting in" and not breaking anyone, was the purpose of "getting into SR early". 

: - Is this confusing? Should wording be clarified?

''No wording changes at this time ... especially given subsequent topic.''

''Also said I wanted to add "features" explicitly to "must sign plugins", and there was no disagreement. (They are never checked at runtime, since they are not Java code, but are checked during installation -- best to confirm that empirically).''

=== Continuing Discussion of if or how to change "yearly release"? ===

==== History ====

: - Review of original motivations and problems solved by current process and schedule. 
:: -- Contrasting "styles" of "releases": Our yearly release was intended to be rock-solid release, that commercial adopters could count on being released on a predictable time, with a predictable level of quality -- so that their own money-making support processes would be predictable, and long term.
:: -- Another style: Some OS Projects like to have a "release" very frequently, typically at semi-random times, and often very frequently (from "weekly") to "several months"). Notice the parallel to our "I-builds" and "Milestone (Stable) builds). 
::: --- These releases  are typically done when either "significant bugs in previous release had been fixed" or 
::: --- There had been "enough new features added" that "things were ready"). 
:: -- An interesting (casual) observation: when these "frequent release" OS Projects were largely driven by a "service" organization, there is often one "release" (perhaps a year old, or so) that is the one (and only) one that they offered service contracts for ... which parallels our own yearly releases. (In other words, they use the word "release" to have more than one meaning.) 

* - Given the above, our "solution" was to provide a (voluntary) Simultaneous Release train once per year, while at the same time, emphasizing that individual projects could still release whenever they wanted. 

* - Short review of "pre-Callisto" days, to avoid repeating past mistakes; (Names and examples are a fictional melding of several cases). Platform released in June. TPTP and CDT a month or two later, WTP a month or two later. Only at that time, was a bug discovered in the Platform (by WTP nearing release) such that they could not release until SR1. Platform releases SR1 in September, WTP can now release. Only then was it observed that some regression was introduced that prevented CDT from working with the Platform SR1. So, CDT might hurry up with their SR1, or adopters would all have to patch a mix and match of components to make their product schedule. In the end, adopters could come up with a product, but it was pretty unlikely users could install other things from Eclipse into it, since there was no "standard" release to build on top of. Similar problem for other plugin providers, inside and outside Eclipse ... it was hard to find a stable, consistent set of things that "worked together", and even when they could, imagine the instructions to the end users on how many update sites to go to, getting precise versions of things (might be most recent, but might be down level) all to "make something work" ... and then no confidence that other things would work with that collection. So, it was thought "same schedule" and "one update site" was a good start at solving these early problems. 

* - Much has changed since those pre-Callisto days (such as rate of change has slowed) but ... that the principle is the same and is still valid. 

* - One reason, originally, that we had "integration over many milestones" as *the* key requirement (it was the only requirement, nearly, in Callisto) was A. to find bugs in OTHERS code (for example, some change in the Platform might not be reproducible if using only the Platform, but it would easily prevent WTP from working correctly, and if discovered "late", then there would be no time to fix it before the planned release date. B. Many of the bugs found in this situation are subtle, due to the many "interacting components" (even though only 20 or so, during Callisto). No one could possibly find them during any sort of quick smoke test, or even a few weeks of "testing one component"; but only when used in "real life" use-cases and workloads ... and we are gratefully to our community of early-adopter users, for trying to do just that, and providing that valuable feedback over a period of many months. 

* - The other, "checklist" requirements have been added to or changed over the years for some items. These typically fall into categories of "minimum" to-do items, to work in one repository, without making us look silly (or, security related) and then also into a category of things that allow better adoption by other projects and commercial adopters.

==== The Future ==== 

===== Statement of Problem =====

* There is some (ongoing) concern that "we" (the Eclipse Foundation) need ability to "release more often" or "with very short cycle". Some have mentioned "once every 6 months". Some, in the past, have said "once a year is too frequent, and should be once every two years" (as LTS was originally proposed to support [current policy is a little less formal, mostly "any SR2" and sometimes even SR1, as I understand it]). And, some projects want (or, do) release every month or two (especially new projects). How can we be "all things, to all people"? (Or, at least, get much closer than we are now). 

* Our [[SimRel/Simultaneous_Release_Policy_FAQ| Policy of new projects joining in SR's]] was intended to be one step in that direction. (And, at first, many said that was enough ... that satisfied needs, that I could even take the on-going discussion off of the agenda [reference] ... but now ... 
:: -- Some have mentioned "the timing" is still not right, and need something between SR1 and SR2. 
:: -- Some have mentioned that "SR" (Service Release) is the wrong name, if it is going to contain new projects and new features. (And, not sure if it is that incorrect 'SR' naming, but it does seem it is a widely misunderstood policy -- by even Planning Council members. 
::: --- We discussed naming in previous meeting [find reference]. 
: - The EPP packages have been so successful, that some now believe that a project "releasing when ever it wants to" does not mean anything (or, much) ... it only means something if EPP can release when ever it wants to. 
:: -- Similarly, it is hard for a project to "update" just their one component in an EPP package, for part technical, and part policy reasons. 

* The EPP packages have been so successful, that "everyone" wants to be in an EPP package -- so much so, they are nearly a marketing tool. 
:: -- Off topic, maybe, but this is oddly parallel to early days, when "everyone wanted to be in the Platform" since that was the "main thing" at Eclipse, that everyone installed. Are we now seeing the same thing happen to EPP packages? Are non-EPP components second class citizens? That was never the intent. The EPP packages were meant to merely provide a better "out of the box" usability experience, oriented to certain audiences, but it was expected that users could and should still "customize" that by adding what ever other function they'd like. 
:: -- The "Simultaneous Release" repository was intended (in part) to make it "easier to discover things" that were available, instead of having to "look all over the place". 
::: --- Probably several reasons why that's not working too well? 
::: --- And now we also have "The Market Place" -- yet another place to look? Or, satisfying needs of a certain class of user? (I think the latter). 
:: -- Should we avoid having too much in EPP packages? Or, put in as much as we can? [Without usage statistics, it is impossible to know.]
:: -- The "capabilities" mechanism in the Platform was also supposed to help make things easy to progressively discover, but it never caught on. 

* Leaf versus Core: we currently do not have a good separation of "leaf" vs "core" component -- and perhaps this is not possible. It could be argued it is easier for a "pure leaf" component to update/release more frequently, than "core" components, since they would have less chance of breaking others in release train. But, they could, still break adopters (and in theory still break core components functionality, due to the nature of "plugins and OSGi". There are often "tangled" relationships making the distinction between "leaf" and "core" multi-faceted instead of a clear binary or hierarchical distinction.

===== Possible solutions ===== 

* See Doug's [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02418.html mailing list post] for one approach.


===== Constraints ===== 

* Developers work load
* IP work load (and work flow)
* Marketing

===== What is required for (any) solution? =====

* Improved automation

* More "self service"

* More automated testing

=== high level outline of discussion === 

* Seemed to be rough agreement that to "release more frequently" would be good ... for projects and perception.
* Was discussion that "6 per year" too many ... "2 per year" not enough. So settled on "4 per year" as a working assumption. 
:* Did not really discuss WHEN they would be (which months), but (I think) general agreement they should be regular, and predictable. 
:* Did not really discuss what to call them.  We want to convey they are true releases, but, releases with no subsequent service release. 
* "SR" name especially bad for perception, since it is not really just "service releases" any more. 
* But, even if we had 4 releases per year, some might put in "just service", some might put in new features, so adds some complexity on what and how to communicate (with each other, and community). 
* We would always (still) need "two streams" going ... one for "next immediate release", ... another stream for "long term work". (Or, may vary by project?)
:* We did NOT discuss how to manage that ... would "long term work" be merged into "release" stream at certain points? 
* We would (still) want something like a yearly "LTS Release". 
* We did say it would take at least 2 months for us to have a concrete proposal.

== Next Meeting  ==

* June 10, 2015 - Regular First Wednesday Meeting -- last meeting before release!

== Reference  ==

: 2013 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]].

:[[Mars| Mars Wiki page]]

:[http://www.eclipse.org/org/foundation/council.php#planning Planning Council Members]

:[[Simultaneous Release Roles]] and [[Simultaneous Release Roles/EMO]]