Planning Council/November 09 2011
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, November 09, 2011, at 1200 Eastern|
|Dial-in:||For the call-in numbers, see the "Project Review" number on Foundation Portal page.|
Members and Attendees
Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, 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
X = not expected
Juno Plan and Requirements
- Any issues?
Review Requirements for substance and wording. In particular:
I. The three new major headings. Do they make it clear some are A. "normal" requirements (just needed earlier), B. some are required items to be in common repo, and C. some are essentially optional, though considered required for good adoption.
II. 4 new items, all marked (currently) with "[added 10/18/2011]"
A. Source build. (this turned out to be wordier than I'd like ... suggestions welcome ... is it worth having?)
B. Platforms and Java Levels. (tried to add some general advice, to especially help new projects, but no substantial "new work" ... just to encourage teams to think through and document what they support).
C. Getting source from repositories. I'd like to make it "required" to use Eclipse-SourceReference, but there was some discussion on cross-project list that not everyone liked that idea. So, tried to word so that "its a good idea, and if you don't use Eclipse-SourceReference, you should provide some other easy way".
D. Provide archived p2 repositories. Again, I personally think this should be "required", but am not positive how many other projects do (I know many provide them already), and can not say for sure we would use them in the aggregation builds for Juno, so not sure it should be "required" this year ... but, it would go a long way towards having "reproducible aggregation builds". Plus, my speculative guess is, something like archived repos might be required for Eclipse LTS (Long Term Support), both to have something to depend on to re-create some packages, but more so, to be sure there is a concrete deliverable from a build against which future builds could be compared.
III. Other requirements?
IV. Other clarifications?
Checklist (aka tracker)
Investigate if checklist can be improved and who can do it.
Any discussion or suggestions of "delegation policy".
- December 7, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).