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/December 02 2009
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, December 02, 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
Strategic Reps
Appointed
|
Inactive
|
Galileo
?
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
- each Top Level Project committing to watch after their own fledgling projects.
- 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.
- 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)
- create (and update) helios container plan (Wayne (re) volunteered)
- 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
Simultaneous Release Roles and Simultaneous Release Roles/EMO