Difference between revisions of "Planning Council/November 10 2010"

From Eclipsepedia

Jump to: navigation, search
(Other business)
(Other business)
Line 199: Line 199:
 
** Consider other measures such as reducing continuous or regular builds during milestone periods?
 
** Consider other measures such as reducing continuous or regular builds during milestone periods?
  
: ''There was agreement this might become a problem, but not sure if it currently is, and not sure what to do about it if/when it becomes a problem. 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.''
+
: ''There was agreement this might become a problem, but not sure if it currently is, and not sure what to do about it if/when it becomes a problem. ''
 +
 
 +
:''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}}. ''
 
* ''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}}. ''

Revision as of 17:16, 10 November 2010

Contents

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, November 10, 2010, at 1200 Eastern
Dial-in: For the call-in numbers, see the "Project Review" number on Foundation Portal page.

Attendees

PMC (and Strategic) Reps

Chris Aniszczyk Technology (PMC) Y
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) X
Mik Kersten Mylyn (ALM) PMC
Brian Payton Datatools (PMC) Y
Anthony Hunter Tools (PMC) Y
Oisin Hurley Stp (PMC)
Ed Merks Modeling (PMC) Y
Thomas Watson Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC) Y

Strategic Reps

Cedric Brun OBEO (Strategic Developer)
Stefan Daume Cloudsmith Inc.(Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Kaloyan Raev SAP AG (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) R
Christian Kurzke Motorola (Strategic Developer)

Appointed

Wayne Beaton Eclipse Foundation (appointed)


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

Inactive

 ? Nokia (Strategic Developer) X
 ? CA Inc. (Strategic Consumer) X
 ? brox IT-Solutions GmbH (Strategic Developer) X


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.



Announcements

  • Eclipse Platform has officially stopped building AIX Motif and Linux Motif.

Maintenance Schedule

Helios SR2

2/25/2011 (Fourth Friday of February)

For detailed RC schedules, see Service Release Schedule in master plan


Indigo Status

M3 coming together roughly, but good part of that is at least people are contributing/participating.

Indigo Plan and Schedule

All agreed it was 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?
  • Discuss "once in always in". Is there a proposal to change this?
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.


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 -Dorg.eclipse.update.jarprocessor.pack200.

Issues and Proposal for 3.7 versus 4.1

Other business

  • TODO: I (dw) agreed to make initial +1, +2, ... table for project signup.
  • 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, but not sure if it currently is, and not sure what to do about it if/when it becomes a problem.
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.

ToDo Items

  • 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.

Next Meeting

November 3, 12 noon Eastern

Reference

Planning_Council/Helios_retrospective

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO