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/August 7 2013"
(→Members and Attendees) |
(→Luna Planning) |
||
| Line 145: | Line 145: | ||
* Is there confusion/contradictions about "unreleased components in Sim. Rel. repo"? See {{bug|411977}}. | * Is there confusion/contradictions about "unreleased components in Sim. Rel. repo"? See {{bug|411977}}. | ||
: For reference, see [[SimRel/Simultaneous_Release_FAQ#Can_a_Simultaneous_Release_project_include_bundles_or_features_from_a_project_not_in_the_Simultaneous_Release.3F| current policy]]. | : For reference, see [[SimRel/Simultaneous_Release_FAQ#Can_a_Simultaneous_Release_project_include_bundles_or_features_from_a_project_not_in_the_Simultaneous_Release.3F| current policy]]. | ||
| − | + | ::''It was thought this one deviation was a "fluke" and no systematic action needed; that for the most part, everyone understands'' | |
| + | :''a) can't release code under another project's namespace (can "include" it, if previously released) | ||
| + | :''b) if unreleased code is desired to use (it is, after all, EPL) you must "refactor" it into your own namespace, following the usual rules of attribution, maintaining copyright info, etc.'' | ||
* Are we "too lax" in versioning requirements? Especially for "maintenance"? See [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09221.html cross-project list posting]. [To be honest, I do not recall what specific situation this is about?] | * Are we "too lax" in versioning requirements? Especially for "maintenance"? See [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09221.html cross-project list posting]. [To be honest, I do not recall what specific situation this is about?] | ||
| − | + | ::''Ed explained the situation to us (involving versioning issues between XText and UML2) and it too sounded like a rare case that did not need to be "policed". But does highlight the importance of correct semantic versioning.'' | |
* I have started scheduling Luna milestones. I think first 4 or 5 will be similar to previous years. | * I have started scheduling Luna milestones. I think first 4 or 5 will be similar to previous years. | ||
: * Appears that timing of EclipseCon in 2014 may effect how M6 is scheduled. It comes "the last week" of what would | : * Appears that timing of EclipseCon in 2014 may effect how M6 is scheduled. It comes "the last week" of what would | ||
normally be M6, instead of M6 finishing first. | normally be M6, instead of M6 finishing first. | ||
: * See [[Luna/Simultaneous_Release_Plan]]. | : * See [[Luna/Simultaneous_Release_Plan]]. | ||
| + | ::''Most favored completing M6 before EclipseCon, even though that is the "API Freeze milestone". DW to workout that schedule in time for reps to review with their projects before September meeting (and alternatives, if any seem to exist).'' | ||
* Can/should Planning Council say projects "should" contribute source to common repo? Or continue to "leave it up to projects" to decide? | * Can/should Planning Council say projects "should" contribute source to common repo? Or continue to "leave it up to projects" to decide? | ||
| Line 157: | Line 160: | ||
:: Possibly {{bug|414262}} | :: Possibly {{bug|414262}} | ||
:: [Remember, we should make this decision based on principle, not the one request for an "Ultimate Package" ({{bug|414025}}), since a) we should always work on principles!, and b) this package may or may not come to fruition.] | :: [Remember, we should make this decision based on principle, not the one request for an "Ultimate Package" ({{bug|414025}}), since a) we should always work on principles!, and b) this package may or may not come to fruition.] | ||
| − | + | :::''It was generally felt we should continue status quo of "leaving it up to project" ... let their adopters and community drive any changes needed/desired. Primarily, simply not to "add process or rules" to what many think is already too many rules nad processes and additionally, it was commented, it is hard to "draw the line" ... what about "types of documentation", or "examples" ... i.e. there is no one answer that fits all projects.'' | |
* Discuss more frequent "(un?) coordinated releases" or updates to common repo or updates to EPP packages. (Doug, Ian). | * Discuss more frequent "(un?) coordinated releases" or updates to common repo or updates to EPP packages. (Doug, Ian). | ||
: See Ian's summary at http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02168.html. | : See Ian's summary at http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02168.html. | ||
Revision as of 23:55, 7 August 2013
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, August 07, 2013, at 1200 Noon Eastern |
| Dial in: | (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)
Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)
|
Members and Attendees
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.
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
D = delegated
X = not expected
Announcements
- New Member: Dani Megert is now the Eclipse PMC representative to the Planning Council. Thanks to John for years of service. Thanks Dani for volunteering to take his place.
Luna Planning
- Is there confusion/contradictions about "unreleased components in Sim. Rel. repo"? See bug 411977.
- For reference, see current policy.
- It was thought this one deviation was a "fluke" and no systematic action needed; that for the most part, everyone understands
- a) can't release code under another project's namespace (can "include" it, if previously released)
- b) if unreleased code is desired to use (it is, after all, EPL) you must "refactor" it into your own namespace, following the usual rules of attribution, maintaining copyright info, etc.
- Are we "too lax" in versioning requirements? Especially for "maintenance"? See cross-project list posting. [To be honest, I do not recall what specific situation this is about?]
- Ed explained the situation to us (involving versioning issues between XText and UML2) and it too sounded like a rare case that did not need to be "policed". But does highlight the importance of correct semantic versioning.
- I have started scheduling Luna milestones. I think first 4 or 5 will be similar to previous years.
- * Appears that timing of EclipseCon in 2014 may effect how M6 is scheduled. It comes "the last week" of what would
normally be M6, instead of M6 finishing first.
- * See Luna/Simultaneous_Release_Plan.
- Most favored completing M6 before EclipseCon, even though that is the "API Freeze milestone". DW to workout that schedule in time for reps to review with their projects before September meeting (and alternatives, if any seem to exist).
- Can/should Planning Council say projects "should" contribute source to common repo? Or continue to "leave it up to projects" to decide?
- See thread around http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09506.html
- Possibly bug 414262
- [Remember, we should make this decision based on principle, not the one request for an "Ultimate Package" (bug 414025), since a) we should always work on principles!, and b) this package may or may not come to fruition.]
- It was generally felt we should continue status quo of "leaving it up to project" ... let their adopters and community drive any changes needed/desired. Primarily, simply not to "add process or rules" to what many think is already too many rules nad processes and additionally, it was commented, it is hard to "draw the line" ... what about "types of documentation", or "examples" ... i.e. there is no one answer that fits all projects.
- Discuss more frequent "(un?) coordinated releases" or updates to common repo or updates to EPP packages. (Doug, Ian).
- See Ian's summary at http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02168.html.
- For some fun reading, I looked up the original bug on how we got to the names of "SR1/SR2" .. bug 227767
- For reference, see current policy.
- Doug also wants to discuss him taking over the "releng role" and do aggregation builds using Maven/Tycho.
- The focus is still on projects providing OSGi bundles in p2 repos, right? No matter what technology they used to get there?
- What type of "input" is required?
- What type of "testing" is done that all is well formed and can be installed together and is repeatable?
- In particular, how are "IDE" vs "runtime only" components treated separately?
- What are concrete advantages?
Progress on Action Items
- Editing of "Requirements Document"? (Dani and Neil)
- GSoC project for "Development Channel"? (Wayne)
- Improved "aggregator examples/doc". (dw -- no progress).
- But, about to send out "aggregator builds and streams ready" message ... depending on outcome of other items.
- [Orbit plan "by end of August". (dw -- no progress -- will likely be late, still "in September")]
Kepler Retrospective
- Propose to start in August (if any extra time), finish in September.
Next Meeting
- September 4, 2013 - Regular First Wednesday Meeting
Reference
- EclipseCon face-to-face follow-through action items. For original meeting notes, see Planning_Council/March_24_2013 and for discussion leading to action items, see Planning_Council/April_10_2013. For last status update, see Planning_Council/May_8_2013.