Jump to: navigation, search

Difference between revisions of "Planning Council/January 05 2011"

(Other business)
(Attendees)
 
(5 intermediate revisions by the same user not shown)
Line 24: Line 24:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| N
 
|-
 
|-
 
| John Arthorne
 
| John Arthorne
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
Line 40: Line 40:
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Anthony Hunter  
 
| Anthony Hunter  
 
| Tools (PMC)  
 
| Tools (PMC)  
|  
+
| N
 
|-
 
|-
 
| Adrian Mos  
 
| Adrian Mos  
Line 52: Line 52:
 
| Ed Merks  
 
| Ed Merks  
 
| Modeling (PMC)  
 
| Modeling (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Thomas Watson  
 
| Thomas Watson  
 
| Rt (PMC)  
 
| Rt (PMC)  
|  
+
| Y
 
|-
 
|-
 
| David Williams  
 
| David Williams  
 
| WTP (PMC) (appointed Chair)  
 
| WTP (PMC) (appointed Chair)  
|  
+
| Y
 
|-
 
|-
 
| Gary Xue  
 
| Gary Xue  
 
| Birt (PMC)  
 
| Birt (PMC)  
|  
+
| Y
 
|}
 
|}
  
Line 73: Line 73:
 
| Cedric Brun  
 
| Cedric Brun  
 
| OBEO (Strategic Developer)  
 
| OBEO (Strategic Developer)  
|  
+
| N
 
|-
 
|-
 
| Stefan Daume  
 
| Stefan Daume  
 
| Cloudsmith Inc.(Strategic Developer)  
 
| Cloudsmith Inc.(Strategic Developer)  
|  
+
| N
 
|-  
 
|-  
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
 
| SAP AG (Strategic Developer)  
 
| SAP AG (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Pascal Rapicault  
 
| Pascal Rapicault  
 
| Sonatype (Strategic Developer)  
 
| Sonatype (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Markus Knauer
 
| Markus Knauer
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|  
+
| N
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
 
| Motorola (Strategic Developer)  
 
| Motorola (Strategic Developer)  
|  
+
| N
 
|-
 
|-
 
| Achim Loerke
 
| Achim Loerke
 
| BREDEX (Strategic Developer)
 
| BREDEX (Strategic Developer)
|
+
| Y
 
|}
 
|}
  
Line 170: Line 170:
 
* Approved? exceptions for projects joining (late) in M5 (remember, if any of these projects do not make M5, new exceptions should be requested for M6).  
 
* Approved? exceptions for projects joining (late) in M5 (remember, if any of these projects do not make M5, new exceptions should be requested for M6).  
  
: [http://www.eclipse.org/jubula/ Jublula]
+
: [http://www.eclipse.org/jubula/ Jubula] ''Achimim reports "on track" for M5''
: [http://www.eclipse.org/proposals/tools.windowbuilder/ Window Builder] (see also [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05064.html intro msg on cross-project list])
+
: [http://www.eclipse.org/proposals/tools.windowbuilder/ Window Builder] (see also [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05064.html intro msg on cross-project list]) ''realistic for M5?''
: [http://www.eclipse.org/proposals/tools.rat/ Runtime Analysis Tools] (see also [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05100.html intro msg on cross-project list])
+
: [http://www.eclipse.org/proposals/tools.rat/ Runtime Analysis Tools] (see also [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05100.html intro msg on cross-project list]) ''realistic for M5?''
: [http://www.eclipse.org/proposals/libra/ Enterprise Tools for OSGi (tm) Service Platform]
+
: [http://www.eclipse.org/proposals/libra/ Enterprise Tools for OSGi (tm) Service Platform] ''Kaloyan reports unlikely for M5, "just being realistic". We'll re-assess at 2/2 meeting for M6.''
: [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05177.html Subversive]?
+
: [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05177.html Subversive]? ''concerns expressed: inconsistent and unpredictable and unresponsive ... they likely need "help" from their PMC?''
: [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05133.html GMF Tooling (GMF Codegen)?]
+
: [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05133.html GMF Tooling (GMF Codegen)?] ''Ed reports it is believed its releng woes are being addressed, but doesn't know detailed status ... there are people, but maybe not yet required skills?  ... it would be disruptive if not in release (some do depend on it) ... and, obviously, disruptive if they continue to "break the build".'' 
 +
 
 +
:: ''The Planning Council formally approved exceptions for all 6 of the above projects; joining Indigo Release, in M5 ... but, with concerns expressed (summarized above), and much discussed. In particular, it is not believed to be realistic for those new projects still being reviewed and provisioned, especially those with large, existing code bases (can they even get through IP review?). We discussed alternatives, such as them joining in Indigo SR1. Also, we reminded ourselves projects can "release" with Indigo, but not be part of the common repository ... fewer requirements on them, in that case ... and users just have to get that code/function from those project's own sites, instead of central repo. The excellent point was made that its not just a matter of "mechanics" of getting things done in time, but also getting adequate "community review and testing". For an example (just as an example) would the "window builder" play well with others, or subtly change the behavior of Java Editor? And it might be just fine to "change behavior" ... but, need adequate community review and testing '''before''' being released to know if its ok, or not. There might be willingness to allow late comers to M6 ... but, beyond that, other alternatives (SR1, or project-only repos) would likely be preferable solutions. It mostly comes down to how "disruptive" they are ... disruptive to end-users, or disruptive to other projects trying to build/aggregate/release. In the code/benefit curve, it was acknowledge there is great benefit ... but not above all cost. So, while we approve for M5 ... we expect we will be discussing more at future meetings.''
  
 
* remember to aggregate project tracking, IP logs, docuware, etc., and [[Development_Resources/HOWTO/Project_Meta-Data| update project meta-data]] as Wayne requested in [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05063.html cross-project note].
 
* remember to aggregate project tracking, IP logs, docuware, etc., and [[Development_Resources/HOWTO/Project_Meta-Data| update project meta-data]] as Wayne requested in [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05063.html cross-project note].
Line 207: Line 209:
 
::: There is no way to monitor/track CPU Utilization "by project".  
 
::: There is no way to monitor/track CPU Utilization "by project".  
 
::: Specific advice to minimize risk (riskiest usage):  
 
::: Specific advice to minimize risk (riskiest usage):  
::::Building only when needed,  
+
::::Building only when needed, [and, '''testing''' only when needed].
 
::::not running too many builds concurrently,  
 
::::not running too many builds concurrently,  
 
::::avoid scanning the file system for nothing (by using find, or chmod * -R for instance),  
 
::::avoid scanning the file system for nothing (by using find, or chmod * -R for instance),  
Line 214: Line 216:
 
::::respecting the [http://wiki.eclipse.org/Image:Build_infra_layout.png Server Storage chart],  
 
::::respecting the [http://wiki.eclipse.org/Image:Build_infra_layout.png Server Storage chart],  
 
::::avoiding hogging all the RAM...
 
::::avoiding hogging all the RAM...
 +
 +
:::''As Eclipse Leaders, we need to infuse "efficient use of resources" in our development culture ... but, as Planning Council, no known actions.'' 
 +
:::''The "cloud computing" solution was discussed and questioned ... wondering if it was technically feasible, with security concerns, and all. It was suggested that more hardware might be "easier" to make use of than "the cloud". Although that sounds like a challenging dare for someone with cloud computing solutions to prove or show case. (hint hint :)''
  
 
== ToDo Items ==
 
== ToDo Items ==

Latest revision as of 14:47, 5 January 2011

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, January 05, 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) N
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) X
Mik Kersten Mylyn (ALM) PMC R
Brian Payton Datatools (PMC) Y
Anthony Hunter Tools (PMC) N
Adrian Mos SOA (PMC) R
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) N
Stefan Daume Cloudsmith Inc.(Strategic Developer) N
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer) Y
Pascal Rapicault Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) N
Christian Kurzke Motorola (Strategic Developer) N
Achim Loerke BREDEX (Strategic Developer) Y

Appointed

Wayne Beaton Eclipse Foundation (appointed) R


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

  • Welcome and introduce new members ...
Jubula Project
  • Others? (that is, who am I missing?)

Maintenance Schedule

Helios SR2

2/25/2011 (Fourth Friday of February)

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

RC1 is getting near ... warmup RC week of 1/17 - 1/21.

Indigo Status

  • nearing M5
  • Approved? exceptions for projects joining (late) in M5 (remember, if any of these projects do not make M5, new exceptions should be requested for M6).
Jubula Achimim reports "on track" for M5
Window Builder (see also intro msg on cross-project list) realistic for M5?
Runtime Analysis Tools (see also intro msg on cross-project list) realistic for M5?
Enterprise Tools for OSGi (tm) Service Platform Kaloyan reports unlikely for M5, "just being realistic". We'll re-assess at 2/2 meeting for M6.
Subversive? concerns expressed: inconsistent and unpredictable and unresponsive ... they likely need "help" from their PMC?
GMF Tooling (GMF Codegen)? Ed reports it is believed its releng woes are being addressed, but doesn't know detailed status ... there are people, but maybe not yet required skills? ... it would be disruptive if not in release (some do depend on it) ... and, obviously, disruptive if they continue to "break the build".
The Planning Council formally approved exceptions for all 6 of the above projects; joining Indigo Release, in M5 ... but, with concerns expressed (summarized above), and much discussed. In particular, it is not believed to be realistic for those new projects still being reviewed and provisioned, especially those with large, existing code bases (can they even get through IP review?). We discussed alternatives, such as them joining in Indigo SR1. Also, we reminded ourselves projects can "release" with Indigo, but not be part of the common repository ... fewer requirements on them, in that case ... and users just have to get that code/function from those project's own sites, instead of central repo. The excellent point was made that its not just a matter of "mechanics" of getting things done in time, but also getting adequate "community review and testing". For an example (just as an example) would the "window builder" play well with others, or subtly change the behavior of Java Editor? And it might be just fine to "change behavior" ... but, need adequate community review and testing before being released to know if its ok, or not. There might be willingness to allow late comers to M6 ... but, beyond that, other alternatives (SR1, or project-only repos) would likely be preferable solutions. It mostly comes down to how "disruptive" they are ... disruptive to end-users, or disruptive to other projects trying to build/aggregate/release. In the code/benefit curve, it was acknowledge there is great benefit ... but not above all cost. So, while we approve for M5 ... we expect we will be discussing more at future meetings.
  • Any concrete ideas on how to improve aggregation timing or workflow? If so, please comment in bug 332942 ... or, should I close it as "won't fix"?

Indigo Plan and Schedule

Other business

  • 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.
Response: (from email discussion with master webmaster, Denis)
No resources to do "cloud computing" (unless, someone donates it).
In current system, greatest bottlenecks will be hard disk access: "Everyone pulling CVS/SVN/Git files, writing to /shared, uploading to downloads, and so on takes a toll on disk performance. The separation of anonymous/external pserver to another dataset will likely help tons."
There is no way to monitor/track CPU Utilization "by project".
Specific advice to minimize risk (riskiest usage):
Building only when needed, [and, testing only when needed].
not running too many builds concurrently,
avoid scanning the file system for nothing (by using find, or chmod * -R for instance),
building during off-peak hours (Fridays, weekend),
minimizing disk operations (copies, moves, deletes, zip, caching 3rd party dependencies, etc),
respecting the Server Storage chart,
avoiding hogging all the RAM...
As Eclipse Leaders, we need to infuse "efficient use of resources" in our development culture ... but, as Planning Council, no known actions.
The "cloud computing" solution was discussed and questioned ... wondering if it was technically feasible, with security concerns, and all. It was suggested that more hardware might be "easier" to make use of than "the cloud". Although that sounds like a challenging dare for someone with cloud computing solutions to prove or show case. (hint hint :)

ToDo Items

  • It is time? ==> Note from Wayne, to Wayne: (from previous meeting) Remember to review plans starting after M4 (at latest) so questions can be clarified before "road map" produced.
  • Was there a note for this item? 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.
  • TODO (from previous meeting): dw to add/create add a FAQ item around "what to handle 3.7 vs. 4.1". Will draw from previous working notes.
  • New TODO?: Need common pages for a) plans b) migration c) N&N?
A contributor (Hendy.rainbowpurple.com) added these for Eclipse project to Indigo Wiki Page ... but, shouldn't we have central page, with potential for each project to add links to their plans, migration guides, and N&N? Is there a better way?

Next Meeting

February 2, 12 noon Eastern

Reference

Planning_Council/Helios_retrospective

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO