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/January 05 2011
Contents
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
Strategic Reps
Appointed
|
Inactive
|
Announcements
- Welcome and introduce new members ...
- 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.
- remember to aggregate project tracking, IP logs, docuware, etc., and update project meta-data as Wayne requested in cross-project note.
- 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
- See also Indigo Wiki page
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...
- Response: (from email discussion with master webmaster, Denis)
- 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
Simultaneous Release Roles and Simultaneous Release Roles/EMO