Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/March 03 2010"
(→Helios) |
(→Helios) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 24: | Line 24: | ||
| Chris Aniszczyk | | Chris Aniszczyk | ||
| Technology (PMC) | | Technology (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| John Arthorne | | John Arthorne | ||
| Eclipse (PMC) | | Eclipse (PMC) | ||
− | | | + | | R |
|- | |- | ||
| Oliver Cole | | Oliver Cole | ||
| Tptp (PMC) | | Tptp (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Brian Payton | | Brian Payton | ||
| Datatools (PMC) | | Datatools (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| <del>Doug Gaff</del> ??? | | <del>Doug Gaff</del> ??? | ||
Line 44: | Line 44: | ||
| Anthony Hunter | | Anthony Hunter | ||
| Tools (PMC) | | Tools (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Oisin Hurley | | Oisin Hurley | ||
| Stp (PMC) | | Stp (PMC) | ||
− | | | + | | R |
|- | |- | ||
| Ed Merks | | Ed Merks | ||
| Modeling (PMC) | | Modeling (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Thomas Watson | | Thomas Watson | ||
| Rt (PMC) | | Rt (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| David Williams | | David Williams | ||
| WTP (PMC) (appointed Chair) | | WTP (PMC) (appointed Chair) | ||
− | | | + | | Y |
|- | |- | ||
| Gary Xue | | Gary Xue | ||
| Birt (PMC) | | Birt (PMC) | ||
− | | | + | | Y |
|} | |} | ||
Line 73: | Line 73: | ||
| Cedric Brun | | Cedric Brun | ||
| OBEO (Strategic Developer) | | OBEO (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| Stefan Daume | | Stefan Daume | ||
| Cloudsmith Inc.(Strategic Developer) | | Cloudsmith Inc.(Strategic Developer) | ||
| | | | ||
− | |- | + | |- |
| Neil Hauge | | Neil Hauge | ||
| Oracle (Strategic Developer) | | Oracle (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| Kaloyan Raev | | Kaloyan Raev | ||
| SAP AG (Strategic Developer) | | SAP AG (Strategic Developer) | ||
− | | | + | | R |
|- | |- | ||
| Markus Knauer | | Markus Knauer | ||
| Innoopract (Strategic Developer) | | Innoopract (Strategic Developer) | ||
− | | | + | | R |
|- | |- | ||
| Christian Kurzke | | Christian Kurzke | ||
| Motorola (Strategic Developer) | | Motorola (Strategic Developer) | ||
− | | | + | | |
|} | |} | ||
Line 102: | Line 102: | ||
| Wayne Beaton | | Wayne Beaton | ||
| Eclipse Foundation (appointed) | | Eclipse Foundation (appointed) | ||
− | | | + | | |
|- | |- | ||
| Mike Milinkovich | | Mike Milinkovich | ||
Line 141: | Line 141: | ||
== Galileo == | == Galileo == | ||
− | Assessment of SR2 | + | Assessment of SR2 |
Potential (near?) negative impact on adopters: | Potential (near?) negative impact on adopters: | ||
− | : Some "late" | + | :Some "late" |
− | :: Modeling EMF ?CDO? missed deadline | + | ::Modeling EMF ?CDO? missed deadline |
− | :: DTP final zips late (sort of)? | + | ::DTP final zips late (sort of)? |
− | : Not all projects had maintenance/rebuilds (do we need to explicitly "plan" for that?) | + | :Not all projects had maintenance/rebuilds (do we need to explicitly "plan" for that?) |
− | :: EclipseLink (thought they would not need an SR2, but after all decided they will need maintenance ... in March or so! ... apparently, this team has pattern of creating their service release shortly after the rest of us release?) | + | ::EclipseLink (thought they would not need an SR2, but after all decided they will need maintenance ... in March or so! ... apparently, this team has pattern of creating their service release shortly after the rest of us release?) |
− | :: PDT (PHP Tools) didn't have an SR2, but I saw one user on mailing list saying "he sure thought they needed one, based on important fixes made in Helios, that could be back ported ... its a long time to wait" (I've no idea if he was accurate ... just raising as an example that caught my attention). | + | ::PDT (PHP Tools) didn't have an SR2, but I saw one user on mailing list saying "he sure thought they needed one, based on important fixes made in Helios, that could be back ported ... its a long time to wait" (I've no idea if he was accurate ... just raising as an example that caught my attention). |
− | :: Potential for some Orbit Jars to not be consistent in some packages vs. others, if not everyone re-builds or re-packages. (Just one or two substantial changes, this time, but all others changed signatures). | + | ::Potential for some Orbit Jars to not be consistent in some packages vs. others, if not everyone re-builds or re-packages. (Just one or two substantial changes, this time, but all others changed signatures). |
− | :: There were nearly equal numbers of projects that supplied service, vs. those that did not | + | ::There were nearly equal numbers of projects that supplied service, vs. those that did not |
:::service released in SR2 | :::service released in SR2 | ||
Line 179: | Line 179: | ||
:::#swordfish.build | :::#swordfish.build | ||
:::#tptp.build | :::#tptp.build | ||
− | :::#webtools.build | + | :::#webtools.build |
:::no service released with SR2 | :::no service released with SR2 | ||
− | :::#buckminster.build | + | :::#buckminster.build |
− | :::#dsdp-tm.build | + | :::#dsdp-tm.build |
− | :::#emf-cdo.build | + | :::#emf-cdo.build |
− | :::#emf-compare.build | + | :::#emf-compare.build |
− | :::#emf-emf.build | + | :::#emf-emf.build |
− | :::#emf-net4j.build | + | :::#emf-net4j.build |
− | :::#emf-teneo.build | + | :::#emf-teneo.build |
− | :::#emf-transaction.build | + | :::#emf-transaction.build |
− | :::#emft-ecoretools.build | + | :::#emft-ecoretools.build |
− | :::#emft-mint.build | + | :::#emft-mint.build |
− | :::#emft-mwe.build | + | :::#emft-mwe.build |
− | :::#m2m-qvtoml.build | + | :::#m2m-qvtoml.build |
− | :::#m2t-xpand.build | + | :::#m2t-xpand.build |
− | :::#mat.build | + | :::#mat.build |
− | :::#mdt-ocl.build | + | :::#mdt-ocl.build |
− | :::#mdt-uml2.build | + | :::#mdt-uml2.build |
− | :::#mdt-uml2tools.build | + | :::#mdt-uml2tools.build |
− | :::#mdt-xsd.build | + | :::#mdt-xsd.build |
− | :::#pdt.build | + | :::#pdt.build |
− | :::#riena.build | + | :::#riena.build |
:::#tmf-xtext.build | :::#tmf-xtext.build | ||
+ | <br> | ||
− | : Any other concerns with SR2? | + | :Any other concerns with SR2? |
− | Good things: | + | Good things: |
− | : Maintained "old" content (SR1) in repository (in addition to new) | + | :Maintained "old" content (SR1) in repository (in addition to new) |
− | : Rolled out P2 artifacts before P2 metadata (instead of artifacts and metadata visible at same time) | + | :Rolled out P2 artifacts before P2 metadata (instead of artifacts and metadata visible at same time) |
− | : Any other positive things with SR2 to document? | + | :Any other positive things with SR2 to document? [''mk - it went smoother than every other release before.'']<br> |
+ | |||
+ | ''Notes from meeting: '' No particular concerns, except Anthony and Ed both commented that in the cases they were aware of, "no service release" was just because there wasn't any bugs, that had been requested for that service release. Even GEF was almost "no service" with only one bug fixed. GMF, on the other hand, had many requests. | ||
== Helios == | == Helios == | ||
Line 225: | Line 228: | ||
* Also, do we agree that projects in release train can omit feature update URL? if they would like to? (since the common release repository URL is built into platform). We need less "repository locations" clutter. Risk is it would be a little harder to provide off-cycle maintenance (users would need to add project location to their list) for those projects deciding not to provide their own URL. They would, still, need to provide their own repository (since that's where central one is created from) just not name it in the feature.xml. | * Also, do we agree that projects in release train can omit feature update URL? if they would like to? (since the common release repository URL is built into platform). We need less "repository locations" clutter. Risk is it would be a little harder to provide off-cycle maintenance (users would need to add project location to their list) for those projects deciding not to provide their own URL. They would, still, need to provide their own repository (since that's where central one is created from) just not name it in the feature.xml. | ||
+ | |||
+ | ''Notes from meeting: '' General agreement this was a good thing to do, and dw to write up for further review and/or (optional) adoption. | ||
=== Cross-Project Teams === | === Cross-Project Teams === | ||
Line 246: | Line 251: | ||
Comments? Ok to move forward? Does anyone prefer Plan B or Plan C? | Comments? Ok to move forward? Does anyone prefer Plan B or Plan C? | ||
+ | |||
+ | ''Notes from meeting: '' Council thought it was good and near ready. A few might review a bit more and have comments later, to be mailed to planning list. Tom and Oliver had suggestions for improvements, which I captured as follows, and forwarded to Gabe: | ||
+ | |||
+ | 1. Make the three main sections look more like sections (as it is, sort of looks like just another item). | ||
+ | |||
+ | For example, perhaps indent the items 3 or 5 spaces from left and right margins (leaving the headings and | ||
+ | their text as they are, flush with margins)? Also, perhaps use larger font for the three section "headings"? | ||
+ | |||
+ | 2. At the very top, perhaps even above the "tracking project" line, put some explanation, and handy links. | ||
+ | |||
+ | Here's what I think it should be: | ||
+ | |||
+ | This form is to track progress towards the yearly <a href="http://wiki.eclipse.org/Helios/Simultaneous_Release_Plan">Simultaneous Release</a>, | ||
+ | for those project that have stated their intent and agreement to be part of that release. Projects (usually the Project Lead) should document their | ||
+ | progress here, on meeting the <a href="http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php">requirements for the Simultaneous Release</a>. | ||
+ | Questions on how to complete the form can be asked on the <a href="mailto:cross-project-issues-dev@eclipse.org">cross-project list</a>. Suggestions for improving the form or process | ||
+ | (or cross-project bugs) can be opened on the | ||
+ | <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community;component=Cross-Project">cross-project bugs component</a>. | ||
+ | Bugs on this form itself can be opened on the <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community;component=Portal">Foundation Portal component</a>. | ||
== ToDo Items == | == ToDo Items == |
Latest revision as of 14:50, 3 March 2010
Contents
Logistics
Meeting Title: | Planning Council Conference Call |
Date & Time: | Wednesday, March 03, 2010, 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
Assessment of SR2
Potential (near?) negative impact on adopters:
- Some "late"
- Modeling EMF ?CDO? missed deadline
- DTP final zips late (sort of)?
- Not all projects had maintenance/rebuilds (do we need to explicitly "plan" for that?)
- EclipseLink (thought they would not need an SR2, but after all decided they will need maintenance ... in March or so! ... apparently, this team has pattern of creating their service release shortly after the rest of us release?)
- PDT (PHP Tools) didn't have an SR2, but I saw one user on mailing list saying "he sure thought they needed one, based on important fixes made in Helios, that could be back ported ... its a long time to wait" (I've no idea if he was accurate ... just raising as an example that caught my attention).
- Potential for some Orbit Jars to not be consistent in some packages vs. others, if not everyone re-builds or re-packages. (Just one or two substantial changes, this time, but all others changed signatures).
- There were nearly equal numbers of projects that supplied service, vs. those that did not
- service released in SR2
- actf.build
- birt.build
- cdt.build
- dltk.build
- dsdp-tm.build
- dtp.build
- ecf.build
- eclipselink.build
- ep.build
- epp-udc.build
- equinox.build
- gef.build
- gmf.build
- jwt.build
- m2m-atl.build
- m2t-jet.build
- mylyn.build
- rap.build
- stp.build
- subversive.build
- swordfish.build
- tptp.build
- webtools.build
- no service released with SR2
- buckminster.build
- dsdp-tm.build
- emf-cdo.build
- emf-compare.build
- emf-emf.build
- emf-net4j.build
- emf-teneo.build
- emf-transaction.build
- emft-ecoretools.build
- emft-mint.build
- emft-mwe.build
- m2m-qvtoml.build
- m2t-xpand.build
- mat.build
- mdt-ocl.build
- mdt-uml2.build
- mdt-uml2tools.build
- mdt-xsd.build
- pdt.build
- riena.build
- tmf-xtext.build
- Any other concerns with SR2?
Good things:
- Maintained "old" content (SR1) in repository (in addition to new)
- Rolled out P2 artifacts before P2 metadata (instead of artifacts and metadata visible at same time)
- Any other positive things with SR2 to document? [mk - it went smoother than every other release before.]
Notes from meeting: No particular concerns, except Anthony and Ed both commented that in the cases they were aware of, "no service release" was just because there wasn't any bugs, that had been requested for that service release. Even GEF was almost "no service" with only one bug fixed. GMF, on the other hand, had many requests.
Helios
- Common repository naming/structure bug 291637
- I want to recommend "guidelines" that may become "required" next year (but not for Helios) but some, such as webtools, may move to it this release:
- ... structure of .../<project>/repository/<release>/[SRn | datetimestamp]/
- ... naming in feature URL would be (only) .../<project>/repository/<release>/
- where 'project' is high level project (Top level? except Tools and Technology? ... or request even Tools and Technology to have central one, or at least part of name and/or structure?
Such as /tools/gef/repository/helios/ ? - where 'release' is Yearly Release Name (e.g. 'helios') ... only for those in yearly release. Others would need to use some version number. (reserving yearly release name, for only those in yearly release).
- where 'project' is high level project (Top level? except Tools and Technology? ... or request even Tools and Technology to have central one, or at least part of name and/or structure?
- Also, do we agree that projects in release train can omit feature update URL? if they would like to? (since the common release repository URL is built into platform). We need less "repository locations" clutter. Risk is it would be a little harder to provide off-cycle maintenance (users would need to add project location to their list) for those projects deciding not to provide their own URL. They would, still, need to provide their own repository (since that's where central one is created from) just not name it in the feature.xml.
Notes from meeting: General agreement this was a good thing to do, and dw to write up for further review and/or (optional) adoption.
Cross-Project Teams
Aggregation
Planning Council/Cross Project Teams/Aggregation
Previously mentioned planned meeting didn't happen ... and after some email exchanges, nothing concrete seemed needed right away, except ....
We will encourage people to test Galileo to Helios upgrade, but not do anything to enable that to be "automatic". See or comment in bug bug 303583.
New question: Should we require projects to specify version numbers in .build file?
- Technically, if omitted, then simply "highest" one is retrieved from repository. That can be good, easier, but a little less error checking and record of what was intended.
Tracking progress and compliance
Review readiness of current version on Portal
Comments? Ok to move forward? Does anyone prefer Plan B or Plan C?
Notes from meeting: Council thought it was good and near ready. A few might review a bit more and have comments later, to be mailed to planning list. Tom and Oliver had suggestions for improvements, which I captured as follows, and forwarded to Gabe:
1. Make the three main sections look more like sections (as it is, sort of looks like just another item).
For example, perhaps indent the items 3 or 5 spaces from left and right margins (leaving the headings and their text as they are, flush with margins)? Also, perhaps use larger font for the three section "headings"?
2. At the very top, perhaps even above the "tracking project" line, put some explanation, and handy links.
Here's what I think it should be:
This form is to track progress towards the yearly <a href="http://wiki.eclipse.org/Helios/Simultaneous_Release_Plan">Simultaneous Release</a>, for those project that have stated their intent and agreement to be part of that release. Projects (usually the Project Lead) should document their progress here, on meeting the <a href="http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php">requirements for the Simultaneous Release</a>. Questions on how to complete the form can be asked on the <a href="mailto:cross-project-issues-dev@eclipse.org">cross-project list</a>. Suggestions for improving the form or process (or cross-project bugs) can be opened on the <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community;component=Cross-Project">cross-project bugs component</a>. Bugs on this form itself can be opened on the <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community;component=Portal">Foundation Portal component</a>.
ToDo Items
- create (and update) helios container plan (Wayne (re) volunteered)
- provide concrete instructions for (new) license-consistency requirement ... before M6? (John Arthorne).
- coordinate community input for next year's name (Oliver says last year this was started "shortly before EclipseCon" ... so now's the time!.
Other business
- Reminder: face-face EclipseCon meeting 2:00 to 3:00 (local time) on the Sunday before EclispeCon (3/21) in the Bayshore room of the Hyatt Santa Clara.
- Followed by "joint meeting" with other councils.
Next Meeting
- EclispeCon 3/21 2:00 PM Pacific Time, in the Bayshore room of the Hyatt Santa Clara
- April 7, Wednesday, Noon Eastern Time.
Reference
Simultaneous Release Roles and Simultaneous Release Roles/EMO