Planning Council/November 10 2010
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, November 3, 2010, at 1600 UTC / 1200 Eastern|
|Dial-in:||For the call-in numbers, see the "Project Review" number on Foundation Portal page.|
PMC (and Strategic) Reps
2/25/2011 (Fourth Friday of February)
For detailed RC schedules, see Service Release Schedule in master plan
Indigo Plan and Schedule
- Discuss "once in always in". Is there a proposal to change this?
Suggestions during (previous) meeting:
- Make explicit that to be in repo, feature includes must be strict, so installs or builds are reproducible. (Even if there might eventually be improvements that allow additional features, with loose constraints ... but "minimum" requirement is the strict inclusion. Unclear what loose requirement solution will be. Note: the strict requirements are the way things are currently done ... just best to make explicit, since it has come up before.
- Move capabilities to "good citizen" section (and check wording to make clear that to document "not supported" is one option ... or, possibly "we don't know what this means" :).
- Consistent license. No real change to requirement, but should provide pointers to bugs where standard "user agreement" may change (to include EDL) and where p2 may be improved to allow pointer to URI ... or something.
- Add a "must do" to be in EPP package, must run on/test on Eclipse 3.7.
- Add a "should do" to have a 4.1 theme item in plan to describe what project is doing for 4.1 (and give some examples).
Tracking "setup" required from Foundation in bug 321522
See initial Indigo Wiki page
Review: There is a subtle implication of specifying Java 6 as "minimum runtime" requirement. Currently, we require contributors to use Java 5 when using pack200, since if not, and if involves a jar that contains no Java (e.g. source or documentation) then it can not be unpacked with Java 5, Java 6 would be required. This has been a headache for people since for many it means tweaking build scripts so an "old" (1.5) VM is used for that one step. During aggregation, we purposely use Java 5 to catch errors in this regard. For Indigo, I propose we not worry about being consistent here, and just use Java 6 during aggregation. Some projects may still want to use 1.5 VMs to do their pack200 ... if their adopters want it ... but I see no reason for mass consistency here ... if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent?
- Some concern expressed, but mostly a matter of letting people know and documenting options. For example, for projects that want compatibility with VMs less than 1.6, they still can, of course, but will no longer get "built in" test from aggregation. Plus, should make clear, even a VM less than 1.6 can still use a pack200 (or, an unpack200 executable) from another VM, such as a 1.6 distribution, and specify it on their command line using
Issues and Proposal for 3.7 versus 4.1
- See working notes in http://wiki.eclipse.org/Indigo/HowToAddress37And41Platform
- We were reminded Mylyn is Top Level project now, and we should be sure to invite rep to Planning Council.
- John mentioned Platform may drop Motif support from swt ... decision not final yet, and not sure if it effects any adapters or members ... just giving a heads up
- Note from Wayne, to Wayne: (actually from last meeting) Remember to review plans starting after M4 (at latest) so questions can be clarified before "road map" produced.
- Wayne teased us all with promise of new tools to check CQs against downloads, which we projects can use ourselves ... but he wasn't ready to tell us about them today and he'll be saying more over next few days or weeks.
- dw to sort out tracking path.
November 3, 12 noon Eastern