Difference between revisions of "Planning Council/September 02 2009"

Latest revision as of 09:20, 3 September 2009

Logistics

Attendees

Inactive Members

Galileo SR1

Any issues?

none report at meeting

Helios

Goals

• Simultaneous Release of participating projects

• Includes Simultaneous Milestones and testing (within the defined windows)

• Improve Eclipse by having extra release criteria

• These criteria, as previous years, need general agreement, and buy-in from all projects represented by Planning Council.
• The criteria are primarily in the interest of Strategic Members to improve adoption, and in most cases benefits end-users as well.

• Provide a "Common Discovery" repository, primarily for end-users, so they can explore and discover interesting and useful function, without having to try so hard.

• This improves "early testing" of Projects, and eases migration to the new release.

• (new?) Provide a single code repository for extenders and committers to ease their development.

• Is this one we really want to support? As committers, we often lean this way ... but, it is more work to do right, and in some cases can be at odds with the "ease of use" goal of a repository for end-users.

At meeting, this last item raised little discussion. Someone will need to champion it for us to add as a goal.

Items to improve this year?

• the aggregation process (previously misnamed "the build").
• accessibility
• capabilities: definitions, reuse, and contribution process?

Note: This item was questioned "is it really needed" ... "are any adopters making use of it". The answer from most on PC was "no, not using". One said "yes, but just rolls their own, just uses to run off some UI". One (ok, me) said "yes, we'd like to, for complicated, large installs of multiple products with optional pieces, but is currently unworkable". It appeared no one else on the call was aware of the "progressive discovery" aspect of capabilities (which would be the one requiring the most work from cooperating projects).

• Structure and content of Common Discovery Site (e.g. categories, classifications, allowable content)

• minimal IDE runtimes vs. distributions for extenders
• how to distinguish and organize IDE functional tools from runtime targets
• four divisions required? code, source, end-user doc, extender (sdk) doc

• How to track compliance?

• bugzilla vs. web app?
• Granularity of tracking (sub-Projects vs. Top Level Projects)?

This last item (how to track) generated the most controversy. Several thought the bugzilla system wasn't great, but not sure bad enough to invest in improvements. But, several thought "was terrible" and unworkable. As someone who had to monitor all 33 "projects" I agree its unworkable and not very meaningful. Conclusion: needs work.

• Quick notes of comments from others at meeting

• Doug

none, except that he didn't want to go first :)

• Neil

The "must do" issue, and noted there are some items already in the "feedback notes" from last year.

• Tom Watson

IP. How to avoid mistakes, like the "mis-release" of one project last year, which had to be removed.

Wayne mentioned he knew this was an issue and he has an agreement with IP team to do more "manual" checking of IP logs compared to distributions. But more work needed to better automate. Also mentioned more could be done by mentors and PMC. wtb For completeness, when an IP Log is submitted, I download the latest milestone build from the submitting project and compare the contents of that file with the log. I work with the project to resolve any discrepancies before greenlighting the IP team to do their review. IMHO, this is very late in the process; we need to make sure that problems are resolved earlier in the process. Perhaps we can draw on the Architecture Council mentors, and/or the PMCs to help

• Brian Payton

Was interested in marking bundles as 'code', 'source', 'documentation' to improve ease of installs.

Most concerned with API compatibility and binary compatibility. I suggested adding a 'release criteria' that (at least) projects must document their policy.

• John Arthorne

bugzilla tracking was awkward

better document "why" important (John volunteered!), such as "here's why it is in your best interest".

We will need all projects to use some new "standard" license to property fit into new install dialogs (which groups items by license, to make that agreement step easier (or feasible?).

• Chris

API tools and usage scans should be a "must do" (boos broke out in the virtual room). :)

PDE team can help incorporate this in builds/tests (another volunteer!)

• Kaloyan

would like to see easier updates from one release to another.

p2 errors are obscure

• Stefan

Would like to see structure of common discovery site improved (was that another volunteer?)

• Cedric

Would like to see more testing of packages fitting together, such as ui consistency, functional testing, etc.

• Oisin

ease pain of 'compliance' of must do items

he would like building-in api and usage tools (as a should-do item)

• Ed

Can't burden projects with more 'must do' items (but ok to ask to document items).

• Wayne

Granularity is problematic. Last year, "number of" projects was 33 vs. 51 depending on how you counted.

IP compliance issues. Would be better if logs were earlier.

My note after meeting: perhaps we could have more checking on a milestone-by-milestone basis? Especially if "diffs" could be generated automatically?

Proposed (initial) process

• Continuous Milestones (beginning with M1)
• Form cross-project teams to come up with recommendations for Planning Council

• Anyone can participate, but I'd like to be only on invitation from Planning Council, to be sure we have a balanced, but diverse representation that mirrors the composition of the Planning Council.
• Planning council to act on those recommendations (one way or another).

• Not only better document and clarify criteria, but also refine their measuremet when possible (so, not just "yes or no', but, when possible "poor, medium, excellent", for example).
• Require a "planned compliance" statement as part of the "standard plan"? Not discussed at meeting. I doubt it would be useful wihtout a vastly improved "tracking" system, which will be hard enough to implement. 

Proposed (initial) Cross-Project Teams

Aggregation

John Arthorne (Platform)

Thomas Hallgren (Buckminster)

Accessibiity

Tammy Strum (IBM)

Neil Hauge (Oracle)

Kaloyan Raev (SAP)

ACTF (they will decide exactly who later this week)

Capabilities

Tim deBoer (IBM/WTP)

Oleg Besedin (Platform)

Structure of Common Discovery Site

?

How to track

?

Helios Dates

This info is here for reference. (It was previously approved by PC). Will be moved to 'release document' soon.

M1 8/7 - 8/21

M2 9/18 - 10/2

Initial standard-format plans due 10/2

M3 10/30 - 11/13

M4 12/11 - 12/18 [note: beginning of 1 week windows]

M5 1/29 - 2/5 [seven week span from M4, to account for end-of-year holidays]

M6 3/12 - 3/19

EclipseCon 3/22 - 3/25

M7 4/30 - 5/7 [seven week span from M6, to account for EclipseCon]

Release: 6/23/2010 (4th Wednesday of June)

Notes regarding the +0, +1, +2, +3, EPP, and 'available' days

• The first three milestones use a two-week window and the remaining milestones use 1-week windows.
  
• The sub-deadline patterns within the windows are as follows:
  

• This pattern was arrived at with a couple of considerations: a) it is very important that teams have a consistent rhythm (so, for example, easier for a team to "always deliver on Tuesday" rather than Monday's some milestones, Thursdays other milestones, etc. b) it represents the latest possible time to produce common-discovery site ... teams can, still, either on their own or work with other projects to do their final builds earlier, making their delivery available earlier to specific teams or test groups.
• Remember, the +n categories represent latest possible time to complete what is required of common discovery site (generally, at noon, Eastern time, of the day). Teams have to do their builds and testing before these common-site deadlines.
• In general, teams often have complicated inter-dependencies which are not captured by the simple "+1", "+2" descriptions. In those cases, it is up to those projects to work out their detailed inter-dependencies and agree to a processes to satisfy what they need from each other. The dates and deadlines listed by Planning Council, apply only to the final deliverable to the common repository.

Review Planning Council/Galileo postmortem

We'll continually review the list of comments to make sure issues are addressed, action plans made, owners found, etc.

ToDo Items

(volunteers welcome)

• create (and update) helios container plan (Wayne volunteered)

• coordinate community input for next year's name

Next Meeting

October 7, Wednesday, Noon Eastern Time.

Reference

Helios Simultaneous Release

Planning Council Members

Simultaneous_Release_Roles and Simultaneous_Release_Roles/EMO