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"
m |
(→Galileo) |
||
| Line 78: | Line 78: | ||
| Cloudsmith Inc.(Strategic Developer) | | Cloudsmith Inc.(Strategic Developer) | ||
| | | | ||
| − | |- | + | |- |
| Neil Hauge | | Neil Hauge | ||
| Oracle (Strategic Developer) | | Oracle (Strategic Developer) | ||
| Line 85: | Line 85: | ||
| Kaloyan Raev | | Kaloyan Raev | ||
| SAP AG (Strategic Developer) | | SAP AG (Strategic Developer) | ||
| − | | | + | | <br> |
|- | |- | ||
| Markus Knauer | | Markus Knauer | ||
| Innoopract (Strategic Developer) | | Innoopract (Strategic Developer) | ||
| − | | | + | | <br> |
|- | |- | ||
| 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 | + | :: 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 | ||
| − | |||
| − | :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? |
== Helios == | == Helios == | ||
| Line 219: | Line 218: | ||
* Common repository naming/structure {{bug|291637}} | * Common repository naming/structure {{bug|291637}} | ||
| − | : I want to recommend "guidelines" that may become "required" next year (but not for Helios) | + | : I want to recommend "guidelines" that may become "required" next year (but not for Helios) |
| − | : | + | : I want to recommend naming of /<project>/repository/<release>/[SRn | datetimestamp]/ |
| − | + | :: where 'project' is high level project (Top level? except Tools and Technology?) | |
| − | :: where 'project' is high level project (Top level? except Tools and Technology? | + | :: where 'release' is Yearly Release name ... only for those in yearly release. |
| − | :: where 'release' is Yearly Release | + | |
| − | * Also, do we agree that projects in release train can omit feature update URL | + | * Also, do we agree that projects in release train can omit feature update URL, if they would like to (since the common one 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). |
=== Cross-Project Teams === | === Cross-Project Teams === | ||
| Line 233: | Line 231: | ||
[[Planning Council/Cross Project Teams/Aggregation]] | [[Planning Council/Cross Project Teams/Aggregation]] | ||
| − | Previously | + | Previously planned meeting didn't happen ... and after some email exchanges, nothing concrete seemed needed. |
| − | |||
| − | |||
| − | |||
| − | |||
==== Tracking progress and compliance ==== | ==== Tracking progress and compliance ==== | ||
| Line 248: | Line 242: | ||
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? | ||
| − | == | + | == Other business == |
| − | * | + | * Reminder: face-face EclipseCon meeting 2:00 to 3:00 (local time) on the Sunday before EclispeCon (3/21). |
| + | * TODO: I need to get/send room. | ||
| + | * Followed by "joint meeting" with other councils. | ||
| − | + | == ToDo Items == | |
| − | + | (volunteers welcome) | |
| − | = | + | *create (and update) [http://www.eclipse.org/projects/project-plan.php?projectid=helios 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). |
| − | * | + | |
| + | *provide concrete instructions for (new) license-consistency requirement (John Arthorne). | ||
== Next Meeting == | == Next Meeting == | ||
| − | : EclispeCon 3/21 2:00 PM Pacific Time | + | : EclispeCon 3/21 2:00 PM Pacific Time |
:[[Planning_Council/April_07_2010|April 7, Wednesday]], Noon Eastern Time. | :[[Planning_Council/April_07_2010|April 7, Wednesday]], Noon Eastern Time. | ||
Revision as of 09:49, 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?
Helios
- Common repository naming/structure bug 291637
- I want to recommend "guidelines" that may become "required" next year (but not for Helios)
- I want to recommend naming of /<project>/repository/<release>/[SRn | datetimestamp]/
- where 'project' is high level project (Top level? except Tools and Technology?)
- where 'release' is Yearly Release name ... only for those in yearly release.
- Also, do we agree that projects in release train can omit feature update URL, if they would like to (since the common one 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).
Cross-Project Teams
Aggregation
Planning Council/Cross Project Teams/Aggregation
Previously planned meeting didn't happen ... and after some email exchanges, nothing concrete seemed needed.
Tracking progress and compliance
Review readiness of current version on Portal
Comments? Ok to move forward? Does anyone prefer Plan B or Plan C?
Other business
- Reminder: face-face EclipseCon meeting 2:00 to 3:00 (local time) on the Sunday before EclispeCon (3/21).
- TODO: I need to get/send room.
- Followed by "joint meeting" with other councils.
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).
- provide concrete instructions for (new) license-consistency requirement (John Arthorne).
Next Meeting
- EclispeCon 3/21 2:00 PM Pacific Time
- April 7, Wednesday, Noon Eastern Time.
Reference
Simultaneous Release Roles and Simultaneous Release Roles/EMO