Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/November 07 2012"
(initial draft) |
(→Other Business) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 46: | Line 46: | ||
| Steffen Pingel | | Steffen Pingel | ||
| Mylyn (ALM) PMC | | Mylyn (ALM) PMC | ||
− | | | + | | Y |
|- | |- | ||
| Brian Payton | | Brian Payton | ||
Line 66: | Line 66: | ||
| Ian Bull | | Ian Bull | ||
| Rt (PMC) | | Rt (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| David Williams | | David Williams | ||
| WTP (PMC) (appointed Chair) | | WTP (PMC) (appointed Chair) | ||
− | | | + | | Y |
|- | |- | ||
| Gary Xue | | Gary Xue | ||
Line 90: | Line 90: | ||
| Neil Hauge | | Neil Hauge | ||
| Oracle (Strategic Developer) | | Oracle (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| Kaloyan Raev | | Kaloyan Raev | ||
Line 102: | Line 102: | ||
| Markus Knauer | | Markus Knauer | ||
| Innoopract (Strategic Developer) | | Innoopract (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| Achim Loerke | | Achim Loerke | ||
| BREDEX (Strategic Developer) | | BREDEX (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| (PMC rep) | | (PMC rep) | ||
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 151: | Line 150: | ||
* [[SimRel/Simultaneous_Release_Requirements]] | * [[SimRel/Simultaneous_Release_Requirements]] | ||
− | : | + | : 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 == | ||
− | * | + | * 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 == | == Next Meeting == |
Latest revision as of 14:16, 7 November 2012
Contents
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:
|
Members and Attendees
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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.
- 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".
- 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).