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.

Juno

Kepler

Kepler Requirements Planning

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.