Planning Council/November 04 2009

From Eclipsepedia

Jump to: navigation, search

Contents

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, October 07, 2009, at 1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin
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) y
Brian Payton Datatools (PMC)
Doug Gaff Dsdp (PMC)
Anthony Hunter Tools (PMC) y
Oisin Hurley Stp (PMC) y
Ed Merks Modeling (PMC) y
Thomas Watson Rt (PMC) y
David Williams WTP (PMC) (appointed Chair) y
Gary Xue Birt (PMC)

Strategic Reps

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

Appointed

Wayne Beaton Eclipse Foundation (appointed) y
Mike Milinkovich 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

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.


Galileo

Build has been broken for a long time. I've just opened bug 294158. Please make sure Galileo stays build-able ... without waiting for me to open a bug! :)

Notes: Anthony moved bug to Buckminster, says they are depending on Helios version.

Helios

Criteria and Process

Discuss Eclipse Simultaneous Release Document.

(It is in cvs repo /cvsroot/org.eclipse in www/helios)

Notes from today's (11/4) meeting:

  • Issue of "maturity" was discussed at length. There was concern this would lead to a "graduation game" where people wanted to graduate just to be on the yearly train. Surprisingly, there is some confusion, or different ideas, as to what "graduation" means, especially with respect to "release 1.0". Some projects do not find it unusual for a project to incubate for years, and in once case, for a mature project to depend on an incubating project. [Problems not to be solved here].
  • The end of "maturity" discussion was not to require graduation, but
  1. each Top Level Project committing to watch after their own fledgling projects.
  2. if a project ... especially an incubating project ... is having trouble making deadlines, or repeatedly break builds, (such as 3 to 5 times) then they should be promptly removed, or disqualified from the train, and their PMC would need to follow the PC exception process if they wanted them back in.
  3. suggestion made to change wording or emphasis of document, where appropriate, to speak of "responsible project" instead of "mature project".
  • It was brought up (again) how important it is to not delete bundles from a repo once they are there. I referred them to bug 291848. (And while a belated suggestion is better than none, I think its funny how (now, imagine the music here) "... you don't know what you got till its gone." with apologies to Carly Simon :)).

Notes from previous meeting:

  • Sounds like the "mature only" item will get some discussion. Some pointed out it encourages and trains projects as they are learning. One pointed out they are a lot of work :) (i.e. break the builds most often, etc.) Some mentioned it may motivate them to do what's required to graduate instead of floating along in incubation. It was also mentioned that Eclipse as a whole is getting mature enough that there are lots of mature projects and that should be the focus of the common discovery site. (There were not that many mature projects, or incubating projects, a few years ago when we first agreed to let in incubating projects. No one mentioned a need from strategic members (or, perhaps, if they do, just a 'release' is enough, no need for common repository?). It was also mentioned that, some believe, what is in the common discovery repository should be the best that Eclipse has to offer for casual end-users who are "just exploring" and should not be a place for "marketing" or "experimental prototypes". There should be other mechanisms for those things.
  • It was mentioned that the "web app" method of tracking items seemed to some people like "creating a new tool when bugzilla is available with no investment". But, bugzilla is too hard to use and create reports for and create initial items, according to others views. But, it does depend on how much effort it would take to create the web-app. So, that's the next step. It was also suggested (by the same person :) that the "exception process for criteria items" be incorporated into the web-app so it's all documented in the same place. (To illustrate, you could document exceptions in bugzilla, but it would be hard to pull that data out of bugzilla, without a bunch of error prone conventions).
  • There was some discussion of just how immutable repositories should be, with no particular conclusion. I did open bug 291637 for related issues.
  • Overall, seemed most like new structure and avoidance of "must do/should do" terminology.

Proposed (initial) Cross-Project Teams

Aggregation

John Arthorne (Platform)
Thomas Hallgren (Buckminster)

Accessibiity

See Planning_Council/Cross_Project_Teams/Accessibility

Notes: Kaloyan summarized recommendation (see end of wiki page).

Capabilities

Tim deBoer (IBM/WTP)
Oleg Besedin (Platform)

Structure of Common Discovery Site

users vs. extenders (minimum runtimes vs. SDKs)
runtime targets vs. tools
hierarchical categories (are more levels required?)

How to track

Web App (form based). Need concrete proposal for sizing.

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)

ToDo Items

(volunteers welcome)

  • coordinate community input for next year's name (Oliver says last year this was started "shortly before EclipseCon" ... so, no rush).

Next Meeting

November 4, Wednesday, Noon Eastern Time.

Reference

Helios Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO