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.
Planning Council/December 01 2010
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, December 01, 2010, at 1200 Eastern|
|Dial-in:||For the call-in numbers, see the "Project Review" number on Foundation Portal page.|
PMC (and Strategic) Reps
- Announced new members: Mik, Pascal, Adrian
2/25/2011 (Fourth Friday of February)
For detailed RC schedules, see Service Release Schedule in master plan
- nearing M4. Is everyone in? Any known exceptions?
- Kaloyan mentioned OSGi Enterprise Tools project will likely be one exception. Not ready by M4. And while still incubating for Indigo, will (likely) be put forth, later, as an exception to the M4 deadline.
- After the meeting, Pascal mentioned to to me in email that m2e might be delayed due to waiting for some CQs. He should know more next week.
Indigo Plan and Schedule
- Discuss "namespace" issues discussed in bug 330312 and elsewhere.
- Several issues came up: One, more concerned with EDP proposed changes, rather than sim. rel., is that some projects do not use the "org.eclipse" namespace through out ... ETF and AspectJ. That is, there are known exceptions. The issue for Sim. Rel has more to do with "overlapping" or "reusing" someone else's namespace, especially in a common repository.
- While it was acknowledged that "it has happened once", the general feeling of the council was that it is so rare, that rules and procedures did not need to be documented. That is was indeed "common sense" that you can not use someone else's namespace, and we do not need to document such common knowledge or such rare exceptional cases.
- Discuss issue (from last year) ... to what extent should Sim. Rel. materials (checklist) be part of official release docuware.
- It was felt we did not need the "persistence" of a PDF copy and that a link would be nice, but no hard requirement. So, I added this sentence:
"This may be in the form of providing a URL to the checklist, ideally as part of the normal docuware."
- following the original statement:
"In addition to the ordinarily required Release Review Archival Materials, all Projects participating in yearly Release agree to provide a checklist-with-detail form that describes their compliance (or not) with all of the criteria items described in this document."
- Suggestions during (previous) meeting:
- The req. doc was deemed ready, acceptable, with one exception:
- The requirement wording on 'jarred bundles' needs to be improved so no explicit exception required (it is required for any requirement in that section) and to also make it more generic and easier for a project to document why a bundle is not jarred. Or, maybe even detail when it should be documented, and what is an automatically acceptable?
- Proposed new workings to replaces "jarred bundles" paragragh:
Jarred Bundles. Projects must use jarred plug-ins (with unpack=false) unless there are technical reasons not to do so. Also, nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-ins. The OSGi runtime is fine with it but the PDE environment is not able to handle classpaths that contain nested jars. Exceptions to these principles should be documented by the project, so we can learn the reasons and extent of unjarred bundles.
- Discussed "once in always in".
- No proposal to change, but given the discussion and misunderstandings, some wording should be improved, maybe 'once participating, always participating', or 'participation is continuous', or something. Plus, should improve the wording of 'Exception process' to better emphasize its purposes: a) improve communication, b) improve PMCs shepherding their own projects (not the planning council, or planning council chair), and c) be sure decision point is not just one person (the planning council chair) but is instead a group effort.
- Proposed new wording to replace "once in always in" paragraph:
Joining implies continuous participation. After a release, there are two follow on activities that must be planned for. First is that releases maintenance stream. The second is the subsequent year's release. In both cases, it is (as always) up to the project to decide what to fix or what to enhance, but being part of the train implies you will always be able to build, in maintenance and in the subsequent release's milestone builds. Sometimes this means simply leaving repositories intact, etc., but occasionally projects may need to fix "prereqs" or similar. Put another way, being part of the Simultaneous Release is not a "one time" activity, covering only the literal release date and not even a "part time" activity covering only part of the yearly development cycle. Instead it is a commitment to stay "simultaneous" on an on-going basis.
- It was requested to beef up the "communication" aspect better, that if a project is going to drop out, or suspend activities for a long time, they should announce broadly since could effect dependent projects.
- 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
- TODO: the question of "3.7 or 4.1" came up again ... I should add a FAQ item
- TODO: I (dw) agreed to make initial +1, +2, ... table for project signup.
- Done. See Indigo/Participating_Projects
- Eclipse Platform 4.1 must move to be +1 because of dependency on EMF. We should discuss how this will be coordinated because there may eventually be cyclic dependencies (JohnA).
- John opened bug 329935 to see if part of emf could be +0.
- Discussion on build machine QoS (JohnA):
- Is build machine contention/availability currently an issue for projects?
- Do we need to adjust schedules to account for this?
- Consider other measures such as reducing continuous or regular builds during milestone periods?
- There was agreement this might become a problem (has been in the past), but not sure if it currently is, and not sure what to do about it if/when it becomes a problem. Its hard to pick favorite projects or take away resources from some committers ... though is is a shared, constrained resource, so might come to that. And by "take away" it it meant to reduce, have various rules about niceness level that are enforced, etc.
- TODO: I (dw) agreed to ask webmasters if there was some way to see who was using what how much, as improved understanding might lead to better solutions.
- Long term, if it is only a matter of "peak usage", may want to investigate (or, encourage others to investigate:) some sort of "cloud" solution so during final milestone/release weeks we could have 10 slaves, or something, whereas most of the time we just need one or two.
- Tom wondered if we need a "central" patch repository ... that could be "built in" to all versions of Eclipse. It was suggested to try to keep at project level, but agreed, some improvements might make that better. For example, if in EPP packages, there was more than one top level feature? Also, there maybe should be some other attributes identifying patches, such as "security fix", or something ... as some people may want to turn off checking for routine updates, but turning off security fixes should probably be a separate decision, as it is on many OS platforms. I was so excited, I opened bug 329949. Plus, later, I opened bug 329973 to improve the EPP package update story, if possible.
- 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