Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Planning Council/November 07 2012"

(Members and Attendees)
(Other Business)
 
(5 intermediate revisions by one other user not shown)
Line 133: Line 133:
 
== Announcements  ==
 
== Announcements  ==
  
* ?
+
* Reminder M3 due next week.
  
 
== Juno ==
 
== Juno ==
  
* SR2 to get active in January  
+
* SR2 to get active in January
 
+
  
 
== Kepler ==
 
== Kepler ==
Line 152: Line 151:
  
 
: Discuss requirements. Changes or clarifications needed? Or, approve "as is", unchanged from Juno?
 
: Discuss requirements. Changes or clarifications needed? Or, approve "as is", unchanged from Juno?
 +
 +
::*''We will formally "approve for Kepler" at our December meeting, though we believe the document is pretty much ok as-is.''
 +
 +
::*''One question that came up was "What does the API requirement mean, exactly?" (where projects must document their API policy and their use of non-API from other projects). The brief answer was "we leave it up to each project, we don't police it". But that the purpose is so that adopters can better understand what is considered API ... that they might want to use ... and/or if a project is "API clean" with respect to its use of code from other Eclipse projects. This in turn led to a brief discussion of "if we don't enforce it, is it really a requirement", but that applies to all the items in the "Required for good adoption" section of the document. I think still valuable to have that section since it means it would be a legitimate bug if an adopter asked a project "what is your API policy" or pointed out in a bug "you use non-API from project B which prevents us from doing X". If/when/how the project "fixes" those bugs is still up to them, but they would valid bugs and it would be incorrect for a "Simultaneous Release Project" to say "Invalid bug, we don't care about that". <br /> TODO: Ian will see if wording can be clarified/improved or if current wording suffices. ''
 +
 +
::*''Another comment came up on the "greediness" requirement. It is thought the Sim. Rel. requirement is correct as written, but that the community (and ourselves) need more education on why it is important ... that is, why use "greedy=false" for runtime optional bundles. I think that one reason is that users (and adopters) may not want to include those things that are installed simply as function of what repository they point p2 at, but, maybe more important, that if such as "optional but greedy" requirement pulled in an additional bundle (or bundles) that it would be impossible for an adopter to provide a "feature patch" for those optional bundles ... if those optional bundles just so happened cause some critical issue in their product for a customer. This should all be confirmed and if confirmed some encouraging, educational reminders be given to the participating projects. But, at the moment, it is not thought the wording in requirements document needs changing (i.e. if a project refuses to go along, they would not be denied participation).''
 +
 +
::*''The document could be "polished" and some of the "removed" requirements (which are currently in strike-out font) be literally removed ... while "changes" are interesting going from one year to the next, we don't need to maintain that "history" forever.''
  
 
== Other Business ==
 
== Other Business ==
Line 157: Line 164:
 
* Any discussion about {{bug|392098}} - Include workswith in simultaneous release?
 
* Any discussion about {{bug|392098}} - Include workswith in simultaneous release?
 
: I closed as "won't fix", but glad to hear any further discussion or opinions.
 
: I closed as "won't fix", but glad to hear any further discussion or opinions.
 +
::''No discussion and Steffen confirmed all is well and the clarification appreciated.''
 +
 +
* ''There was a problem for one member getting in through the "North America" number for Asterisk service. Just kept getting busy signal for 10 or 12 minutes.''
  
 
== Next Meeting  ==
 
== Next Meeting  ==

Latest revision as of 14:16, 7 November 2012

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, November 07, 2012, at 1200 Eastern
Dial in: (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers:

  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-877-369-7806
  • 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
Participant conference extension: 710 then enter pin 35498
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
John Arthorne Eclipse (PMC)
Steffen Pingel Mylyn (ALM) PMC Y
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Adrian Mos SOA (PMC)
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC)
Wayne Beaton Eclipse Foundation (appointed)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer)
Igor Fedorenko Sonatype (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer) Y
Achim Loerke BREDEX (Strategic Developer) Y
(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

  • Reminder M3 due next week.

Juno

  • SR2 to get active in January

Kepler

Kepler Requirements Planning

Discuss requirements. Changes or clarifications needed? Or, approve "as is", unchanged from Juno?
  • We will formally "approve for Kepler" at our December meeting, though we believe the document is pretty much ok as-is.
  • One question that came up was "What does the API requirement mean, exactly?" (where projects must document their API policy and their use of non-API from other projects). The brief answer was "we leave it up to each project, we don't police it". But that the purpose is so that adopters can better understand what is considered API ... that they might want to use ... and/or if a project is "API clean" with respect to its use of code from other Eclipse projects. This in turn led to a brief discussion of "if we don't enforce it, is it really a requirement", but that applies to all the items in the "Required for good adoption" section of the document. I think still valuable to have that section since it means it would be a legitimate bug if an adopter asked a project "what is your API policy" or pointed out in a bug "you use non-API from project B which prevents us from doing X". If/when/how the project "fixes" those bugs is still up to them, but they would valid bugs and it would be incorrect for a "Simultaneous Release Project" to say "Invalid bug, we don't care about that".
    TODO: Ian will see if wording can be clarified/improved or if current wording suffices.
  • Another comment came up on the "greediness" requirement. It is thought the Sim. Rel. requirement is correct as written, but that the community (and ourselves) need more education on why it is important ... that is, why use "greedy=false" for runtime optional bundles. I think that one reason is that users (and adopters) may not want to include those things that are installed simply as function of what repository they point p2 at, but, maybe more important, that if such as "optional but greedy" requirement pulled in an additional bundle (or bundles) that it would be impossible for an adopter to provide a "feature patch" for those optional bundles ... if those optional bundles just so happened cause some critical issue in their product for a customer. This should all be confirmed and if confirmed some encouraging, educational reminders be given to the participating projects. But, at the moment, it is not thought the wording in requirements document needs changing (i.e. if a project refuses to go along, they would not be denied participation).
  • The document could be "polished" and some of the "removed" requirements (which are currently in strike-out font) be literally removed ... while "changes" are interesting going from one year to the next, we don't need to maintain that "history" forever.

Other Business

  • Any discussion about bug 392098 - Include workswith in simultaneous release?
I closed as "won't fix", but glad to hear any further discussion or opinions.
No discussion and Steffen confirmed all is well and the clarification appreciated.
  • There was a problem for one member getting in through the "North America" number for Asterisk service. Just kept getting busy signal for 10 or 12 minutes.

Next Meeting

  • December 5, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).


Reference

Kepler Wiki page
Juno Wiki page
Planning Council/Indigo retrospective
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Copyright © Eclipse Foundation, Inc. All Rights Reserved.