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.

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.

Indigo Plan and Schedule

Other business

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),

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.

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?