Logistics
| Meeting Title:
|
Planning Council Conference Call
|
| Date & Time:
|
Wednesday, August 5, 2015, 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
- 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
- call 710@asterisk.eclipse.org, then enter pin 35498.
|
Members and Attendees
PMC (and Strategic) Reps
| John Arthorne (occasional)
|
Cloud (PMC)
|
|
| Chris Aniszczyk
|
Technology (PMC)
|
|
| Dani Megert
|
Eclipse (PMC)
|
Y
|
| Steffen Pingel (Sam Davis)
|
Mylyn (ALM) PMC
|
D (?Chan?)
|
| Brian Payton
|
Datatools (PMC)
|
|
| Doug Schaefer
|
Tools (PMC)
|
Y
|
| Adrian Mos (Marc Dutoo )
|
SOA (PMC)
|
|
| Ed Merks
|
Modeling (PMC)
|
|
| Ian Bull
|
Rt (PMC)
|
R
|
| Chuck Bridgham
|
WTP (PMC)
|
|
| Wayne Beaton
|
Eclipse Foundation (appointed)
|
Y
|
| David Williams
|
(appointed Chair)
|
Y
|
|
Strategic Reps
| Nick Boldt
|
Redhat (Strategic Developer)
|
Y
|
| Remi Schnekenburger
|
CEA List (Strategic Developer)
|
|
| Cedric Brun
|
OBEO (Strategic Developer)
|
|
| Neil Hauge
|
Oracle (Strategic Developer)
|
|
| Stephan Merker
|
SAP AG (Strategic Developer)
|
Y
|
| Markus Knauer
|
Innoopract (Strategic Developer)
|
|
| 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
|
| [no name]
|
Birt (PMC)
|
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
Previous meeting minutes
- Review previous meeting minutes if you'd like. That is, review them before meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Mars Planning
- What to call September and February releases?
- Propose to change name to "Mars.1" and "Mars.2" to avoid the "service release" terminology, as one way to better reflect the rules that have been in place for years (See Policy FAQ), and perhaps name change alone would help correct the mis-perception that "new things can be added only once per year". For some recent history discussion, on how we ended up proposing a "point number", see mailing list thread on the topic.
- - Largest impact would be to change "MarsSRn" type phrases to simply "Mars.n" in the few places it is used.
- - When generic words are needed, instead of numbers, the June Simultaneous Release can be called "the initial yearly Simultaneous Release" and subsequent ones, when generic wording is needed can be called "update (number)" or "point number" or "dot number". For example, "Our project typically does XYZ in the first update, not the initial release".
- - This terminology applies primarily to the "Simultaneous Release". Individual projects should still refer to their releases as accurately as possible (service release, or minor release, if not specific number).
- * The "Policy" (currently in Policy FAQ) will be "moved up" to the actual "plan" document. (Just as well move both items into the Plan, even if as footnotes.)
- > In general, "the policy" will emphasize that new projects can join in subsequent, as well as initial releases and projects can contribute "minor releases" as well as "service releases" ... it is up to the project. But, a) must be "backwards compatible" with that train (for example, a minor release that changes "internal methods" into API, should leave the "internal methods" in place, but deprecated) and b) almost never would be a "major release" -- the project would have to be a pure leaf component in Simultaneous Release, and have good reason to believe would not effect any adopters (hard to do, in practice), and would require "exception process" in Planning Council (partially as sanity check, but primarily to ensure well communicated).
- - We need to (also) add milestones for update releases. I propose we have two milestones, M1 [not sure when, yet], and M2 become what we currently call the "warm-up RC". So, we would end up the 2 milestones, and 3 RC's. The milestones are needed primarily for those new projects joining, or those adding large new features. But, as with mainline development, everyone should contribute "their latest", even if just working on service.
- > New Projects or features would have to be in the aggregation build by M2 [Or, should we be stricter, and say M1? -- at least, for Neon's subsequent releases?]
- > [TODO: More of a Neon Item, but consider having more than 2 streams being aggregated. Purpose would be to better enable projects to be working on Update+2 before everyone else is finished with Update+1 (for example).]
- - In the end, Simultaneous Release name for September and February releases agreed to was "Mars.1", "Mars.2". This is the main name that will occur in announcements, URLs, and "about box", and similar -- anything that refers to a specific release. Initial releases will still be named without numeral, such as "Neon".
- - It was also agreed that when a generic term is needed, then an informal "update" or "update release" is suitable, such as "We'll fix that in an update release". We considered the proposal of having "Update" in the name, such as "Mars Update 1" but some thought that would make URLs, and some names unnecessarily long, and for some there might be an implication that "update" meant about the same thing as "service" so we thought best to be as generic as possible. The <Release name><dot><numeral> does indirectly imply a "minor release" (but, that's only if you know about OSGi semantic naming ... so, pretty generic for most users). The generic term "update" was thought better that "minor release" since a) "minor release" does not have any "industry wide" meaning; b) many projects may still do only "service releases" so did not want to imply every project "had to be" a minor release. Its believed too, that this matches what a fair number of projects and products in the industry do -- have a "main (or major) release" and "dot (or point) releases" and "service releases".
- - Had a LONG discussion about "what an update release means" ... some thought it still implied "nothing new", but most agreed it obviously means "nothing breaking". Some (who missed meetings where this was previously discussed) questioned "why not allow breaking" changes -- completely new releases -- but some adopters in meeting spoke up on the need and importance to have "nothing breaking".
- - While we agreed with the new emphasis on "users needs" we reiterated our desire to balance that with not only adopters needs, but more so committers needs ... every "coordinated release" is extra work for committers, on a number of levels. If nothing else, even if a project did not change anything themselves, they might be effected by changes someone else made in Simultaneous Release repo. Even a +3 project can effect a +1 project, given the nature of plugins. They would not directly break compiling code, but they can change the order that things are done, or effect some critical path section of performance, and other indirect effects.
- - It was agreed, that even breaking API changes might sometimes be allowed in an update release, but that would be handled under current Exception Process. The types of use-cases where this might make sense is for a leaf project (effects nothing else in Sim. Release) and where the project is fairly sure there are no adopters yet (such as new, incubating project) or where communication with adopters is thought to be adequate and adopters have indicated their desire for the breaking change. TODO: document this sort of exception explicitly in "Update Release" description (to be in the Plan document).
- - After meeting, I realized we never discussed things like "translations". Having something "new" in an update release, could break some adopters "product translations" (that is, English might "show up" in a translated product, if some "new feature" was picked up by customer) but ... that seems to be fairly low risk and low impact.
- - Some discussion of how much this was like "wild west" -- especially considering long term potential process changes where projects could update even more frequently. Only conclusion was that to avoid "wild west" chaos was one reason to still have a "coordinated release" and if users want to get latest release of "uncoordinated changes" from some particular project, then they should have to take explicit action, such as adding a new URL to their software site repository list. This does have some implications: projects should not automatically add reference repositories to software site lists that are generic or "high level" and which could automatically pick up new releases with breaking changes. (I think everyone knows that, already).
- - There was some talk about how to make it so that EPP packages could be "updated" by individual projects, without getting too "wild west" about it. Left for future discussions.
- - There was some talk about how to better test packages automatically, so for future, especially if "very frequent" updates, there would not be too much increased burden on project's committers to test EPP pages (say, if individual projects in EPP packages released changes every month, every few weeks?). Again, mostly left for future. Wayne did mentioned Eclipse Foundation might be able to help fund/staff some "automated testing" effort -- though, I am sure he was now aware of how large this effort could be. :)
- - There was no talk of if or how "Oomph" played a role in "more frequent releases", if any. Also left to future discussions of having milestones in "Update Release" streams (not just RCs) or more than two "update streams". Also left to future (not discussed) was the idea of having having a single Sim. Release repository instead of composite) which will become more important, as we have more update releases.
- - Another thing not discussed, was the inability to remove features, in an update release. (See bug 314165).
- - There was a repeat of statement of our desire to have 3 Update Releases for Neon (not two). TODO: need to propose dates soon!
- - It was agreed the Plan was the best place to put primary description of "Update Release" (and deprecate that unfindable "Policy FAQ"), but for Neon, to also add a section in Requirements to better describe exactly what requirements are, for Update Releases, such as when new projects need to be in a build. TODO: I will update Mars Plan soon, give PC a short time to review for errors, and then announce on cross-project list.
Neon Planning
New Business
Next Meeting
- September 5, 2015 - Regular First Wednesday Meeting
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 Wiki page
- Planning Council Members
- Simultaneous Release Roles and Simultaneous Release Roles/EMO
