Skip to main content
Jump to: navigation, search

Difference between revisions of "Planning Council/January 06 2016"

(Mars Planning)
(Neon + 1 Planning)
Line 184: Line 184:
 
== Neon + 1 Planning ==  
 
== Neon + 1 Planning ==  
  
* How's "naming" coming?  
+
* How's "naming" coming?
 +
* Poll: https://www.eclipse.org/neon/planning/poll.php -> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_dd4ff581da35bddc
 +
* Current winner with 242 votes and 8 days left: Oxygen
  
 
== EclipseCon Face-to-face ==  
 
== EclipseCon Face-to-face ==  

Revision as of 16:18, 5 January 2016

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, January 6, 2016, 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
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC)
Sam Davis Mylyn (ALM) PMC
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Adrian Mos (Marc Dutoo ) SOA (PMC)
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC)
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed)
David Williams (appointed Chair) Y
Strategic Reps
Nick Boldt Redhat (Strategic Developer)
Remi Schnekenburger CEA List (Strategic Developer)
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Stephan Merker SAP AG (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer)
Rajeev Dayal Google (Strategic Developer)
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
Cloud (PMC) X
CA Inc. (Strategic Consumer) X
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 the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.

Mars Planning

  • Mars.2 issues?
  • Remember Mars.2 RCs begin Jan 15 to Jan 22.
  • Tracking participation in minor releases bug 485223

Neon Planning (and beyond)

  • Should we change "maintenance" staging name now? for Mars.2? See bug 483475.
  • Release Policy vs. Release mechanics. This is being tracked in bug 483322.
One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" (or, say, once per month?) -- say for "hot fixes" only ... say after review/approval by Planning Council?
AND, to avoid "contamination" of update site lists (without the user being in charge of it) change p2 install/update to not allow the addition of reference repositories during feature installs. But, it has been stated, adopters still want that ability ... so, not sure how "we" could ever know the difference.
Perhaps could solve with a "product preference" so EPP could "set" the preference one way, and adopters creating products could set it another way? Or, direct users to do so?
Easy for me to say "change p2" :) but ... who would do the work?
Perhaps solve simply with a "policy" of "do not add reference repositories" (with feature installs)?
But without some way to enforce it, I think some projects still would.
This "reference repositories issue" was a discussed as a concern at Architecture Council
Apparently there have been cases of users getting "mixed" installs because reference repositories are sometimes very broad. [I hope I've captured the issue correctly, I was not there, so please correct if I read it wrong.]
Does Oomph solve this problem at all? Does it have a possible solution?
From Ed's note to ide-dev list, it sounds like it solves the issue of updating non-root features (as long as they are "in the repository"?).
  • Rolling "release" issue.
I have sometimes heard it suggested we allow more of a "continuous release". Is this something we should discuss? Should we have some long term planning for it? Such as, what would it take to accomplish that?
This could be planned with or without the "beta stream" mechanisms sometimes discussed.
  • Should the ability to update from yearly release to yearly release be a 'requirement'?
What would this take? (Such as features are never "just removed" but are replaced or transitioned?)
What testing would projects have to do?

Neon + 1 Planning

EclipseCon Face-to-face

New Business

  •  ?

Next Meeting

  • February 3, 2016 - Regular First Wednesday Meeting

Reference

Neon Wiki page
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top