diff --git a/.github/workflows/check-markdown.yaml b/.github/workflows/check-markdown.yaml new file mode 100644 index 0000000..67b45d4 --- /dev/null +++ b/.github/workflows/check-markdown.yaml @@ -0,0 +1,14 @@ +name: Check Markdown links + +# TODO - once markdown is in a more complete state this can be changed to check all +# files, not just modified ones. See check-modified-files-only too +on: [pull_request] + +jobs: + markdown-link-check: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@master + - uses: gaurav-nelson/github-action-markdown-link-check@v1 + with: + check-modified-files-only: 'yes' diff --git a/wiki/Planning_Council.md b/wiki/Planning_Council.md new file mode 100644 index 0000000..e30ee26 --- /dev/null +++ b/wiki/Planning_Council.md @@ -0,0 +1,149 @@ +# Planning Council Mission + +From the [development +process](http://www.eclipse.org/projects/dev_process/development_process_2010.php#4_8_Councils) +"The Planning Council is responsible for establishing a coordinated +[Simultaneous Release](Simultaneous_Release.md) (a.k.a, "the +release train") that supports the Themes and Priorities in the Roadmap. +The Planning Council is responsible for cross-project planning, +architectural issues, user interface conflicts, and all other +coordination and integration issues. The Planning Council discharges its +responsibility via collaborative evaluation, prioritization, and +compromise." + +# Call and Meeting Schedule + +Planning Council calls take place the first Wednesday of each month. A +Google +[calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York) +is used to manage call dates and times. + +## Logistics + +Join from PC, Mac, Linux, iOS or Android: + + +Or iPhone one-tap : + +`   US: +16699006833,,928841320#  or +14086380968,,928841320# ` + +Or Telephone: + +>   Dial(for higher quality, dial a number based on your current location)： +>       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923  +>       Canada: +1 647 558 0588  +>       France: +33 (0) 1 8288 0188  +>       Germany: +49 (0) 30 3080 6188  +>       United Kingdom: +44 (0) 20 3695 0088  +>       Switzerland: +41 (0) 31 528 0988  +>       Sweden: +46 (0) 8 4468 2488  +>       Denmark: +45 89 88 37 88  +>       Netherlands: +31 (0) 20 241 0288  +>   Meeting ID: 928 841 320 +>   International numbers available: [https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf](https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf)  + + + +

Meetings

+ +


+*For older meetings, see the meeting archives

+


+

+ +


+The calendar is available in the following formats:
+iCal, HTML

+ +# Links + +- [Planning Council Mailing list +archive](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/maillist.html) +- [Index of simultaneous releases](Simultaneous_Release.md) +- [Simultaneous_Release_Roles](SimRel/Simultaneous_Release_Roles.md) + +# Planning Council Makeup + +From the +[Bylaws](http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202011_08_15%20Final.pdf), +the Planning Council is comprised of: +* One representative designated by each Project Management Committee +* Strategic Consumer Members as a group are entitled to elect one +representative +* A Strategic Developer Member that is not leading a PMC, or Strategic +Consumer Member that has eight or more full-time developers assigned to +Eclipse projects, is entitled to designate one representative unless an +employee, officer, director, or consultant of the Member has already +been appointed to the Council. +* Other individuals designated by the Executive Director: +The Planning Council is chaired by a person designated by the Executive +Director. While not explicitly stated in the Bylaws, the Executive +Director supports the idea of an annual rotating chair with each +successor nominated by the Council members. + +The current membership of the Planning Council is listed on [the +councils +page](http://www.eclipse.org/org/foundation/council.php#planning) of the +main website. diff --git a/wiki/Planning_Council/2019-01-09.md b/wiki/Planning_Council/2019-01-09.md new file mode 100644 index 0000000..4190491 --- /dev/null +++ b/wiki/Planning_Council/2019-01-09.md @@ -0,0 +1,154 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Jan 9, 2018, at 11:00 EST one week later than usual

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Temporary Planning Council Chair: Nick Boldt Planning Council Chair: +Melanie Bats (returns Dec 2018) + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Chuck Bridgham) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +Dani, Tom, Martin, Alex, Mélanie. + +## Regrets + +## Agenda + + - Next release update + - JDK Support + +## Notes + +### Next release updates + +M1 for Eclipse SDK will be done this week and the rest of the train will +follow. Lakshmi is in charge of the N\&N page and Sopot continue to be +the coordinative for the release page and in charge of being the link +with the Panning Council. + +### JDK support + +How Java 12 will be provided? It will be provided as the previous +release on the Marketplace. It is too short between the official Java 12 +release and the Release Train to do the change. The platform remains on +Java 8 and 11 which are the LTS versions. The Java 12 will be integrated +in the Release Train for the June release. It will be the same for Java +13. If Java releases continue to be on time, we will discuss whether to +adapt our release plan to fit the Java releases in order to integrate +them. + +## Actions + + - Mélanie : Prepare the schedule for the June & September releases + - Mélanie : Contact Wayne & Nick to get follow-up about the following + actions + +:\* **AI**: Wayne: add item to calendar: validate participation list (on +March 8); repeat for 2019-06 schedule + +:\* **AI**: Wayne document participation validation process + +:\* **AI**: Wayne make sure that aggrcon file touching is a MUST DO in + + +:\* **AI**: Nick to talk to Wayne re: automating the validation process +via a new job/script hosted on simrel JIPP + +:\* **AI**: Nick update wiki re: Jan meeting on 9th, not 2nd (because +NYE / holidays) + +::\* **DONE** + +:\* **AI**: Wayne to remove offsets from project pages, but keep it in +the simrel release req + +:\* **AI**: Wayne to clean up PMC rep list + +:\* **AI**: Wayne prune inactive members, contact members/orgs to find +new participants - + \ No newline at end of file diff --git a/wiki/Planning_Council/2019-02-06.md b/wiki/Planning_Council/2019-02-06.md new file mode 100644 index 0000000..f09ed6c --- /dev/null +++ b/wiki/Planning_Council/2019-02-06.md @@ -0,0 +1,234 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Feb 6, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +## Regrets + +## Agenda + + - Actions follow-up + - Next release update + - WildWebDeveloper project joining March SimRel + - June & September schedules + +## Actions follow-up + +:\* Mélanie : Prepare the schedule for the June & September releases + + - + + - + Added to the call agenda for validation : June + [Plan](https://wiki.eclipse.org/SimRel/2019-06/Simultaneous_Release_Plan) + & September proposal dates + **DONE** + +:\* Mélanie : Contact Wayne & Nick to get follow-up about the following +actions + + - + + - + **DONE** + +:\* Wayne: add item to calendar: validate participation list (on March +8); repeat for 2019-06 schedule + + - + + - + March 8 (Milestone 3) seems too late. Don't recall agreeing to + validate at that point (maybe assemble the list, but we need to + validate sooner than that). + [Post](https://www.eclipse.org/lists/cross-project-issues-dev/msg16380.html) + to cross-project-issues-dev. + **DONE** + +:\* Wayne : document participation validation process + + - + + - + The participation requirements section was updated. A + [note](https://www.eclipse.org/lists/cross-project-issues-dev/msg16359.html) + was sent out to cross-project-issues-dev. + **DONE** + +:\* Wayne : make sure that aggrcon file touching is a MUST DO in + + + - + + - + **DONE** + +:\* **Nick** : to talk to Wayne re: automating the validation process +via a new job/script hosted on simrel JIPP + + - + Bash script used by Wayne, manual process. + - + **DONE** + +:\* **Wayne** to remove offsets from project pages, but keep it in the +simrel release req + + - + Follow up with web dev gays. + - + **DONE** + +:\* Wayne : to clean up PMC rep list + + - + + - + The PMC and Strategic Member representatives are now accurate on + the most recent meeting minutes page. Also added appointed + members. + **DONE** + +:\* Wayne: prune inactive members, contact members/orgs to find new +participants - + + + - + + - + Given the current focus of the Planning Council, Wayne don't + think that we'll be able to get much interest from the companies + and TLPs that are missing representatives. Wayne will ask the + business development folks about whether or not Robert Bosche + might be interested (and maybe CEA List). Eclipse Science may be + interested as well; Wayne will send a note to their PMC list. + Pretty sure that only Adrian Mos is inactive in the current + list. Eclipse SOA should be terminated relatively soon, so just + leave it. + **DONE** + +## Notes + +### Next release update + +Business as usual, M2 on Friday, everything is ok. Tiny little change +Mickaël Istria opened a bugzilla to remove the index.html as now +directory is browsable. It will be removed for the next coming release. +Dani asked if there is some news about marketing activities, if Sopot or +Thabang are taking care of it ? + +### WildWebDeveloper + +WildWebDeveloper project is joining March SimRel in M2. + +### June & September schedules + +Mélanie asked to review the June +[Plan](https://wiki.eclipse.org/SimRel/2019-06/Simultaneous_Release_Plan) +on the wiki & the September proposal dates on the Google calendar. + +### Actions + + - Dani : will send an email to get updates about marketing activities + for 2019-03. + + + + - + **DONE** + + + + - All : Please review the June Plan wiki page and the Google calendar + dates for 2019-09. Mélanie will send an email to ask everyone to + approve the schedule.Actions follow-up + - All : Review the updates done by Wayne on the participation process. \ No newline at end of file diff --git a/wiki/Planning_Council/2019-03-06.md b/wiki/Planning_Council/2019-03-06.md new file mode 100644 index 0000000..70c0117 --- /dev/null +++ b/wiki/Planning_Council/2019-03-06.md @@ -0,0 +1,205 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, March 6, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +Alex, Dani, Wayne, Fred, Mélanie, Thomas, Nitin + +## Regrets + +Nick + +## Agenda + + - Actions follow-up + - Next release update + - June & September schedules + - Wiki updates + +## Actions follow-up + +:\* Dani : will send an email to get updates about marketing activities +for 2019-03. + +:: **DONE** Sopot is taking care of that with the foundation. + +:\* All : Please review the June Plan wiki page and the Google calendar +dates for 2019-09. + +:: **DONE** Mélanie will send an email to ask everyone to approve the +schedule. + +:: **TODO** Review by all + +:: All : Review [SimRel-2019-09 wiki +page](https://wiki.eclipse.org/Category:SimRel-2019-09) + +:: **DONE** by Dani + +:: Mélanie prepare the [SimRel-2019-09 wiki +page](https://wiki.eclipse.org/Category:SimRel-2019-09) + +:: **DONE** + +:\* All : Review the updates done by Wayne on the participation process. + + - + + - + **DONE** + +## Notes + +### Next release update + +Platform ready to release RC2. Orbit URL was not ready, so a rebuild +will be needed but everything is ok. + +### June & September schedules + + - [2019-06](https://wiki.eclipse.org/Category:SimRel-2019-06) + + + + - [2019-09](https://wiki.eclipse.org/Category:SimRel-2019-09) + + + + - For details see the Google calendar : + + + +### Wiki updates + +Mélanie has merged the SimRel FAQs +[Simultaneous_Release_FAQ](https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ) +& +[Simultaneous_Release_Cycle_FAQ](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ) +to only one : + +Auto-redirection was done. + +Mélanie has updated to remove the "yearly" notion: + + +If you detect other wiki pages that should be updated, send an email to +Mélanie. + +### Track inactive projects + +Wayne raises the fact that a handfull of projects are not paying +attention and does not meet the requirements. The idea is that projects +should update their aggrcon file to declare that they are in the SimRel. +If they do not modify their aggrcon, they will be out. Today, Wayne is +taking care of chasing these different projects, pushing a gerrit +request to remove the aggrcon file of these projects and then following +the thread. It is time consuming for him. It was proposed to +automatically declare the project as out if the aggr file was not touch. +That is not so simple as removing a project could have some important +consequences for other projects depending on it. There is a +communication aspect that should be taken into consideration. It was +also proposed to have a clear process to declare the project intent to +be in. It already existed in the past and it was not so successful. The +idea is to trying to identify who is not taking care instead of +punishing everyone with a new process. Fred proposed to assist Wayne on +the aggcon file tracking. Another possibility is to turn off the build a +week before removing them officially, in order to detect the +consequences. + +### Actions + + - Need a chair for the next call on April 3rd, Mélanie will not be + able to organize/join : Martin Lippert proposed to take care of the + call. Thanks again Martin\! + - Mélanie will prepare the plan for the 2019-09 release. + - All : Review the dates for the 2019-06 & 2019-09 and approve by mail + on the mailing list. \ No newline at end of file diff --git a/wiki/Planning_Council/2019-04-03.md b/wiki/Planning_Council/2019-04-03.md new file mode 100644 index 0000000..c25e4e4 --- /dev/null +++ b/wiki/Planning_Council/2019-04-03.md @@ -0,0 +1,123 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 3, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Martin Lippert + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +Only Wayne, Mikaël, Tom and Dani attended. + +## Regrets + +Nitin Dahyabhai, scheduling conflict + +tbd + +## Agenda + + - The opt-in process that we have defined requires that project teams + at least "touch" their aggrcon file once during the release cycle. + - If you excuse Fred's modifications, many project teams did not + engage. + - e.g. BIRT (June 2018), PMF (September 2017) + - What do we do about these projects? + - Is it time to rethink opt-in requirements? + +## Actions follow-up + +tbd + +## Notes + +tbd + +### Actions + +tbd \ No newline at end of file diff --git a/wiki/Planning_Council/2019-06-05.md b/wiki/Planning_Council/2019-06-05.md new file mode 100644 index 0000000..30abde3 --- /dev/null +++ b/wiki/Planning_Council/2019-06-05.md @@ -0,0 +1,136 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 5, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +Dani + +## Regrets + +## Agenda + + - 2019-12 planning + +`-> Google Calendar updated` +`-> Please review the wiki pages :` +` - ` +` - ` + + - Identify and remove inactive projects + - Opt-in rule requires that projects make a change to their + aggrcon file to prove that they're paying attention. + - Based on a quick check, the following aggrcon files haven't been + changed by their project teams in well over a year (changes by + Fred Gurr don't count): + - actf.aggrcon, epp-logging.aggrcon, jwt.aggrcon, + m2t-xpand.aggrcon, PMF.aggrcon, XWT.aggrcon + - Request: PMC representatives investigate their projects to + determine whether or not they should be dropped from the + simultaneous release. + - Opt-in process is flawed + - The back-and-forth to get the participation list right requires + as much work and generates as much churn as the opt-in emails of + the past. + - Do we actually need to maintain a participation list? + - Assuming yes, is there a better way to maintain it? + +## Actions follow-up + +## Notes + +Planning for 2019-12 was reviewed and validated. + +Other topics were not discussed as Wayne was missing. + +### Actions + +No actions required. \ No newline at end of file diff --git a/wiki/Planning_Council/2019-09-04.md b/wiki/Planning_Council/2019-09-04.md new file mode 100644 index 0000000..d13d374 --- /dev/null +++ b/wiki/Planning_Council/2019-09-04.md @@ -0,0 +1,209 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 4, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + + - Nitin Dahyabhai + - Mikaël Barbero + - Wayne Beaton + - Tom Watson + - Martin Lippert + - Fred Gurr + - Mélanie Bats + +## Regrets + + - Ed Merks + +## Agenda + + - Simrel updates & MAc signing + - Discuss 2020-03 & 2020-06 planning + - Managing opt-in/opt-out + - Is the participation page (e.g. + [2019-09](https://projects.eclipse.org/releases/2019-09) + considered useful? + - Planning Council to be removed from the Eclipse Foundation Bylaws + (and EDP) + - Acknowledge that the Planning Council is entirely focused on + Eclipse IDE Simultaneous Release + +## Actions follow-up + +None + +## Notes + +### Simrel update + +RC1 due on friday RC2 next friday Hopefully GA will be ontime + +Some improvements were done on the Simrel wiki pages : + + +### Mac signing + +With the next MacOS release Catalina, each apps need to be authorized +despite we sign the Eclipse bnudle, it is not authorized. It is mostly +fixed for the next release but this means that no previous release will +run on new MacOS. So Mikaël is working on making the mac version being +authorised on Catalina. The latest build runs, there is still more +testing to do. + +### Bylaws + +Planning Council will be removed from the Eclipse Foundation Bylaws (and +EDP). We acknowledge that the Planning Council is entirely focused on +Eclipse IDE Simultaneous Release. So the idea is to move everything +under EPP project and just continue to work as an Eclipse project. Other +working groups are organized differently, they could be inspired by the +IDE Simrel (JakartaEE communities, Science working group) but that's +all. + +### Managing opt-in/opt-out + +Opt-in process is broken, it relies too heavily on Wayne (identifying +not listening projects, contact them, ...) We decided last year to be +based on the touch of the aggr file to determine who's in or out. In +anyway, after few cycles, Wayne thinks that it seems ridiculous. The +question is : do we need opt-in/opt-out ? How could we find how many +projects are listening ? Proposal was done by Nitin to automatize this +based on the PMI. We could add a section to declare that a release is +part of the xxxx-yy Simrel. The purpose is to make sure that projects +pay attention and to prevent that something will not break the build in +last stage. + +We should discuss how to modify PMI ? Mikael proposed also to implement +checks. For example, that verify that a contribition is not older than +one year old, in order to find easily which project needs to be +contacted and see with them if we should remove them ? + +Mélanie asked if Wayne will not be anymore in charge of contacting the +project, who will do that as it seems to be a very consuming task. +Should it be done by the planning council's chair ? Mélanie raised the +fact that she will not have the time to do that alone. So another idea +would be to share this on the planning council members. It was decided +to continue this discussion on the mailing list, Wayne will start at +thread. + +### 2020-03 & 2020-06 schedules + +2020-03 + + - 17/01 M1 + - 07/02 M2 + - 28/02 M3 + - 06/03 RC1 + - 13/03 RC2 + - 13/03 - 17/03 Quiet Period + - 18/03 GA + +Fred: Dates LGTM\! Martin: Dates LGTM\! + +2020-06 + + - 17/04 M1 + - 08/05 M2 + - 29/05 M3 + - 05/06 RC1 + - 12/06 RC2 + - 12/06 - 16/06 Quiet Period + - 17/06 GA + +Martin: Dates LGTM\! + +### Actions + + - Wayne starts a discussion on the mailing list about the + opt-in/opt-out process & who will be in charge of ? + - Mélanie starts a discussion on the mailing list to validate 2020-03 + & 2020-06 schedules \ No newline at end of file diff --git a/wiki/Planning_Council/2019-10-02.md b/wiki/Planning_Council/2019-10-02.md new file mode 100644 index 0000000..54346b9 --- /dev/null +++ b/wiki/Planning_Council/2019-10-02.md @@ -0,0 +1,143 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, October 2, 2019, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + + + +## Attendance + +## Regrets + +## Agenda + + - Simrel updates + - Discuss 2020-03 & 2020-06 planning + - Managing opt-in/opt-out + - Planning Council should move to a project + - Usage of Oomph p2 repo quality report in our release process (see + and + ) + - Enable repo by default + +## Actions follow-up + + - \[Done\] Mélanie starts a discussion on the mailing list for + validation of the 2020-03 and 2020-06 dates + - Wayne starts a discussion on the mailing list about the + opt-in/opt-out process & who will be in charge of ? + +## Notes + +### 2020-03 & 2020-06 schedules + +2020-03 + + - 17/01 M1 + - 07/02 M2 + - 28/02 M3 + - 06/03 RC1 + - 13/03 RC2 + - 13/03 - 17/03 Quiet Period + - 18/03 GA + + + +2020-06 + + - 17/04 M1 + - 08/05 M2 + - 29/05 M3 + - 05/06 RC1 + - 12/06 RC2 + - 12/06 - 16/06 Quiet Period + - 17/06 GA + + + +### Actions \ No newline at end of file diff --git a/wiki/Planning_Council/2020-01-07.md b/wiki/Planning_Council/2020-01-07.md new file mode 100644 index 0000000..cf13886 --- /dev/null +++ b/wiki/Planning_Council/2020-01-07.md @@ -0,0 +1,106 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 8, 2020, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +## Regrets + +## Agenda + + - Simrel updates + - Discuss 2020-09 planning + +## Actions follow-up + +No actions + +## Notes + +### Actions \ No newline at end of file diff --git a/wiki/Planning_Council/2020-01-08.md b/wiki/Planning_Council/2020-01-08.md new file mode 100644 index 0000000..73f455b --- /dev/null +++ b/wiki/Planning_Council/2020-01-08.md @@ -0,0 +1,115 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 8, 2020, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + + - Mélanie Bats + - Martin Lippert + - Dani Megert + +## Regrets + +## Agenda + + - Simrel updates + - Discuss 2020-09 planning + +## Actions follow-up + +No actions + +## Notes + +Mélanie, Dani & Martin discussed the fact to align the SimRel dates with +Jave to be able to release the last Java version support in the Simrel. + +### Actions + +Dani & Mélanie review the next SimRel date to align with Java. \ No newline at end of file diff --git a/wiki/Planning_Council/2020-02-05.md b/wiki/Planning_Council/2020-02-05.md new file mode 100644 index 0000000..0c6a41d --- /dev/null +++ b/wiki/Planning_Council/2020-02-05.md @@ -0,0 +1,137 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 5, 2020, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

US: +16699006833,,928841320# or +14086380968,,928841320#

+

Or Telephone:

+

Dial(for higher quality, dial a number based on your current location)：
+ US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
+ Canada: +1 647 558 0588
+ France: +33 (0) 1 8288 0188
+ Germany: +49 (0) 30 3080 6188
+ United Kingdom: +44 (0) 20 3695 0088
+ Switzerland: +41 (0) 31 528 0988
+ Sweden: +46 (0) 8 4468 2488
+ Denmark: +45 89 88 37 88
+ Netherlands: +31 (0) 20 241 0288
+ Meeting ID: 928 841 320
+ International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Mélanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse Enterprise for Java PMC + - IoT PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Service Oriented Architecture PMC (Adrian Mos) + - Eclipse Technology PMC (Gunnar Wagenknecht) + - Tools Project PMC (Alexander Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Nitin Dahyabhai) + +### Appointed Members + + - Appointed (Mikael Barbero) + - Appointed (Markus Knauer) + - Appointed (Mike Milinkovich) + - Appointed (Sopot Cela) + - Appointed (Wayne Beaton) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +## Regrets + + - Nitin Dahyabhai + +## Agenda + + - Simrel updates + - Discuss 2020-09 planning : Java 15/16 release date? + - Discuss Simrel future + +## Actions follow-up + +Dani & Mélanie review the next SimRel date to align with Java. + +## Notes + + - Schedule 2020-09 + - Please review the 2020-09 schedule available in the Google + Calendar and summarized on the wiki : + + - Align Java release with Eclipse release + - Not to change as Java release dates can't be changed and we + don't want eclipse to change versions due to Java release date + change + - Easier for JDT to ship first on the marketplace so there is a + bit more stabilization time rather than pressure to release + - Simrel 2020-03 + - Small issue with M1 release dates, fixed and in good state now + - M2 seem in good shape + - Jonah will do EPP M2 but no reply from Markus so best effort + from Jonah + - Who does M3? Wait for M2 to see if the actual work expected is + clearer. + - Planning council future + - Working group as a future handling EPP, simrel, installer? + - Rules to be defined by Planning council, deliverables come from + various projects + - Working group is the place to discuss marketplace and other + broader topics not just bring money + - Put current simrel repo and etc in separate project or merge + with EPP? No changes for now. + - EPP project is a project like every other and Planning council + treats it like that, no additional requests + +### Actions \ No newline at end of file diff --git a/wiki/Planning_Council/2020-06-03.md b/wiki/Planning_Council/2020-06-03.md new file mode 100644 index 0000000..4e5daad --- /dev/null +++ b/wiki/Planning_Council/2020-06-03.md @@ -0,0 +1,22 @@ +We had a short meeting today. + +Attendees: + + - Wayne Beaton + - Martin Lippert + - Fred Gurr + - Dani Megert + - Nitin Dahyabhai + - Tom Watson + +The June 2020 simultaneous release is progressing as planned. No current +blocker issues. + +Wayne expressed concern regarding the handful of presumably stable +projects that have not contributed any new versions of their features +for some time. It's not clear that the content is being tested and so +there may be risk that these features will break if they're installed. + +Wayne will assemble a list for the July call and will propose an agenda +item to discuss what, if anything, we should do to qualify continued +participation on the simultaneous release. \ No newline at end of file diff --git a/wiki/Planning_Council/2020-08-05.md b/wiki/Planning_Council/2020-08-05.md new file mode 100644 index 0000000..502e97b --- /dev/null +++ b/wiki/Planning_Council/2020-08-05.md @@ -0,0 +1,31 @@ +Agenda items: + + - I (Wayne) noticed that several of the contributions are more than + one year old (some of them significantly more). I don't believe that + it's necessarily wrong to contribute stable content, but would like + to make sure that somebody is periodically testing configurations + that include these contributions to mitigate the risk that we ship + broken content. + - Eclipse Tools for Cloud Foundry (2018) + - Eclipse BIRT (2017) + - Eclipse Mylyn (2018) + - Eclipse WindowBuilder (early 2019) + - Eclipse Xpand (2016) + - Eclipse Remote Systems Explorer (2018) + - Eclipse EMFStore (2017) + - Eclipse BPMN2 Model (2018) + - Eclipse BPEL Designer (2018) + - Eclipse ACTF (2017) + + + + - Regrets: + - Nitin Dahyabhai (WTP PMC) + +## Notes + + - Eclipse Platform started to provide Linux AArch64 builds in the 4.17 + stream. If a project with native parts wants to add support for it + and lacks access to AArch64 machine for the builds - please contact + Alexander Kurtakov so the current machine can be attached to your + JIPP. \ No newline at end of file diff --git a/wiki/Planning_Council/2020-09-02.md b/wiki/Planning_Council/2020-09-02.md new file mode 100644 index 0000000..077fa43 --- /dev/null +++ b/wiki/Planning_Council/2020-09-02.md @@ -0,0 +1,18 @@ +Attendees: + +Alexander Kurtakov + +Nitin Dahyabhai + +Mélanie Bats + +Notes: + +We had a short meeting today. Mélanie prepared the schedule for the +2020-12 and 2021-03 releases: + + + +This was approved by Fred, Thomas, Alex. If no one send -1 before next +week (09/09/20), it will be considered as approved by the planning +council. \ No newline at end of file diff --git a/wiki/Planning_Council/2021-09-06.md b/wiki/Planning_Council/2021-09-06.md new file mode 100644 index 0000000..38a9aa2 --- /dev/null +++ b/wiki/Planning_Council/2021-09-06.md @@ -0,0 +1,107 @@ +## Notes + +### 2021-09 status + +M2 cancellation good track Jonah still have some issues with signing, +takes a long time to do the signing especially with Mac Other issue with +splashscreen, rebuilt for EPP RC1A by platform team RC2A fixing crash on +windows 10 Should be able to do it for RC2 Bugs open that should be +fixed, Labor day in NA + +### Explains the role and responsibilities of the WG steering committee vs planning council + +Extract from the WG charter: "The Planning Council is responsible for +establishing a roadmap and coordinated release plan that balances the +many competing requirements. The release plan describes the themes and +priorities that focus these releases, and orchestrates the dependencies +among project plans. + +#### Powers and Duties + +The Planning Council is responsible for managing the Eclipse IDE +Simultaneous Release, cross-project planning, facilitating the +mitigation of architectural issues and user interface conflicts, and all +other coordination and integration issues. The Planning Council +discharges its responsibility via collaborative evaluation, +prioritization, and compromise. The Planning Council has the following +responsibilities: + + - Planning and requirements gathering and management; + - Setting the names and dates of Eclipse IDE product releases; + - Setting, evolving, and enforcing the policies and procedures for + participation of Eclipse open source projects that contribute + content to the Eclipse IDE Simultaneous Release; + - Setting, evolving, and enforcing policies and procedures for the + creation and distribution of Eclipse IDE products, along with all + intermediate products; + - Setting, evolving, and enforcing policies and procedures governing + supporting products (e.g., marketplaces, statistics gathering and + data collection services, ...); + - Establishing practices to mitigate risk and ensure overall quality + of the processes and resulting products; + - Providing technical guidance and oversight for the working group’s + projects; + - Establishing developer communication channels; and + - Establishing user support channels." + +The Planning Council should work with the Program Manager as WG SC does +not get involved in execution. + +#### Composition + +Members of the Planning Council are generally senior technical experts. +The Planning Council is composed of: + + - One representative designated by the Project Management Committee + (PMC) for every top level project for which at least one subproject + is a simultaneous release participant; + - One representative designated for each Strategic Member; and + - Additional representatives as approved by the Steering Committee. + +The Planning Council elects a chair of the Planning Council. This chair +is elected among the members of the Council. They will serve from April +1 to March 31 of each calendar year, or until their successor is elected +and qualified, or as otherwise provided for in this Charter. + +#### Discussion + +WG SC purpose supports what the PC does and what the PC proposes, the PC +decides what should be done The Program Manager will not decide, it is +important to make clear that "PC decides", the term manager could be +badly interpreted. The Program Manager job is to take care of each +participants of the simrel, helping all the projects who want being part +of it He has also a release engineer technical role. + +During next steering committee meeting we should clarify: + + - Flow of the power, who decides? Should be express explicitely + - Who really decides what the Program Manager will do ? + - Who will manage him? SC / PC ? + +It is clear for the PC members that the Steering Committee do not want +to take technical decision, this is the PC role? The SC provides High +level statement. The PC refines them as technical things to be done. The +PM job is to do it. This implies a good cooperation between SC and PC. + +### Jar signing + +The WG intent about that is "Build artifacts made available at the +Eclipse Foundation are verifiably the ones built by respective +projects." + +Ed will create a bugzilla about signing in order that everyone will give +his requirements. Then the Planning Council would be able to take a +technical decision. + +### Review Simrel issues list to see what would be the top 3 issues and the actions that should be done + +Please all, review the Simrel issues list to add what is missing +according to the last Simrel 2021-06/2021-09 + + +The spreadsheet will be updated to be able to vote on each issues to +consider which ones are the most important, every PC members will have +1, 2, 3 points to distribute between 3 issues. + +Next call we will discuss the most rated issues to see what actions +would be needed. \ No newline at end of file diff --git a/wiki/Planning_Council/2021-10-06.md b/wiki/Planning_Council/2021-10-06.md new file mode 100644 index 0000000..f347da6 --- /dev/null +++ b/wiki/Planning_Council/2021-10-06.md @@ -0,0 +1,24 @@ +## Notes + +Vote for Jonah Graham as new Planning Council Chair concluded +successfully. + +### SimRel improvements + +Discussions on SimRel improvements list to pass to IDE WG Steering +Committee. Action (Jonah): put together draft of simrel improvements + +### Community Day at EclipseCon + +Action (Jonah): put together talk for community day + +### 2022-03 and 2022-06 Schedule + +Action (Melanie): Give permissions for calendar for schedule update and +point at all the pages Action (Jonah): Put together schedule and +distribute it + +### JarSigning + +Discussions on JarSigning future. Action (Jonah): Send proposal for +1 +to group \ No newline at end of file diff --git a/wiki/Planning_Council/2021-11-03.md b/wiki/Planning_Council/2021-11-03.md new file mode 100644 index 0000000..5bbd016 --- /dev/null +++ b/wiki/Planning_Council/2021-11-03.md @@ -0,0 +1,52 @@ +## Notes + +### Membership + +Welcome Leif Geiger to the planning council meeting. + +Johannes Matheis (representative from Vector) has joined the council and +is expected at the next meeting + +### Actions from last meeting + + - SimRel improvements list distributed to IDE WG Steering Committee + - EclipseCon Community Day presentation completed and delivered + - 2022-03/06 schedule created, voted on and approved + - JarSigning replacement proposal circulated on mailing list + +### Related Technologies Discussion + + - Wayne provided an overview based on his email + - The Marketplace client is an Eclipse Project + - The Marketplace server is software run and maintained by the EF + - There is a new Marketplace client + server in development + - The Marketplace falls under the Planning Council, from the IDE WG + Charter "Setting, evolving, and enforcing policies and procedures + governing supporting products (e.g., marketplaces, statistics + gathering and data collection services, ...);" + - Decided that the Planning Council should request the Steering + Committee spend some specific amount of money to in the short term + address a key problem. e.g. "pay 30 day contract to do X" + - A high priority item would be to clean up the marketplace of + uninstallable content, see + + - Action: Martin will provide a first draft + - Goal: Provide this to the IDE WG Steering Committee by their next + meeting (16 Nov) + +### PGP Signing + + - Red Hat rpm team did a review of PGP signing plan + - The earliest that PGP only signed content can be delivered is after + a full release with the Eclipse Platform / p2 having it implemented + to ensure users who are upgrading are not presented with an unsigned + warning. This means that (for e.g.) if the Eclipse Platform has a + complete implementation in 2021-12 (4.22) the earliest PGP only + signed content can be delivered is 2022-03. + +### CVEs / vulnerabilities + + - CVEs / vulnerabilities were discussed. See + + + \ No newline at end of file diff --git a/wiki/Planning_Council/2021-12-01.md b/wiki/Planning_Council/2021-12-01.md new file mode 100644 index 0000000..fda5684 --- /dev/null +++ b/wiki/Planning_Council/2021-12-01.md @@ -0,0 +1,50 @@ +## Notes + +### 2021-12 release status + + - Discussed PDT + PHP EPP broken issue - see conversations + + and + + - Jonah will work with PDT team (specifically Dawid Pakula) to try + to get respin PDT in for 2021-12 + - If PDT team can't resolve issue in time, Jonah (via Tools PMC) + will request to join PDT as a committer so that a respin can be + done + - We may need to slip the EPP build date to have time to get this + in. No consideration for slipping the release date yet. + +### PGP Signing + + - Platform team plan to have test dependencies in PGP only form from + Maven directly instead of Orbit. This will allow testing install + flow for PGP signed jars. + - IDE WG minutes were shared with Planning Council - see + + - Wayne has volunteered to try and put together the document that is + digestible by the IDE WG and reviewers. The source material is + "Implemented PGP and p2 strategy as alternative to jarsigner" as + initially assembled by Mickael Istria is + + - other sources (some are linked from the document): + - "Build artifacts made available at the Eclipse Foundation are + verifiably the ones built by respective projects." + + - "Support manual (UI) addition/removal of trusted PGP keys" + + - "A way to add trusted PGP keys as update-able extensions" + + - Early discussions on ML + + +### "Top 3 Issues" + + - The discussions from IDE WG were shared with planning council. The + formal minutes of these discussions in the IDE WG should be + published in a couple of weeks. + +### Membership + +The membership of the Planning Council needs a review, but due to lack +of time at this meeting the topic has been delayed until the next +meeting. \ No newline at end of file diff --git a/wiki/Planning_Council/2022-01-05.md b/wiki/Planning_Council/2022-01-05.md new file mode 100644 index 0000000..3544085 --- /dev/null +++ b/wiki/Planning_Council/2022-01-05.md @@ -0,0 +1,27 @@ +## Notes + + - WTP and RAP also make use of Jetty, but more of it than the Platform + does, so they can not rely solely on bundles the Platform and + Eclipse TLP produce in the future with PGP signatures. They are + constrained to keeping the version they use in sync with the + Platform SimRel contribution, even as they have to build and handle + signing of the additional bundles on their own. + + + + - PGP discussions: + - Long discussion on how to present keys/fingerprints to users. + Perhaps a link to a webpage with instructions/etc. + - Various discussions on bugs/improvements that can/need to be + made to p2 and related code. Please see bugzilla for details. + - **Action (Jonah)**: Have a vote on mailing list to make sure we + are on the same page as far as functional complete by 2022-03 + with 2022-06 including PGP signed content. + + + + - 2021-12 Postmortem discussion: + - ECF update means RCP cannot build from simrel alone, needs + Platform - problem may be resolved by 2022-03 M2 (maybe M1 if + fix is adopted soon enough). Httpclient is related to the + problem. \ No newline at end of file diff --git a/wiki/Planning_Council/2022-02-02.md b/wiki/Planning_Council/2022-02-02.md new file mode 100644 index 0000000..417871a --- /dev/null +++ b/wiki/Planning_Council/2022-02-02.md @@ -0,0 +1,28 @@ +## Notes + + - Brief PGP discussion on current state which is positive. See + + for more details. + - Follow up on vote from last meeting was successful with +1 from all + respondents: + + - "Top 3" items now tracked in gitlab: + + - 2022-03 status update: + - MPC is actively working on moving to httpclient5 now that + ECF/platform are using httpclient5 + - Orbit does not have any active builds, platform using I-build. + **Action (Jonah)** to reach out to Roland to discuss handling + builds (aka promotions) of Orbit + - 2022-06 planning: + - Remove Mylyn - **Action (Jonah)** send reminder to + cross-project-issues ahead of time and remove in 2022-06 M1 + phase + - Remove Orbit direct contribution to SimRel - **Action (Jonah)** + send reminder to cross-project-issues ahead of time and remove + in 2022-06 M1 phase + - Remove CVS part of Orbit - **Action (Jonah)** to follow up on + Alex's suggestion (especially as Jonah plans to reach out to + Roland, see above) + + - Membership discussion deferred to next meeting \ No newline at end of file diff --git a/wiki/Planning_Council/2022-03-02.md b/wiki/Planning_Council/2022-03-02.md new file mode 100644 index 0000000..9d876fe --- /dev/null +++ b/wiki/Planning_Council/2022-03-02.md @@ -0,0 +1,52 @@ +## Notes + + - The actions for the last meeting have all been completed - see the + last meeting notes for details + [2022-02-02](2022-02-02.md) + - 2022-03 status update: + - The log4j 1.2.15 is probably not going to be in the 2022-03 + SimRel repository. + - **Action (Jonah)** to confirm the above and make changes if + possible to resolve it. + - The 2022-09 and 2022-12 schedules need to be created. Following + discussion the same schedule as 2021-09 and 2021-12 will be used + (which means 1 week less for 2022-12 and one extra week for 2023-03 + to keep 2022-12 release away from Christmas break) + - **Action (Jonah)** Update planning calendars and wikis + - Membership of planning council discussed. + - Need to review membership and make sure that all Top Level + projects that contain projects part of the SimRel are properly + invited to participate in the Planning Council + - Review existing membership for discussions on existing + participation + - The Planning Council website needs to be updated - + + - **Action (Jonah)** Lead this effort in coordination with + Wayne/Maria/EMO. + - PGP + - PGP update from Ed + - 2022-06 will allow PGP signed content in SimRel (that is signed + by PGP and not jarsigned - jarsigned content is still allowed + and unsigned content is still not allowed) + - Announcement to be made in the coming weeks once some + documentation is updated + - Much of this work has been funded by the Eclipse IDE WG + - See + + for more details. + - "Top 3" items now tracked in gitlab: + + - Three "Prioritzed Dev Efforts" have been created - the first one + is mostly complete already too: + - [Prioritized Dev Effort \#1 - webkitgtk 2.32+ + BrowserFunction only works in first browser + instance](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/issues/5) + - [Prioritized Dev Effort \#2 - Implementation and ongoing + support for Chromium as web browser integration in Eclipse + IDE](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/issues/6) + - [Prioritized Dev Effort \#3 - Dark mode support in SWT and + other parts of Eclipse + UI](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/issues/7) + - Kit Lo + - Kit has recently passed away. Please see his [memorial + page](https://gitlab.eclipse.org/eclipsefdn/memorials). \ No newline at end of file diff --git a/wiki/Planning_Council/2022-04-06.md b/wiki/Planning_Council/2022-04-06.md new file mode 100644 index 0000000..99b7dab --- /dev/null +++ b/wiki/Planning_Council/2022-04-06.md @@ -0,0 +1,34 @@ +## Notes + + - Actions completed from + [2022-03-02](Planning_Council/2022-03-02.md) + meeting: + - log4j 1.2.15 not present in 2022-03 release\! + - Actions carried forward from + [2022-03-02](Planning_Council/2022-03-02.md) + meeting: + - **Action (Jonah)** to update membership + - **Action (Jonah)** to create release schedule for -09/-12 + - PGP can be used announcement made - see + + - Reviewed old release pages on eclipse.org (e.g + , + ) in the context of + migrating to + - **Action (Jonah)** communicate this to the EF web teams via + + and + + - EPP to continue to ship only LTS Java. i.e. stay on Java 17 until + next LTS release. **Action (Jonah)** to update EPP release + procedures to mention this + - Buildship has issues when using Java 17 but project is on older + version.**Action (Martin)** to raise bug with Buildship project + - **Action (Planning Council)** Planning council will monitor the + issue to help ensure health of the Buildship plug-ins in the + Eclipse ecosystem. + - Broad consensus that the release landing pages add little value + and don't need to be migrated. Instead those pages can redirect + to eclipseide.org home page. + - Brief discussion on IP policies going forward. see + \ No newline at end of file diff --git a/wiki/Planning_Council/2022-05-04.md b/wiki/Planning_Council/2022-05-04.md new file mode 100644 index 0000000..53d122c --- /dev/null +++ b/wiki/Planning_Council/2022-05-04.md @@ -0,0 +1,36 @@ +## Notes + + - Actions completed from + [2022-04-06](Planning_Council/2022-04-06.md) + meeting: + - create release schedule for -09/-12 complete + - Update membership in progress, emails sent to all relevant + members. **Action (Jonah)** to continue this update. Follow + + for the migration of the page too. + - Martin raised bug with Buildship project - see + + - **Action (Planning Council)** Planning council will monitor + the issue to help ensure health of the Buildship plug-ins in + the Eclipse ecosystem. + - Discussion on progress for 2022-06 + - Outstanding issue is signing of some bundles - see + + - Finalize 2022-09/-12 schedule + - The schedule has been finalized and approved - see + + - Finalize Java 17 as maximum BREE in SimRel for 2022-09 + - 2022-09 will allow BREE of up to and including Java 17. See + + for what has been approved. The information has been documented + in the release requirements on the wiki [SimRel Requirementes on + Execution + Environment](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28partially_tested.29) + - Discussions on web/chrome/edge support happened in the meeting + - Strong emphasis that we have to be able to handle security + updates in a reasonable amount of effort, this can be done by + relying on OS shipped components, or else Eclipse project (or + related) will need to have a regular update. + - The Eclipse IDE WG will take that on board and coordinate with + the Eclipse project team to make sure that proposed solutions + address these concerns \ No newline at end of file diff --git a/wiki/Planning_Council/2022-06-01.md b/wiki/Planning_Council/2022-06-01.md new file mode 100644 index 0000000..8643980 --- /dev/null +++ b/wiki/Planning_Council/2022-06-01.md @@ -0,0 +1,70 @@ +## Notes + + - Actions completed from + [2022-05-04](Planning_Council/2022-05-04.md) + meeting: + - Membership is now mostly accurate. Some of the PMCs that + participate in SimRel don't have active representation, but no + one from those PMCs has stepped forward to participate. Follow + + for the migration of the page too. + - While the bug Martin raised bug with Buildship project - see + - has had no + response, the Buildship project is still active. Therefore, like + much of open source, if Issue \#1147 is a problem for someone + they should work with the Buildship committers to get it + resolved. + - Discussion on progress for 2022-06 + - Everything on track + - Minor issue of jboss still not being accessible from Eclipse + means this gerrit cannot be applied still - + + - **Action (Jonah)** Submit the gerrit once (if?) jboss issue + resolved + - **Action (Jonah)** Submit bug to Ant folks related to + comment ' Central has javax.media:jai-core:1.1.3 but only + com.sun.media:jai-codec:1.1.2_01' in + + - Leif filled us in on Yatta's proposed Electron based integration for + SWT browser + - The initial working version is here - + + - The advantage of this approach is that browser rendering is + decoupled from SWT (using IPC between electron and SWT + processes) + - Yatta intends to contribute this to the EF + - The disadvantage is that Electron needs to be shipped with your + SWT application to take advantage of it. For lightweight SWT + applications (as opposed to the full Eclipse IDE) this may be + unfeasible as SWT is currently just a couple of megabytes and + adding in Electron would add in \~100MB. Therefore the SWT + integration with OS provided web browser components would need + to remain (e.g. Webkit, Edge, etc) + - Some of the remaining issues (particularly macOS performance + with Retina) could use some dedicated development effort (see + next section of notes) and would require someone with expertise + in this area to resolve. + - Read more and get involved with the project at the GitHub link + above. + - Funded Dev Efforts going forward + - The initial round of funded dev effort (last year's "Top 3") is + well progressed now with all items having been started, and some + completed + - Now is time for planning council to start considering what are + the next items the steering committee should fund + - **Action (Jonah)** Add this to agenda of next meeting + - Composite repos + - Following on from discussion on + + we decided to in SimRel and EPP stop having the composites + contain multiple milestones as children. + - **Action (Jonah)** Announce this on cross-project-issues + - PGP status + - PGP is working well, many bundles are using it + - TM4E is signing one bundle with PGP, but as the public key was + not previously release users updating from 2022-03 to 2022-06 + will be prompted to trust that key + - Ed updated Oomph catalogs to trust keys coming from Eclipse + projects, so users installing 2022-06 will not see this prompt. + See + for more details \ No newline at end of file diff --git a/wiki/Planning_Council/2022-09-07.md b/wiki/Planning_Council/2022-09-07.md new file mode 100644 index 0000000..1494b86 --- /dev/null +++ b/wiki/Planning_Council/2022-09-07.md @@ -0,0 +1,48 @@ +## Notes + +### 2022-09 Release + + - 2022-09 release going fine and on schedule for EPP to be built + tomorrow + - Ed has been keeping on top of numerous issues (all resolved), such + as: + - Platform's RC1/RC2 getting fully submitted\*\*\* RAP + contribution missing PGP signatures (resolved very quickly + thanks to quick response from RAP project) + - Signature issue re: Jetty between Platform and WTP. Currently + resolved because Platform's contribution goes into SimRel + because it is listed first in the .aggr file. + - Nitin fixed the issue of out of date bugzilla links in the packages + - m2e has a major new version. + - This means some installs will fail to update depending on what + third-party m2e extensions are installed. This may lead to bug + reports/etc of fail to upgrade problems. + - Some updates aren't really necessary, simply updating the Maven + plug-in means that extensions aren't needed. + - See + + for more info + +### IDE WG Funded Development Effort + + - The current work is going well with the budget available, just that + it is taking longer than originally hoped. No budget implications as + delay is calendar only, not effort required. + - Martin and Leif will discuss Chromium offline to see next steps + - Future items for IDE WG to consider funding: + - review and accepting contributions + - e.g. are there past active committers willing to review + changes? + - Add "obsolete" to p2 so that old stuff can be removed that does + not work - modelled on RPM + - The hope is this is to resolve future issues like the m2e + upgrade problem so that packages can be marked obsolete and + be removed as part of an upgrade + +### 2023 schedule + + - Aim is to follow the same schedule in 2023-03 and 2023-06 as the + 2022 schedules + - **Action (Jonah)** Create + [SimultaneousRelease](../Simultaneous_Release.md) pages for the + releases and send them to planning council for approval \ No newline at end of file diff --git a/wiki/Planning_Council/2022-10-05.md b/wiki/Planning_Council/2022-10-05.md new file mode 100644 index 0000000..696c847 --- /dev/null +++ b/wiki/Planning_Council/2022-10-05.md @@ -0,0 +1,49 @@ +## Notes + +### 2023-03 and 2023-06 schedule + + - The 2023-03 and 2023-06 schedule was circulated ahead of the meeting + ([email](https://www.eclipse.org/lists/eclipse.org-planning-council/msg03608.html)) + - The schedule was approved in the meeting + - **Action (Jonah)**: Add the schedule to the Google Calendar + +### 2022-12 Release + + - The release is on schedule for M1 + - JustJ has signed java.exe and other exes/dlls + - Ed has been keeping on top of the contents of the train which has + led to Nitin has done quick turnaround on some fixes (such as dup + versions + unsigned content) + +### IDE WG funded development + + - A recap of what happened in 2022 was reviewed + - Discussions on what should be in the list to send to the IDE WG + Steering Committee happened. + - See the [email + thread](https://www.eclipse.org/lists/eclipse.org-planning-council/msg03609.html) + on the results of that discussion. + - **Action (Alex) - completed**: Send Jonahsome example queries on + win32 open items + - **Action (Jonah)**: Send details of discussion in response to above + mentioned thread, and once approved pass this to the IDE WG Steering + Committee. + +### EclipseCon Community Day + + - Martin and Johannes have volunteered to present slides at the + [community day](https://www.eclipsecon.org/2022/community-day), if + it is in the afternoon. Schedule is not final yet. (Thank you + both\!) + - See [email + thread](https://www.eclipse.org/lists/eclipse.org-planning-council/msg03607.html) + on this topic. + - **Action (Jonah)**: Put slides together by 12th October + +### SimRel participation rules + + - Some of the participation rules need to be updated, such as + [third-party + content](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Re-use_and_share_common_third_party_code_.28partially_tested.29) + does not need to come via Orbit + - **Action (Jonah)**: Update must-dos and circulate for approval. \ No newline at end of file diff --git a/wiki/Planning_Council/2022-11-02.md b/wiki/Planning_Council/2022-11-02.md new file mode 100644 index 0000000..e1633d2 --- /dev/null +++ b/wiki/Planning_Council/2022-11-02.md @@ -0,0 +1,37 @@ +## Notes + +### Actions from last meeting + +Actions from [2022-10-05](2022-10-05.md). + + - **DONE**: Action (Jonah): Add the schedule to the Google Calendar + - **DONE**: Action (Jonah): Send details of discussion in response to + above mentioned thread, and once approved pass this to the IDE WG + Steering Committee. + - **DONE**: Action (Jonah): Put slides together by 12th October + - Carried forward **Action (Jonah)**: Update SimRel participation + rules must-dos and circulate for approval. + +### 2022-12 Release + + - Batik upgrade has caused lots of duplicates, hopefully as this was + late in M2 cycle this will be resolved for M3 + - ECF needs to upgrade to latest httpclient version or else the older + version will be in 2022-12. See [this + issue](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/591#issuecomment-1300640537) + as an entry point to that discussion. + +### IDE WG funded development + + - The current board is + [here](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/boards/1208) + - Discussed and approved adding the following two items (which may be + broken down into smaller items if/as needed): + - m2e specific fixes to improve usability, for example + [m2e-core\#1012](https://github.com/eclipse-m2e/m2e-core/issues/1012) + and + [m2e-core\#1013](https://github.com/eclipse-m2e/m2e-core/issues/1013) + - release engineering work on projects in WG that are at the root + of the dependency charts, e.g. Tycho, EMF, ECF, Platform + - **Action (Jonah)**: Make the new issues in + [gitlab](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues) \ No newline at end of file diff --git a/wiki/Planning_Council/2022-12-07.md b/wiki/Planning_Council/2022-12-07.md new file mode 100644 index 0000000..6dc2dd8 --- /dev/null +++ b/wiki/Planning_Council/2022-12-07.md @@ -0,0 +1,2 @@ +See notes for this meeting recorded on the mailing list - + \ No newline at end of file diff --git a/wiki/Planning_Council/2023-02-01.md b/wiki/Planning_Council/2023-02-01.md new file mode 100644 index 0000000..b483b4a --- /dev/null +++ b/wiki/Planning_Council/2023-02-01.md @@ -0,0 +1,25 @@ +## Notes + +### Actions from last meeting + +Actions from Previous meetings + + - Carried forward **Action (Jonah)**: Update SimRel participation + rules must-dos and circulate for approval. + +### IDE WG funded development + + - The current board is + [here](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/boards/1208) + - Discussed and approved adding the security issues raised by the + security audit and outlined in Mikael's email + + - **Action (Jonah)**: Make the new issues in + [gitlab](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues) + +### Items carried forward to next meeting + + - 2023-03 status + - 2023-09/12 schedules + - IDE WG dev effort on JDT/m2e issue sent to list + \ No newline at end of file diff --git a/wiki/Planning_Council/2023-03-01.md b/wiki/Planning_Council/2023-03-01.md new file mode 100644 index 0000000..592d7fc --- /dev/null +++ b/wiki/Planning_Council/2023-03-01.md @@ -0,0 +1,21 @@ +## Notes + +### Actions from last meeting + +Actions from Previous meetings + +- Carried forward **Action (Jonah)**: Update SimRel participation + rules must-dos and circulate for approval. + +### IDE WG funded development + +- The current board is + [here](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/boards/1208) +- Discussed and approved adding the security issues raised by the + security audit and outlined in Mikael's email + +- **Action (Jonah)**: Make the new issues in + [gitlab](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues) +- The Dark mode issue that was previously identified as higher + priority has now fallen far enough down the priority list. Therefore + it should not be recreated going forward. \ No newline at end of file diff --git a/wiki/Planning_Council/2023-04-05.md b/wiki/Planning_Council/2023-04-05.md new file mode 100644 index 0000000..7dd0796 --- /dev/null +++ b/wiki/Planning_Council/2023-04-05.md @@ -0,0 +1,35 @@ +## Notes + +### Actions from last meeting + +- **Action (Jonah)**: Make the new issues in + [gitlab](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues) + \*\*DONE\*\* +- **Action (Jonah)**: Make + [SimultaneousRelease](../Simultaneous_Release.md) pages for 2023-09 + and 2023-12 + +Actions from Previous meetings + +- Carried forward **Action (Jonah)**: Update SimRel participation + rules must-dos and circulate for approval. + +### Discussions + +- Discussed removal of Navigator, an issue that the Eclipse PMC will + be discussing at their next meeting. + + (the eclipse-pmc email archive is broken so I can't list to the + emails on this topic there) +- Confirmed that [SimultaneousRelease](../Simultaneous_Release.md) pages + for 2023-09 and 2023-12 are ok. **Action (Jonah)**: Create google + calendar entries +- No issues identified for 2023-06 M1 that is coming up next week. +- Discussion about how to manage API across all of SimRel. Items + discussed: + - Perhaps use japicmp across all of SimRel + - All projects build against latest dependencies (and all the + issues related to that) + - How to handle removal of APIs, e.g. how better to + handle/generate an email like this in the future: + \ No newline at end of file diff --git a/wiki/Planning_Council/2023-05-03.md b/wiki/Planning_Council/2023-05-03.md new file mode 100644 index 0000000..da1b589 --- /dev/null +++ b/wiki/Planning_Council/2023-05-03.md @@ -0,0 +1,114 @@ +## Notes + +### Actions from last meeting + +- **Action (Jonah)**: Create google calendar entries for 2023-09/12 + **DONE** - see + + +Actions from Previous meetings + +- Carried forward **Action (Jonah)**: Update SimRel participation + rules must-dos and circulate for approval. + +### Discussions + +#### Funded development + +Focus of meeting was on identifying funded development efforts of the +IDE WG. The ongoing planning and prioritization will be conducted on the +mailing list. **Action (Jonah)** to circulate first draft of this +prioritized on mailing list in coming days with goal of having a few +items ready for Jonah/Martin next meeting with Paul/Sharon on May 9th. + +Here are the items that we brainstormed: + +- SWT on Linux + - GTK 4 + - Initial GTK4 work now doesn't compile anymore - largely due + to strict compilation rules around deprecated use, but other + items too + - Webkit for GTK3 is likely to be discontinued much sooner + than the rest of GTK3 - something similar happened with + webkit on GTK2 + - Webkit is needed to generate any HTML content, e.g. javadoc + pop-ups + - Estimate that it is a full time job to maintain GTK 4 port + - Adapting Tree and Table to GTK4 is probably 4-5 months work + for a knowledgeable engineer + - Discussed whether there are other options, such as building on + top of or Qt +- m2e + - m2e has open usability dev funding effort in + + - can we increase funding so more of the backlog can be addressed + quicker +- UI Overhaul + - Generally raised idea of improving UI, but not concrete + issues/dev efforts can really be raised at this point + - Once various work items on improving UI is underway, if there + are issues that can be pulled out that should happen then +- On macOS breaking signing by editing install directory + - This was identified as a research project to figure out Eclipse + can work in the secure environments of not only macOS, but also + Windows and shared installations +- Coding Mentor + - Within the context of using funds in the IDE WG for the best + multiplicative effect modelling on what the documentation + foundation did by hiring a mentor for newcomers was discussed + - +- Accessibility + - See section below +- JDT + - General stability issues requiring things like restarting the + IDE +- Open Type/Resource/etc Implement fuzzy matching - see + +- Windows defender auto-fix + - For a long time there has been a warning on the [N&N + pages](https://eclipseide.org/release/noteworthy/) for Eclipse + "Windows 10 users: Windows 10 Defender significantly slows down + Eclipse\[...\]" + - Implement something like + - + + (Apache 2.0 licensed) and section "A new IDE suggestion to + reconfigure Windows Defender settings for better performance" of + +- hidpi issues +- multi-monitor issues +- p2 touchpoint issues on restart e.g + +- target platform errors e.g. + + +#### Accessibility + +In response to request from Wayne - + - +we discussed next steps and came up with this 3 step plan: + +1. Create a funded development effort to identify/fix/improve places + that accessibility is lacking. (Steps below are not blocked on + completing the dev effort itself) +2. Bring wiki documents up to date (maybe in new location) **Action + (Jonah)** to review documents. +3. Create a blog post to announce efforts and importance and circulate + to various Eclipse IDE development channels. **Action (Jonah)** to + create blog post. + +#### Testing and Platform Support + +Project plan - + - +lists Linux target environments as being Red Hat Enterprise Linux, SUSE +Linux Enterprise Server and Ubuntu Long Term Support. CI testing does +not use all those platforms. See Smoke Tests on + + +**Action (Jonah)** to reach out to IBM to find out if there is or used +to be manual testing procedures. + +#### Chat service + +Short discussion on Chat Service used and interest in it. \ No newline at end of file diff --git a/wiki/Planning_Council/2023-06-07.md b/wiki/Planning_Council/2023-06-07.md new file mode 100644 index 0000000..496a66c --- /dev/null +++ b/wiki/Planning_Council/2023-06-07.md @@ -0,0 +1,26 @@ +## Notes + +### Actions from last meeting + +- **Action (Jonah)** to reach out to IBM to find out if there is or + used to be manual testing procedures. **DONE** - There aren't any + formal ones +- **Action (Jonah)** Create all items on the funded dev efforts board + and prioritize them with the council. **DONE** - see + + +Actions that are still outstanding: + +- **Action (Jonah)**: [Accessibility plan](2023-05-03.md#accessibility) +- **Action (Jonah)**: Update SimRel participation rules must-dos and + circulate for approval. + +### Discussions + +- Delivered update on funded dev efforts, with particular focus on Onboarding mentor and discussions with Jan Iversen +- Status update on 2023-06 +- Third party dependencies +- See in particular all the improvements coming in Tycho 4.0 and how they can be used: + - [https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#400-under-development](https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#400-under-development) + - [https://github.com/eclipse/wildwebdeveloper/pull/1238](https://github.com/eclipse/wildwebdeveloper/pull/1238) + - [https://www.eclipse.org/lists/cross-project-issues-dev/msg19679.html](https://www.eclipse.org/lists/cross-project-issues-dev/msg19679.html) \ No newline at end of file diff --git a/wiki/Planning_Council/2023-08-02.md b/wiki/Planning_Council/2023-08-02.md new file mode 100644 index 0000000..80a4057 --- /dev/null +++ b/wiki/Planning_Council/2023-08-02.md @@ -0,0 +1,21 @@ +## Notes + +### Actions from last meeting + +- **Action (Jonah)**: Accessibility plan - see + +- **Action (Jonah)**: Update SimRel participation rules must-dos and + circulate for approval. + +### Discussions + +- Status update on 2023-09 +- Third party dependencies +- Reviewed dev efforts +- Agreed to add new Dev Effort to completely revamp/fix 3rd party + library handling (aka Orbit) to take full advantage of all recent + technologies, such as direct from Maven +- Initial discussion on security release procedures and its possible + effects on SimRel + - One option is Oomph can display webpages on startup so we can + push a notification that way to users about CVE/etc \ No newline at end of file diff --git a/wiki/Planning_Council/2023-09-06.md b/wiki/Planning_Council/2023-09-06.md new file mode 100644 index 0000000..e6b5501 --- /dev/null +++ b/wiki/Planning_Council/2023-09-06.md @@ -0,0 +1,17 @@ +### Actions from last meeting + +- **Action (Jonah)**: Accessibility plan - see + +- **Action (Jonah)**: Update SimRel participation rules must-dos and + circulate for approval. + +### Discussions + +- Status update on 2023-09 +- Reviewed dev efforts board - see + +- Discussed new logging work - see + + for summary +- **Action (Jonah)** Add a N&N entry somewhere about the changes + needed to get logging working \ No newline at end of file diff --git a/wiki/Planning_Council/Apr_01_2009.md b/wiki/Planning_Council/Apr_01_2009.md new file mode 100644 index 0000000..cb848c5 --- /dev/null +++ b/wiki/Planning_Council/Apr_01_2009.md @@ -0,0 +1,187 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, Apr 01 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=4&day=1&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| | +| | + +| | | +| -------------------------------- | ----------------- | +| Chris Aniszczyk | Y | +| Cedric Brun | Y | +| Oliver Cole | Y | +| Stefan Daume | Y | +| Brian Fitzpatrick | R | +| Bjorn Freeman-Benson | | +| Doug Gaff | | +| Neil Hauge | Y | +| Mika Hoikkala | | +| Anthony Hunter | Y | +| Oisin Hurley | Y | +| Markus Knauer | R (on a train...) | +| Christian Kurzke | | +| Wenfeng Li (represented by Gary) | Y | +| Ed Merks | Y | +| Mike Milinkovich | | +| Philippe Mulet | | +| James Saliba | | +| Georg Schmidt | | +| Karsten Schmidt | Y | +| Thomas Watson | Y | +| David Williams | Y | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Build update + + + + - + + - + Anthony to followup with Rich next week on how to handle some + modeling (?qvt?) project files. + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + + + + - + + - + Karsten (re) raised concern about the accessibility issue, and + that so many of that "should do" items had no comment or status. + ACTION: I offered to send reminder to cross-project list. + + + + - + + - + Tom asked about Babel's expectations and deadlines. + ACTION: Since none of us knew, Tom will ask on Babel's + newsgroup, and get back to Planning Council. + + + + - When, How, Who to have bi-weekly "build team" meetings? + + + + - + + - + Oisin may follow-up with note to cross-project list with a a + proposal. + + + + - List of moons for future names: + + + + - + + - + ACTION: Oliver volunteered to setup a doodle vote (or whatever + its called) and give community a limited set to vote on ... such + as just the H moons. We did decide we can use any moon in the + solar system ... don't need to stick to Jupiter's moons. + + + + - + + - + Jupiter has about [50 + moons](http://solarsystem.nasa.gov/planets/profile.cfm?Object=Jupiter&Display=Moons)\! + Are these pronounceable enough? + If we sort alphabetically and start with those "higher" than + "G", the list would be: + - + Harpalyke + Hegemone + Helike + Hermippe + Himalia + Iocaste + Isonoe + Kale + Kallichore + Kalyke + Kore + Leda + Lysithea + Megaclite + Metis + Mneme + Orthosie + Pasiphaë + Pasithee + Praxidike + Sinope + Sponde + Taygete + Thebe + Thelxinoe + Themisto + Thyone + Saturn has a similar total number of moons. If we did similar, + alphabetize and take those greater than "G" the list would be: + - + Hati + Helene + Hyperion + Hyrokkin + Iapetus + Ijiraq + Janus + Jarnsaxa + Kari + Kiviuq + Loge + Methone + Mimas + Mundilfari + Narvi + Paaliaq + Pallene + Pan + Pandora + Phoebe + Polydeuces + Prometheus + Rhea + Siarnaq + Skathi + Skoll + Surtur + Suttungr + Tarqeq + Tarvos + Telesto + Tethys + Thrymr + Titan + Ymir + +## Reference Links + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) \ No newline at end of file diff --git a/wiki/Planning_Council/April_01_2015.md b/wiki/Planning_Council/April_01_2015.md new file mode 100644 index 0000000..594a3dd --- /dev/null +++ b/wiki/Planning_Council/April_01_2015.md @@ -0,0 +1,250 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 1, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + +| | | | +| ------------------------- | | | +| width="100%" valign="top" | | | + +| | | | +| ------------------------ | ------------------------------ | - | +| Chris Aniszczyk | Technology (PMC) | | +| Dani Megert | Eclipse (PMC) | Y | +| Steffen Pingel | Mylyn (ALM) PMC | | +| Brian Payton | Datatools (PMC) | | +| Doug Schaefer | Tools (PMC) | Y | +| Adrian Mos (Marc Dutoo ) | SOA (PMC) | | +| Ed Merks | Modeling (PMC) | | +| Ian Bull | Rt (PMC) | Y | +| Chuck Bridgham | WTP (PMC) | Y | +| Wayne Beaton | Eclipse Foundation (appointed) | Y | +| David Williams | (appointed Chair) | Y | + +**PMC (and Strategic) Reps** + +| + +| | | | +| -------------- | -------------------------------- | - | +| Cedric Brun | OBEO (Strategic Developer) | | +| Neil Hauge | Oracle (Strategic Developer) | Y | +| Stephan Merker | SAP AG (Strategic Developer) | Y | +| Markus Knauer | Innoopract (Strategic Developer) | | +| Rajeev Dayal | Google (Strategic Developer) | | +| (PMC rep) | Actuate (Strategic Developer) | X | +| (PMC rep) | IBM (Strategic Developer) | X | + +**Strategic Reps** + +|- ||width="100%" valign="top" || | |} + +| | | | +| ----------- | ---------------------------- | - | +| \[no name\] | CA Inc. (Strategic Consumer) | X | +| \[no name\] | Birt (PMC) | X | + +**Inactive** + +|} + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Naming Mars +1 + + - and - Naming Mars+1 (2016 Eclipse Simultaneous Release) + + - Neon: 31 % is latest being vetted. Any status update? + +## EclipseCon 2015 + +\[To those that attended: how was breakfast? Any "notes" relevant to +Planning Council?\] + + - ''Wayne had "eggs and vegetables" which he highly recommends. :) + + + + - + Sounds like nothing concrete discussed, at breakfast or elsewhere, + with direct actions needed. But, still some discussion of "what can + go in an SR", and "do we need 6 month releases instead of yearly" + were the types of topics discussed. + +## Mars Planning + + - Any issues? + - Improving user experience in finding right function to install. For + latest ideas, see + + + + - + + \- Create a Marketplace for the simultaneous release. + + *Overall, would be "driven" by Eclipse Foundation, but they would + need help from top level projects, and the Planning Council.* + + + + - Moved "Sim Release Aggregation" to "[HIPP + Instance](https://hudson.eclipse.org/simrel/)" (post M6). + - Move Git access to require Gerrit URL . + - Any issues with - Use Java 7 in the infrastructure signing service? + (Is currently Java 6). + + + + - + \- Primarily effects "repack" users (of which PDE batch builds is + main one). + + + + - Improved "aggregator examples/doc" (a long standing "to do" item). + See [The best format and process for contributing to Sim. + Release](Simrel/Contributing_to_Simrel_Aggregation_Build#The_best_format_and_process_for_contributing_to_Sim._Release "wikilink"). + + + + - + \- Can I ask for one volunteer to "edit" the document (just that new + section)? Proof read, makes sure it is understandable? Not too + wordy? (Before I announce to the world.) + *No volunteers. Will let community review*. + \- When should we require and enforce "the first format"? Or, some + variation of it? (Purpose is to be more "repeatable", and more + useful to adopters.) (See ) + \- Does any one have, or can someone create a tool to "create the + right format"? + +## Progress on Action Items + + - Improve "aggregator examples/doc". (dw -- done\! With preliminary + version, anyway). + +## New Business + + - Just curious, how's the ["greatfix + competition"](https://www.eclipse.org/projects/greatfix/)? + + + + - + *Going well, according to Wayne. One unanticipated thing was when + one person contributes many small fixes. No one of them is a "great + fix", but as a whole is a significant contribution. Handling + informally now, but next time my include in the rules or + guidelines.* + + + + - *Spent a fair amount of time discussing late addition of Gradle (aka + Eclipse Buildship). Some concern expressed about lateness, some + alternatives discussed, but to some extent all premature since Wayne + et. al. not ready to formally propose. One thing needed is some + "community" of Gradle users (experts) who can test to "make sure it + is ready".* + + + + - *Some **potential** security issues mentioned (one with Batik, one + with Xerces and Java 9) but no action required at this time.* + + + + - *Good news is the "Java 9 team" has been testing Eclipse and several + projects, and so far no huge problems found.* + +## Next Meeting + + - May 6, 2015 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_02_2014.md b/wiki/Planning_Council/April_02_2014.md new file mode 100644 index 0000000..06e11d9 --- /dev/null +++ b/wiki/Planning_Council/April_02_2014.md @@ -0,0 +1,493 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 2, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y Delegate: Konstantin

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Reminder: [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + + + + - Reminder: Make sure you and your projects are aware of [these + proposals for "preferences and configuration" and "error + reporting"](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10405.html). + +## Previous meeting minutes + + - + + - + Let's discuss EclipseCon meeting and hear "trip reports" at end + of meeting, if time allows. + + [EclipseCon face-to-face](March_16_2014.md) + + [Previous "first Wednesday" + meeting](March_05_2014.md) + +## Kepler SR2 + + - Any issues? + + + + - + There is one known, mysterious p2-update issue (discovered after + 'release'): + - + Sounds like no progress? + +*This was discussed at EclipseCon, by p2 team, and while good solution +is still unknown, the reasons for it are understood, and (for some +reason) doesn't seem to be reported that often as a problem, so I'll +remove from future agenda items.* + +## Kepler Plus + + - Discuss/Decide Plan (if any) for "post Kepler patches" for Java 8 + support. + + + + - + I'm assuming everyone has been reading the thread on cross-project + list titled: Kepler SR3 for Java 8? + - + For overall view, see + + I think this is the initial, quiet posting: + + And for some reason, heats up from there. + Thanks to Mike and Eclipse Foundation for the [steps they are + taking](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10439.html) + to raise awareness. + \[retrospective\] Overall, I feel I'm responsible for not putting on + agenda months ago (but, I know we are all responsible for failure to + plan) ... but it appears that Java 8 support caught some people by + surprise -- and perhaps we should have thought to coordinate better? + + + + - Brief reminder that some have said if our goal is to "wow casual + users" that bugs such as may not allow that. That is, those not + used to "EEs" and "toolchains" may be frustrated by some of the + behavior, instead of wowed, and those that do understand EEs and + tool chains are likely not burdened (too much) by using patches. + - How big is the problem? Who besides Platform (JDT/PDE) has "Java 8" + support to patch into Kepler? + + + + - + See - Who has "Java 8 Patch" for Kepler SR2? + - + Faceted Projects, from WTP + m2e (has already declined to participate, I believe). + ObjectTeam? + AspectJ? + Anyone else? + + + + - What should "we" do (as being responsible for "overall Release + Plans")? + +:\* Alternatives I've heard mentioned: + +::\* Do nothing, and projects can provide patch features from their own +repositories, if they'd like. + +::\* Kepler SR3, update sim rel repository, respin packages (gather +community testing and feedback, and package maintainers testing). + +::\* Some sort of new "R" release? that was apparently discussed at +Arch. meeting at EclispeCon? + +::\* In addition to EF's "summary pages", have a common repository that +would contain all patches related to Java 8. + + - + + - + Note: I've seen where Wayne has already created ["Market Place" + items](https://bugs.eclipse.org/bugs/show_bug.cgi?id=431294#c4) + for the two known cases. + - + Is this equivalent to this "common patch" repo? (I think it + is, mostly)? + - This would, presumably, hold patches for "new function" + for Java 8, as well as anyone who had to fix something + to enable running on Java 8 -- but not "fixes in + general" (those should still come from project's own + repositories). + - Would be "long lived" in the sense we would not delete + it when Luna came out, but (I'd propose) would not have + any further maintenance done on those patches (i.e., no + attempt to make Kepler equal Luna support for Java 8). + More of a sneak peek. Care is needed here not to give + the wrong impression this was "Complete Java 8 support + backported" to Kepler. + - This could be implemented as a snapshot: with "copies" + of the patch repositories ... composting subdirectories, + and remaining unchanged. + + - + Or could be implemented floating: a composite repo + pointing to the original patch repositories, so small + tweaks or blocking defects fixed (eventually) and thus + would be "in" the "Common Java 8 Patch Repository" + automatically. + + - Konstantin [has proposed to "do all the + work"](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10451.html) + to create new packages with patched features, if he had "a + commitment to publish these packages at a reasonable + location in eclipse.org main downloads area". + - Are there "third party" providers that make these sort of + "Kepler Plus" packages? Such as EclispeSource via Yoxos? + (And, I'm not asking for any confidential information\!). + +Be prepared for a roll-call vote\! Not only "yea or nay" but, also if +your projects (with PMC's blessing) had something for this repo, or if +the strategic member you represent has any view point to share with the +Planning Council. \[As always, the decision is not made by "majority +rules" (the decision is made by "status quo, if no consensus") ... but I +do want to be sure to hear, equally, from everyone, with specifics.\] + +### Results of discussion + +''Meeting went over by 30 minutes, so we could talk on this subject for +an hour. We did decide a general direction, though some items still +needed a bit more research: '' + + - *If Konstantin was willing to "do all the work", we saw no reason to + object to making the "pre-patched" packages available.* + - ''But, we did not want to give users the wrong impression that they + were "on par" with a service release, since basically they will be + untested (by community, and package maintainers) so wanted users to + have to go to separate page, make an explicit choice, and know what + they were getting, for example to make it clear these were "Kepler + SR2 packages with Java 8 Support patches pre-applied". We would not + want to call them "SR3" nor imply "Kepler with full Java 8 support". + '' + - ''Follow-up Actions: '' + + + + - + + - + \* Konstantin to send note to epp-dev list asking if any + packages did not want to have such a patched package made + available. (package maintainers would not have to test or + sign-off on them, so at worse, they might get some bug reports + they'd have to triage ... which hopefully would be a good thing + as an early warning for Luna issue. And, of course, they could + test as much as they'd like, but there would be no official + "sign-off"). + \* Konstantin to send note to "m2e" asking if any inclusion + required/desired for "wtp-m2e" in WTP. + \* David to follow through with Eclipse Foundation, on how and + where to place on "downloads". \[Technically, EF "owns" + downloads page, but they'd appreciate our input and + suggestions.\] + - + \* The best suggestion I heard, came from Dani, where on the + current "Java 8 support" page, to have a link to 1) Kepler + SR2 packages with Java 8 support patches pre-applied and 2) + a link to "Luna packages under development with Java 8 + support" (this would be more relevant once M7 comes out ... + but, until then, might point to Eclipse's download page for + I-builds? Or, just say "(coming for Luna M7, available May + 9th)". + \* Would recommend a "related link" on normal download page, + that went to "Java 8 support page". + - + \* Konstantin: It needs to be far more prominent that + that (bigger font). The user should be able to glance on + the page and see Java 8 reference quickly. That will not + be the case with the small text of the related links. On + the call, folks brought up two alternatives that would + address my concerns (a) Java 8 tab next to developer + builds tab or (b) Java 8 rectangle beneath Eclipse + Standard banner. + + + + - *Non-action items we agreed on:* + +::\* No changes to Kepler Sim. Release repository. + +::\* No "common patch repository" would be made available. + +::\* If someone "not ready now", then, we would not go through this +again in a month or two. (This includes, for example, if "JDT" comes out +with an improved patch in weeks or months ahead, then users would still +have to go to their specific site to install that update). + + - *Open Questions* + +::\* When should the "Java 8 Support page with patched packages" go +away? When Luna comes out in June? Or, leave until September and Luna +SR1? Seemed a slight leaning towards September ... but ... we did not +really discuss enough. + +## Luna Planning + + - Question/awareness of "Mac packaging". See . My view it is too late + to do for Luna -- anyone feel like it's so important we drop other + things to do this? I assume could not be done in an "SR" (but, + maybe?) ... which would mean "another year". Is there a reason to + never do it? (i.e. doesn't fit someone's "use cases" or workflow?) + Would that mean we need "two forms" of packaging available to + satisfy everyone? + +*There was clear agreement this was not a Luna item, but most agreed it +should be investigated for Mars. It might take reaction on some +projects, such as if they don't specify "platform URLs" correctly (but +use some sort of relative or absolute file paths) but no real blockers +are currently known. Need to investigate if any side effects such as +does using "dropins" break the signature ... or, does dropins need to be +somewhere outside of Eclipse.apps", and similar unknowns.* + +## Progress on Action Items + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + +## New Business + + - ? + +## Next Meeting + + - May 7, 2014 - Regular First Wednesday Meeting + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_05_2017.md b/wiki/Planning_Council/April_05_2017.md new file mode 100644 index 0000000..f2a197c --- /dev/null +++ b/wiki/Planning_Council/April_05_2017.md @@ -0,0 +1,251 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Mar 01, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + +### Eclipse Foundation + + - Y Wayne Beaton, interim chair + - Y Frederic Gurr + - Y Mickael Barbero + +### Strategic Members + + - N CA Technologies + - N CEA LIST + - N Codenvy, S.A. (Tyler Jewell) + - N Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - Y IBM (Thomas Watson) + - N itemis AG (Alexander Nyssen) + - Y OBEO (Melanie Bats) + - N Oracle (Neil Hauge) + - N Red Hat, Inc. (Nick Boldt) + - N Robert Bosch GmbH + - Y SAP SE (Stephan Merker) + +### PMC Representatives + + - N Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - N Data Tools Platform PMC (Brian Payton) + - N Eclipse Cloud Development PMC (Martin Lippert) + - Y Eclipse Project PMC (Dani Megert) + - N IoT + - N LocationTech Technology + - Y Eclipse Modeling Project PMC (Ed Merks) + - N Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - N PolarSys + - N Eclipse Runtime Project (RT) PMC (Ian Bull) + - N Eclipse Science + - N Service Oriented Architecture PMC (Adrian Mos) + - N Technology PMC (Chris Aniszczyk) + - Y Tools Project PMC (Doug Schaefer) + - N Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Finalize our plans with regard to a July *Java 9 Release* + - Neon.3 Update Problems: To Fix and Howto Fix? + +**The Neon.3 update problems** + +The first symptom seen was that the Marketplace was not showing anymore +in the Help menu in Neon.3. This seems to be due to a broken Orbit +bundle that got into the Neon.3 release train repository: +org.apache.httpcomponents.httpclient 4.5.2 which does not include the +fluent API among others. This was introduced in Neon.3 by the Linux +Tools project while upgrading the level of docker-client referenced the +Oxygen M4 Orbit repo to get the httpclient. + +This leads to two different points: 1. How to resolve right now the +problem for Neon.3 ? What should we do to not anymore include the broken +httpclient version in Neon.3? 2. What we should do to prevent this in +our future releases: How Orbit dependencies should be managed? + +**1. How to resolve the problem for Neon.3 ?** + +Several options for resolution were proposed on the mailing lists: + +A. Respin against Oxygen Mx Orbit: Jeff Jonhson proposed to respin Linux +Tools based on the Oxygen M5 Orbit. This means distributing an +unreleased version of a bundle. + +B. Respin with the old version of httpclient: Needs a Neon.3 Orbit +Service Release containing only the 4.3.6 version of httpclient. Needs a +respin of Linux Tools to downgrade the version But the other depending +projects will not be updated and so the MPC will still not work for end +user after the update. + +C. Respin with the two versions of httpclient: Needs a Neon.3 Orbit +Service Release containing the old 4.3.6 version and the fixed 4.5.2 +version of httpclient. In theory the two httpclient bundles should be +able to work side-by-side but we've seen a lot of wiring issues in +Oxygen due to the mix. + +D. Respin with only the new fixed version of httpclient: Needs a Neon.3 +Orbit Service Release containing only the 4.5.2 version of httpclient. +Needs a respin of all the depending projects (Marketplace?) to update +their ranges to the new 4.5.2 version minimum and force the update. + +Service release builds for Orbit ? One point was also about that service +release builds for Orbit could be dropped in the future: + + +David Williams confirmed that in the past, there was always a +maintenance build in Orbit when it was required. + +**2. How Orbit dependencies should be managed?** + +The fact is that many integration problems occurred during these last +months in the SimRel. Today we rely on the manual labor of our package +maintainers. From the Neon.3 problems, another discussion was initiated, +I tried here to list the different proposed solutions: + +A. Be sure of the Orbit milestones: Roland Grunberg proposed to make +sure that the Orbit milestones aren't harmful to begin with. For future +release they would use separate branches. For Neon.3, they had no +initial plan to release Orbit builds at the beginning which contribute +to the previous exposed problem. + +B. Check that 3rd party libs for SimRel come from Orbit. + +C. A tool to check consistency a kind of “SimRel consistency check”. + +D. The individual projects should not be allowed to contribute Orbit +bundles to SimRel: SimRel aggregator should pull in the required Orbit +bundles alone. + +E. Don't include Orbit bundles in project's features: It is not +necessary to include deps in features as p2 will install them. David +Williams answered that this could make builds and installs +non-deterministic especially with third party jars. This means that +tests should be done based on the "project's repository" and others from +the "Sim. Release repository". + +F. Communication/synchronization effort is necessary to harmonize +versions across feature.xml of all participating projects. + +G. Have an integration test suite that SimRel projects can contribute +their own test bundles to and that runs against the finished packages. +These integration tests should cover basic user stories. + +H. Requiring projects on the train to have proper package uses +constraints for all their bundles. + +## Notes + +### Java 9 Update + +Only projects that contribute something that is Java 9 related should be +included in this update release. + +Wayne asked if this means that users will get Java 9 updates as a matter +of course (i.e. as part of the natural update process). + +Dani stated that the Java 9 support for JDT will be made available with +the Java 9 release and then we'd have time between then and the Oxygen.1 +release in September to fix issues. Ed then asked if we want to include +the Java 9 support in the official repository so that it will +automatically update onto users workstations. The implication being that +on the release date, the JDT Java 9 support will not have enjoyed the +level of testing that other projects have via the many multiple +milestones. While beta support for Java 9 has been available for some +time, only proactive developers who have added it to their own +environments have done real testing. + +The discussion lead to a suggestion that we should issue the initial +Java 9 support in a separate repository (i.e. a separate Java 9 p2 site) +and continue to distribute it via Marketplace. (Wayne) *Can we include +it in an update to the Oxygen repository as an optional feature (i.e. a +feature that won't automatically be updated on user workstations?* + +Can we combine a separate install step with a community marketing push? + +Dani noted that we're currently making the Java 9 support in JDT +available via a separate repository because of licensing restrictions on +the specification. For legal reasons, we can't include the +implementation in our milestone builds. + +We did not arrive at any sort of conclusion. Time is getting tight, +we'll have to decide what we're going to do on the next call. + +### Neon.3 is broken + +Melanie proposed some process changes for future releases on the mailing +list. + +Update releases must be encapsulated. i.e. use the repository related to +the release for builds (don't use the Oxygen repo to build artifacts for +deployment in to Neon). + +Melanie proposed some options to mitigate the problems with the Neon.3 +release. + +Ed agreed to provide steps for reproducing the problem so that Thomas +Watson could test if the wiring resolution fix he made for Oxygen also +solves the problem for Neon.3. + +### Other + +The Eclipse Planning Council approved participation by the Eclipse LDT +project in Oxygen. The project's bits have been included in builds since +the beginning of the Oxygen development cycle, but the project team +missed announcing their participation by the M4 deadline. \ No newline at end of file diff --git a/wiki/Planning_Council/April_06_2011.md b/wiki/Planning_Council/April_06_2011.md new file mode 100644 index 0000000..700eb61 --- /dev/null +++ b/wiki/Planning_Council/April_06_2011.md @@ -0,0 +1,399 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, April 06, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=04&day=06&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

R

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

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)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - Welcome "new" member Doug Schaefer ... new representative of Tools + PMC. + +## Indigo Status + + - On track for M7? + +## Name Indigo +1 + + - Name that release; Indigo+1. And [the winner + is](http://www.eclipse.org/indigo/planning/poll2012name.php) ... + *Juno. Pending EMO Review.* + + + + - + And, as of Tuesday, April 5, it is still "pending review". + +## Eclipse 4.2 vs. 3.8 for Juno + +We need to come up with a "proposed plan" for Eclipse Projects and +members to evaluate. With their feedback, our proposed plan can become +our initial plan, and it, in turn, become our final plan. + +During this meeting, I'd like to get feedback on this proposal, to see +if it is ready to "publish" for further feedback from the community. I +realize that many of you will need more detailed meetings with the +projects you represent and/or member companies to see if this plan is +reasonable. It will help those discussions if there is a concrete +proposal. + +(See also [notes from previous +meeting](March_20_2011#Eclipse_4.2_vs._3.8.md).) + +### Proposal + +For Juno, Eclipse 4.2 will be the primary workbench, but all +(participating) projects will support and maintain a 3.8 based +deliverable. + +'Primary workbench' means Eclipse 4.2 will be the primary workbench that +(participating) projects build against, and test, and will be provided +in the common repository, and EPP packages. In all cases, "4.2" means +"4.2 plus compatibility layer". That is, no one is expected to split +streams, use 4.2 workbench "native" or exploit anything specific to 4.2. +Of course, projects can if they want to (within the +[*Assumptions*](April_06_2011#Assumptions.md), +below) but there is no requirement to exploit 4.2 directly and probably +better if low level projects do not. + +'Support and maintain a 3.8 based deliverables' means that +(participating) projects, at a minimum, agree to continue to provide a +deliverable that can be used with 3.8 workbench. In most cases, we hope, +this is the exact same deliverable used for the 4.2 based deliverable. +This would be true for projects that do not use 4.2 specific API and +simply rely on the compatibility layer. But for projects that want to +exploit something new in 4.2 workbench ... that is split streams and +have one specific to the 4.2 workbench prereq ... then they would still +be expected to provide something adopters or upstream projects could use +for 3.8-based installs. When there are two separate deliverables, the +3.8-based maintenance version might simply be Indigo SR2, at a minimum. +But, even then, there might be cases where versions ranges have to be +adjusted, or bugs fixed due to changes in 3.8 (since Indigo SR2 will be +built and tested with Eclipse 3.7.2). Those are the minimum assumed +deliverables. Naturally, projects may do more if they have desire or +reason to, but the goal is to allow adopters an extended "transition" +period to 4.x, if needed, where things will still work, in some form, +using 3.8 based prereqs. For projects that do have "two deliverables", +the 3.8 based one would be available on their own download sites and +their own project's software site repositories, not the common +repository. + +### Assumptions + +While we want to allow projects to split streams, if they need to do so +to exploit some new feature in Eclipse 4.x, we assume no "low level" +projects introduce split streams that would require all dependent +projects above them to also split streams. This could easily lead to +"double work" for many people, which is not practical. + +### Plan roll-out and point of no return + +We need to follow a process of evaluating this proposal, making sure +there are no "blockers" that prevent it becoming our final plan. + +The first step will be to "publish" this plan for feedback. If, or once, +we agree on wording, I'll send note to cross-project list and remind +people to talk to their Planning Council representative if they have +comments or suggestions on the plan. We'll incorporate feedback +received, from projects, or adopters, in our May meeting and then again +in our June meeting. At that point, we'll consider our "proposed plan" +to be our "initial plan". + +To move from "initial plan" to "final plan", we will simply follow our +plan and re-evaluate each milestone of Juno, that is for M1, M2, M3, and +M4. Naturally, we expect confidence to grow incrementally each +milestone, but M4 (in mid-December) will be assumed to be the point of +no return. If no issues are found that prohibit this "4.2 is primary" +plan, then it will be considered final after M4, mid-December, 2011 +(which is the normal time for the "final plans" for our yearly June +releases). This cycle differs a little from previous cycles, since it +assumes projects and adopters do plenty of early testing with those +early milestones (and/or early 3.8 based installs) to make sure it is a +valid plan fulfilling their needs. Typically, many projects will be busy +with Indigo maintenance during this same period of time, so it does take +some commitment to also do the early Juno work if there are any concerns +about implementing this plan. + +### *Discussion during meeting* + +*It was acknowledge that we don't necessarily know how to tell project +the best way to accomplish the goals of "joint support" ... for example, +some might want to build against 3.8 to make sure they do not +accidentally pull in 4.2 APIs, for example. It (probably) depends on +where each project wants to put the focus, but it is mostly up to the +project ... that is, we do not want to dictate how to do things, just +what the goals are ... but, if we come up with better suggestions, or +concrete how-to advise, we should mentor the projects if it would make +things easier.* + +*It was mentioned that projects **can** split streams, without requiring +dependent projects to split streams (that is, their API would stay the +same). This might increase testing use-cases but would not "double" the +work. I'll reword "assumptions".* + +''It was mentioned the proposal seems to say "4.2 is primary" but "we +discourage taking advantage 4.2's new capabilities". Especially in light +of "split streams do not necessarily propagate", I'll reword. '' + +*Ed didn't know if "EMF Edit UI" needed to be split stream, or not ... +will have to investigate*. + +*Mic reports that Mylyn will have to split stream for some of their +bundles, since they use UI internals, but this would not effect their +APIs, so would not mean adopters, that use Mylyn APIs, would have to +split streams.* + +*Given that 4.2 is "primary" and used in repository and EPP packages, +what is the nature of the "support 3.8" requirement? It would not make +sense to say "ok, you can not be in 4.2 based repository, since you do +not support 3.8". Hence, 3.8 support is a "should do" ... a strongly +suggested should-do. With strong emphasis on "tell us explicitly if you +can not". While adopters could always (probably) simply use Helios SR2 +based bundles in their adopting project or products ... but,, the +expectation would be that any bugs open preventing that kind of use +would be accepted as valid. (For examples, if someone has an overly +narrow version pre-req version range).* + +''Put another way, since 3.8 not used in repo, or EPP packages, it would +be hard to know if someone was not maintaining 3.8 compatibility ... +would only show up from adopters or users that were "building their own" +3.8 based installs. That might be a reason or advantage of setting up +some "test builds" to produce a 3.8 based repository ... even if not +"delivered" or formally used, it would spot incompatibility issues +early, at least. This would also be a value-add service to those +adopters that needed 3.8 based builds, since then there would exist a +"specification" of what goes into a 3.8 based build. Hopefully could be +done with some sort of "incremental" build files, so only differences +would have to be listed. '' + +*One request for May or June PC meetings is to list known cases, of who +plans to split stream, or knows they'd have to. Many projects should +already be known, since preliminary work with 4.1 has been going on.* + +*There as a general consensus on the importance of the objectives, that +is, the importance of supporting both streams, but at the same time a +general feeling that "it sure seems complicated" and is unknown what +issues might arise.* + +## Juno Dates + +These are our proposed dates for Juno deliverables. They follow same +"pattern" as previous years. Any issues? Discussion? If not, the +milestone dates will be forthcoming, also following pattern from +previous years. + + - + Release: June 27, 2012 (fourth Wednesday) + SR1: September 28, 2012 (fourth Friday) + SR2: February 22, 2013 (fourth Friday) + +*These dates were agreed to. It was pointed out that this is what the +community would expect, and since one of the oft mentioned strong points +of Eclipse is its predictability, we would want a really important +reason to deviate* + +## Next Meeting + + - May 4, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](Indigo "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_06_2016.md b/wiki/Planning_Council/April_06_2016.md new file mode 100644 index 0000000..75eb11b --- /dev/null +++ b/wiki/Planning_Council/April_06_2016.md @@ -0,0 +1,374 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 6, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Alexander Nyssen

Itemis

Y

Nick Boldt (and Max)

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

EPP (appointed)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Any? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Mars "left over" topics + + - Requirement to use "latest Orbit" (or other pre-reqs) even in + Maintenance releases + + + + - + + - + Turns out, some projects "do not rebuild, ever, for + "maintenance" so they do not use the latest Orbit. + Is it too much to \*require\* that they rebuild to "pick up" new + prereqs? See bug for why this is important. (Ideally, "new + builds" with "new prereqs" would be easy to do. But, guess not + always, if not used to branches, I assume.) + + + + - + + - + \- *Alex promoted the proposal he wrote about on cross-project + list. I will need to re-read that, and respond there. We + discussed a fair amount with no resolution so will track as an + on-going item.* + \- I did respond to give my point of view.'' + \- Anything to add? + \- *No one said anything* + +## Neon Planning (and beyond) + +### new business + + - Cloud Category? + [bug 489467](https://bugs.eclipse.org/bugs/show_bug.cgi?id=489467) + -- In general a good idea, but seems little consensus on "what it + is". We need a good definition of what goes into it. + + + + - + \- *Bug had been updated. Since meeting has been updated again, and + is now "in" as a category.* + +### old (ongoing) stuff + + - Should we change "maintenance" staging name now? for Mars.2? See . + + + + - + \- \[See also for unreleated additional URL.\] + + + + - + + - + \- Still "todo" item. (i.e. not done yet, apologies for delay) + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In M6 we changed to have (nearly) all features to be "root features. + Now what? + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **Impossible now, for Neon. Right? (for EPP Packages) Do we + still need "streamless-URL" now?** + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + What testing would projects have to do? + May become "defacto requirement" once is implemented. + + + + - + *Seemed to be no objection to "trying it" and with Neon we will "try + it" by having the "streamless-URL" proposed in . For Neon, we will + not use that URL automatically anywhere but users can add it if they + would like. Will be interesting to see if many bug reports occur + from people trying that "update to next main release" (that is, from + Mars to Neon).* + +## Oxygen Planning + + - ? + +## New Business + + - Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + +## Next Meeting + + - May 4, 2016 - Regular First Wednesday Meeting + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_07_2010.md b/wiki/Planning_Council/April_07_2010.md new file mode 100644 index 0000000..e39b4aa --- /dev/null +++ b/wiki/Planning_Council/April_07_2010.md @@ -0,0 +1,259 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, April 07, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=04&day=7&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) 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)

N

Doug Gaff ???

Dsdp (PMC)

X

Anthony Hunter

Tools (PMC)

Y

Oisin Hurley

Stp (PMC)

N

Ed Merks

Modeling (PMC)

N

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

N

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

N

Christian Kurzke

Motorola (Strategic Developer)

N

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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.

+ + + +## Helios + +### Common License Issue + +See + +Resolved its fair to ask people to change now to common one, and we are +confident we have correct one. + +The feature.properties file string is that's used in the installers +"compare license" function. + +The compare does strip out whitespace (spaces, tabs, and EOLs) before +comparing. + +PMCs are reminded that where licenses are **missing** is a "stop ship" +issue so don't let those linger. Just being "different" would impact +usability, and violate this year's new Sim. Rel requirement, but would +not be treated as stop ship. + +### Next Year's Name + +See + +See [proposed, culled naming +list](April_07_2010/Proposed_Naming.md) for +voting. + +We discussed list, edited it some, and Wayne will look into using +Eclipse polling software to conduct the poll. + +### Any exceptions to note, or discuss? + + - + PDT + +Anthony discussed the issue, and John add his affirmative vote to make +total 3 required (Anthony's, and Chris replied on mailing list). + +### Maintenance Schedule + +Fourth Friday of September? 9/24/2010 + +Fourth Friday of February? 2/25/2011 + +### Next Year's Schedule + +Not ready to discuss details, but the problems with +1, +2, +3 category +(and short times) should be well discussed. + +Similarly, Oliver brought up issue with need for better "warm-up" +rhythm, especially if a prereq project is late. (EMF's "last minute" M6 +delivery added pressure to TPTP's ability to build/test in time). No +specific actions, process or remedies are known, but ... maybe a +reminder to cross-project list that intermediate or warm-up builds are +good (especially if going to be near deadline). + +### Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +#### Tracking progress and compliance + + - + Work on [Summary + page(s)](http://eclipse.org/helios/planning/SimultaneousRleaseOverview.php) + has started. + + + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + +## Other business + + - +## ToDo Items + +## Next Meeting + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_07_2010/Proposed_Naming.md b/wiki/Planning_Council/April_07_2010/Proposed_Naming.md new file mode 100644 index 0000000..4f8fb4a --- /dev/null +++ b/wiki/Planning_Council/April_07_2010/Proposed_Naming.md @@ -0,0 +1,68 @@ +The following is all "proposed" to be decided during 4/7 meeting. + +In particular, please consider if any "candidate names" should be +excluded, or "excluded names" moved back to the candidate list. + +## Proposed instructions for doodle poll + +Please vote (once only) for your favorite name for the 2011 Simultaneous +Release (the one following Helios). + +The simultaneous release name is an informal "marketing name". It should +be recognizable, pronounceable, relatively distinct, and not confusable +with other software or software companies. Be sure to consider how it +sounds in context, such as "... go download the Eclipse xxxxxxxx Release +... " and how it looks in use as labels or urls, such as +http://..../releases/xxxxxxx. + +See for comments on the relative merits on these candidate names. +. + +This doodle poll will be open for two weeks, until April 22. At that +time, if there is no clear winner, a runnoff vote will be for the top +three contenders until May 6. + +## Proposed (acceptable) candidates for "doodle poll" + + - + Indigo + Indra + Indus + Ion + Ionia + Iris + Isaac + Isis + Ivory + Izar + +## Proposed excluded candidates + +Following ruled out by planning council as being unnecessarily out of +range, unrecognizable, unpronounceable, or having negative associations +imaginable. + + - + Hegemone + Hermes + Hero + Hyperion + Ia ia Cthulhu fhtagn + Iapetos + Icarus + Ijiraq + Ikebana + Intrepid + Ilion + Imagine + Imhotep + Iupiter + Izayoi + Ixion + Io + Ishtar + Janus + Jason + Juno + Jupiter + Kepler \ No newline at end of file diff --git a/wiki/Planning_Council/April_10_2013.md b/wiki/Planning_Council/April_10_2013.md new file mode 100644 index 0000000..bcba3ea --- /dev/null +++ b/wiki/Planning_Council/April_10_2013.md @@ -0,0 +1,328 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 10, 2013, at 1300 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

N

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

N

Adrian Mos

SOA (PMC)

N

Ed Merks

Modeling (PMC)

N

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

N

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

N

Igor Fedorenko

Sonatype (Strategic Developer)

N

Markus Knauer

Innoopract (Strategic Developer)

N

Markus Tiede

BREDEX (Strategic Developer)

N

Rajeev Dayal

Google (Strategic Developer)

N

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Kepler + +### M7 + + - Issues? + + + + - + *No issues raised* + +## EclipseCon face-to-face follow-through + + - + Continue discussion from EclipseCon face-to-face + - + [March_24_2013](Planning_Council/March_24_2013.md) + + + + - + Come up with actionable items + Solicit volunteers to do the actions + + + + - + The following are notes/actions from discussing the specific items. + +### Policy on new releases joining SR + +dw to update current policy in FAQ with the additional detail. + +### Build reproducibility + +dw to come up with "perfect example". Add to wiki, send to Wayne and +Than, and see if some way "CBI" maven task could produce, from template, +as part of build output. + +dw better educate. Give perfect example on wiki. Emphasize non-changing +repos. Give "acceptable" example on wiki. Give "unacceptable" examples +on wiki. + +dw create "report of changes" from one build to another, one repo to +another, so a) individual projects could see if things changed when they +should not have; b) PMCs, Team Leads, Planning council could better +observe "big picture" of how much change there was, especially related +to changes in build input files. + +dw start to tag build file project, each build (so we could diff build +files). + +wayne to add item to release review that "there must be a retention +policy" (it should cover how long repos stay around, such as milestone +repos, and also via ?education? emphasis that it must be +"non-changing".) And then Planning Council can add extra rules for sim. +release, if necessary. + +### Release train rules + +John and Neil volunteered to improve. The idea is to provide briefer +version, but still (probably via hyperlinks?) allow readers to find out +"reasons" for a rule. This would be for Luna (due in Fall, after Kepler +release). + +### Release train rhythm + +We don't anticipate any changes to rhythm, but perhaps more +emphasis/education on milestones. (Perhaps, eventually, add idea of "1 +milestone" to SR cycles). + +Wayne volunteered to add suggestion/idea to GSOC database to make some +user friendly way that users could say "I want to follow beta releases" +... this would add the "current" development stream URL to update sites, +so they'd get updates from milestones, without having to know about it, +and manually add it. + +### The release train and RT + +No actions came from this discussion. It was thought that if/when RT +projects begin to *need* coordination, that we are certainly open to +changes in "rules" that make it more accommodating. (But ... we don't +know if any concrete rules that are inhibitors (all can have exceptions) +... but the mere act of coordinating schedules, if there is no need to +coordinate with others, is inhibiting). If RT stacks are all relatively +independent of IDE, and each other, they often prefer to set their own +schedules, etc. There might be a day when there could be some +"marketing" advantage, say to announce large maven central update, or +something, might be interesting to Rt projects ... but, not clear its +needed now. + +### Orbit + +The Orbit Project Lead (dw) agreed to a plan for a plan ... a plan will +be created after Kepler release, by end of August (since July often a +"slow" month) ... and implemented in the months after that. + +## Next Meeting + + - May 1, 2013 - First Wednesday Meeting + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/April_4_2018.md b/wiki/Planning_Council/April_4_2018.md new file mode 100644 index 0000000..83797fb --- /dev/null +++ b/wiki/Planning_Council/April_4_2018.md @@ -0,0 +1,139 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, April 4, 2018, at 1200 Noon Eastern

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Photon & Oxygen status + - Post Photon SimRel status + +## Attendance + +Ed Merks (Eclipse Modeling Project), Frederic Gurr (Eclipse Foundation), +Martin Lippert (Eclipse Cloud Development), Dani Megert (Eclipse +Project), Mélanie Bats (Obeo), Thomas Watson (IBM) + +Regrets : Mickael Barbero (Eclipse Foundation) + +## Notes + +### Photon & Oxygen status + +Everything is okay : Oxygen.3 out on time + +RC2 Oxygen.3a EPP ready last week. + +Oxygen.3a GA 11/04/18 + +### Post Photon SimRel status + +After the last call, it was asked to Ed to bring at the board level our +discussion about naming & planning council role. See the previous +minutes & the bugzilla for details. The conclusion of this topic for the +board is that the planning council is for all the Eclipse projects and +the Simultaneaous Release could include all Eclipse projects. The board +does not care about the naming. The planning council concludes that the +naming must be inclusive enough. It was decided to use the following +pattern for the name : Eclipse MM-YYYY. + +The urls should be : SimultaneousReleases/year/month. + +Dani explains that the platforms will just drop the bits for M1 & M3 in +order that people can build EPP & do tests. In order to be aligned with +the release train the first platfrm milestone will be named M2. + +Then it was discussed that we should care about moving the release dates +to be able to keep up to date with the java releases in order to reduce +the effort of making a specific Java support release as we did this +year. + +Finally, Ed pointed the fact that we should recommend to projects to +have a latest repo in order to easily get the latest nightly build. + +### Planning council call + +We had few participants again during this call, remind that when you are +not available for the call you must send a representative. Some of the +participants suggested to update the call time, Mélanie will send a mail +to vote for a new time for this recurring call. Mélanie will contact +also recurring missing members to remind them to participate or to +propose a new representative. \ No newline at end of file diff --git a/wiki/Planning_Council/August_01_2012.md b/wiki/Planning_Council/August_01_2012.md new file mode 100644 index 0000000..d16c557 --- /dev/null +++ b/wiki/Planning_Council/August_01_2012.md @@ -0,0 +1,322 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 01, 2012, at 1200 Eastern

Dial in:

NOTE CHANGE: First meeting to use Asterisk service:

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

D to David Williams

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull (Plus Jesse, transition)

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

R

Achim Loerke

BREDEX (Strategic Developer)

D to Markus Tiede

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Ian Bull as new Rt PMC representative + - Welcome Steffen Pingel as new Mylyn PMC representative (maybe not + official yet?) + - Change in [strategic + membership](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) + and hence PC representatives: + + + + - + + - + Motorola and Cloudsmith no longer strategic members. + Talend new member. + +## Juno SR1 + + - SR1 dates have already been set, agreed to, and are coming right + up\! See + [Juno/Simultaneous_Release_Plan\#Service_Releases](Juno/Simultaneous_Release_Plan#Service_Releases "wikilink") + + + + - + + - + Comments, questions, concerns? + + + + - + + - + *None* + +## Kepler + +We will focus on requirements changes (if any) in subsequent meetings +... but for now, is there agreements on my proposed dates? They are very +similar pattern as previous years: +[Kepler/Simultaneous_Release_Plan\#Schedule](Kepler/Simultaneous_Release_Plan#Schedule "wikilink") + +*Agreement with the dates* + +## Start annual debrief + + - [Juno_retrospective](Planning_Council/Juno_retrospective.md) + + + + - + Feel free to add things to the page before the meeting, if that + would facilitate discussion. + + + + - + *Some good points raised. We will re-visit in September.* + + + + - + Be sure to read last years: + [Indigo_retrospective](Planning_Council/Indigo_retrospective.md) + +## Other Business + + - Comments on migrating aggregation files to Git? See . + +*Wayne officially approved using "org.eclipse.simrel" as package names, +even though "simrel" is not an Eclipse Project, in the normal sense.* + +*No issues with transitioning this coming week.* + + - *It was asked if "b3 aggregator" would be replaced by something in + CBI.* + + + + - + *Answer was "no, no plans at this time". Tycho itself produces a + simple repo but does not do any other "repo validation and + publishing" like b3 aggregator does.* + +## Next Meeting + + - September 5, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + + + + - + + - + Conclude (if needed) our yearly "debrief" on what went well, + what could be better. + Plan for Kepler + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_03_2011.md b/wiki/Planning_Council/August_03_2011.md new file mode 100644 index 0000000..2519902 --- /dev/null +++ b/wiki/Planning_Council/August_03_2011.md @@ -0,0 +1,309 @@ +## Logistics + +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, August 03, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=08&day=03&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

N

??

?TPTP? (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Y

Jesse McConnell

Rt (PMC)

Y (plus Tom)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - Welcome Jesse McConnell (new Rt PMC representative, replacing Tom + Watson) + +## Indigo SR1 + +First RC (warm-up) build is coming up soon (8/15-8/19). See [Indigo SR1 +Schedule](http://wiki.eclipse.org/Indigo/Simultaneous_Release_Plan#SR1) + +On the topic of "Can new things show up in Sim. Release Service +Releases?" ... we have previously agreed "yes". Any discussion? + +*It was was suggested we have a FAQ to document this, and to make it +clear, those projects still need to have a "release review" per normal +EDP rules. It is up to the project to initiate that release review, and +up to their PMC to "monitor" (all) their projects to make sure they are +following the Eclipse rules, but, as with any other Eclipse Citizen, if +the Planning Council happens to notice someone might be breaking the EDP +rules, we can certainly point that out to them or the PC rep. The "new +content" in SR can be completely new, or possibly a minor bump in +feature versions. The FAQ should also strongly word the new content must +still meet all the other requirements of the Simultaneous Release, such +as signed, externalized strings, etc. In fact, the "requirement" that a +project "do no harm" might, in practice, rule out some "low level" +features from a having a minor version increase in the common +repository. In other words, adding a "leaf" project is relatively easy, +changing a low level one requires lot of communication, checking, and +testing. \[dw agreed to write the FAQ for PC to review\]* + +*New FAQ written at [Can a new project or feature join a Simultaneous +Service Release (SR1 or +SR2)?](SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F "wikilink")* + +## Juno Release Planning + +### Juno Dates + + - + Release: June 27, 2012 (fourth Wednesday) + SR1: September 28, 2012 (fourth Friday) + SR2: February 22, 2013 (fourth Friday) + +See [proposed plan for proposed milestone +dates](http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Schedule). + +Issue: We have a 53 week development year ... 6/22/2011 to 6/27/2012 +(due to the way "fourth Wednesdays" fall) ... so what to do with extra +week? + + - M7 extra long, 8 weeks instead of 7? + - M6 longer than usual, 7 weeks instead of 6? \<-- my recommendation, + so that M6 ends "right before" EclispeCon? + +*It was agreed we would put the extra week in M6, this year. Another +advantage mentioned is that that is API freeze milestone, so if "extra +time" is available, that'd be a good place for it. It does put the end +of M6 right up to the Friday before EclipseCon. That's good in that it +might allow fixes to be made to M6 as people prepare their EclipseCon +demos, tutorials, etc. but also has the disadvantage of having "breaks" +right before EclispeCon, and also people not being able to get "clean" +M6 copies before EclipseCon. Pros and Cons balance, was the collective +view. It has actually been "the Friday before EclipseCon" for several +years ... though, it did used to be a week earlier. We will leave the +open for one week in case others have comments/concerns, then consider +it final after 8/10*. + +### Juno Requirements + +#### 4.2 vs. 3.8 + +We will have 4.2 as primary (hence the one used for EPP Packages) but +ask participating projects to have a clear plan item titled, exactly, +"Support for Eclipse 3.8 workbench" where possible descriptions might be +similar to: + + - Not at all. No support for 3.8 based apps. + + + + - We will accept bugs against 3.8 based apps, but do not test or + compile against it. + + + + - We will compile against and somewhat test 3.8, though 4.2 is + primary. + + + + - We will support 3.8 as well as 4.2, but the exact functionality may + differ. + + + + - We will support 3.8 and 4.2 equally. + +## Next Meeting + + - September 7, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + - "retrospective" at September meeting. + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_03_2016.md b/wiki/Planning_Council/August_03_2016.md new file mode 100644 index 0000000..ecb1cf4 --- /dev/null +++ b/wiki/Planning_Council/August_03_2016.md @@ -0,0 +1,439 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 8, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

R

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

D (Colin Ritchie)

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Y

Alexander Nyssen

itemis AG (Strategic Developer)

Y

Nick Boldt

Redhat (Strategic Developer)

R

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

EPP (appointed)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

R!

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Dates (and RCs) for Neon.1 (etc.) approved via mailing list. + + + + - + \- Calendar updated through "end of year" (still need to do 2017). + +## Oxygen Planning + + - Date for milestones, RCs and release approved via mailing list. + + + + - + \- Calendar updated through "end of year" (still need to do 2017). + + + + - ACTION ITEM: from the [mailing + list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02626.html): + Improve "Plan" wording about "format" and "when it is due". + + + + - + \- DONE: See [Wayne's + response](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02627.html) + \- Briefly discussed "what plan is expected" and Wayne said "not + much" from EDT point of view. No one on council seemed to want more + (at this meeting) for Simultaneous Release. + + + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. See . + + + + - + \- **ACTION ITEM:** Wayne to discuss with Ian on how best to get + more data from our community of users. + \- DONE (mostly): Wayne said Ian thought we didn't have a specific + enough "problem" to ask general users about. + \- Further discussion in the meeting lead to the idea that one thing + that is missing is what DO we call the "think" we are releasing. + "Eclipse Neon" seems too vague and definitely sounds like a + different thing than "Eclipse Mars" (even if you add "release". Some + quick suggestions were "Eclipse IDE - Neon Version" or similar (with + dates, probably). + + + + - \- ACTION ITEM: Doug said he would try to re-ignite the discussion + via blog or similar. + + + + - + \*- Main point is that we owe the community some response on bug + 493490 about what our plan will be. + +### old (ongoing) stuff + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In M6 we changed to have (nearly) all features to be "root features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **Impossible now, for Neon. Right? (for EPP Packages) Do we + still need "streamless-URL" now?** I am assuming "no". + + + + - + + - + ***ACTION ITEM** from 6/8 meeting. Doug volunteered to "take up" + this item to better specify "what does it mean" and "what will + it take" to update across major releases. \[Doug, it is up to + you, but I suggest you form a small team of like 3 people, such + as Ian and Dani or, others who know some of the technical + issues, to help if they are able and willing.\] The goal being + just a more specific statement of what it means, and what + projects have to do differently for Oxygen. That is, we don't + need to reach Nirvana in one release cycle.* + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + Preferences, views, etc. have to "migrate" (if their ID + changes). + What testing would projects have to do? + May become "defacto requirement" once is implemented. + - + For Neon we will not have a "streamless" URL, since "won't + work" for upgrading to Neon for the EPP packages. + +## New Business + + - ''Wayne could not make the meeting, but posted a [message to our + mailing + list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02606.html) + about concern over some specific projects -- some of which may have + to be "removed" from the train. But, in addition, expressed concern + over "the process". + + + + - + \- ''I agree and commented on a similar issue on [cross-project + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13122.html) + about two projects who "declared intent", but thought they could + join the build at the last minute. '' + \- *I wondered out loud if it was time for more of a Sim. Release + process where projects had to "prove they were ready to be in the + Sim. Release" instead of us just saying what they needed to do, and + then assume they were doing it. We did not discuss at this meeting, + but, for example, I mean like a checklist (web app) that has to be + updated every milestone? Just an idea.* + + + + - A question was raised if people have to "announce" they will be in + "Neon.1" if they were in Neon. The answer was "no". \[Did not + mention it at meeting, but they should announce if they are NOT + going to be in Neon.1.\] + + + + - + \- This led to a brief discussion if projects should "rebuild" if + their prereqs change. For example, if a security bug is found in an + Orbit bundle. A few thought "yes", but seemed the consensus was + "there was no way we could force them to" (i.e. can not leave them + out, or else their "previous release" would still be there with the + bad bundle) and it was probably a fringe enough case we did not need + to have a rule about it. + + + + - A question was raised how we can avoid issues such as with Neon + where Window Builder was excluded for Neon. They were ready at the + very very last minute but had not done any builds or testing for all + of Neon. Somehow, we should "detect" when projects are not active so + we can approach them early to find out if the project is viable, if + they are testing, etc. + +## Next Meeting + + - September 7, 2016 - Regular First Wednesday Meeting + +## Reference + + - + Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + + + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_04_2010.md b/wiki/Planning_Council/August_04_2010.md new file mode 100644 index 0000000..0e63890 --- /dev/null +++ b/wiki/Planning_Council/August_04_2010.md @@ -0,0 +1,275 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, August 04, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=08&day=4&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Oliver Cole

Tptp (PMC)

Brian Payton

Datatools (PMC)

Anthony Hunter

Tools (PMC)

Oisin Hurley

Stp (PMC)

Ed Merks

Modeling (PMC)

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)

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)

+


+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.

+ + + +## Announcements + + - ? + +## Helios SR1 + +Soon to switch to b3 aggregator format files. + +Warm up (RC1) builds to start soon (8/9 to 8/13). + +### Maintenance Schedule + +SR1 Fourth Friday of September 9/24/2010 + +SR2 Fourth Friday of February 2/25/2011 + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Helios Retrospective + +Any additions? + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +## Indigo Plan and Schedule + +Tracking "setup" required from Foundation in + +See initial [Indigo Wiki page](indigo "wikilink") + +Are we agreed to +\[| +Indigo dates \]? All shifted by one calendar day (to keep same day of +week). Can we say these are official? + +### Issues and Proposal for 3.7 versus 4.1 + +For planning documents, etc. we'll call 3.7 based work Indigo Minor, and +4.1 based work Indigo Major. + +For this plan, more so than previous years, there will need to be +adjustments based on experience over next few months. + +Ideally focus would be on 4.1 based work. But final plans need to be +based on where projects want to focus, and what proves suitable. + +Main goal: participating projects must work with or contribute to both +platform levels. + +There's several options to accomplish this -- and participating projects +must explicitly state what their plans are, what they support. + + - One set of plugins work with both versions. + + + + - Projects contribute "maintenance only" to Indigo Minor, but branch + and all new work done assumes Indigo Major + +EPP Packages: Ideally, EPP packages would be based on 4.1 (only). If +experience shows 4.1 is not ready, or if projects can not fully move to +4.1, then this needs to be dropped back to 3.7 (only). Is is possible +that each "package owner" can decide which they want. \[Would this make +sense?\] Is is a fair assumption to say its unreasonable to produce two +sets of packages? (I think so, but others can answer too). + +Issue: Can all bundles reside in one repo, and correct ones "pulled out" +by P2? (can this be done easily, and reliably, that is). + +Issue: If focus is on one stack, how to "test" other stack? + +Feedback required from large projects such as webtools, CDT + +Issues raised in meeting: + + - Branding. Is it really one simultaneous release? Or two? Is one name + (Indigo) enough? Does Indigo Major and Indigo Minor suffice? Or, do + we need a whole additional code name? + - Provisioning? Often adopters provide an "all in one" product + package, but they also want to "install into existing installation". + So, what/how can they "install into". How to document and explain to + users and customers? + - Its one thing to conceive of one different "platform" in stack, but + if or when there are different versions at higher levels, seems to + get very complicated (e.g. if JDT has an Indigo Major vs. Indigo + Minor version, that might "force" projects to take different + planning paths. Its unclear what their plans are, and if the e4 + related function would be "additive" to Indigo Minor bundles, or + complete replacements. + - Need another meeting in a few weeks to make progress on this issue. + +## Other business + + - ? + +## ToDo Items + + - ? + +## Next Meeting + +August 18, 12 noon (Eastern) September 1, 12 noon (Eastern) + +## Reference + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_05_2009.md b/wiki/Planning_Council/August_05_2009.md new file mode 100644 index 0000000..9e55270 --- /dev/null +++ b/wiki/Planning_Council/August_05_2009.md @@ -0,0 +1,353 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, August 05, 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=8&day=5&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

Cedric Brun

OBEO (Strategic Developer)

Oliver Cole

Tptp (PMC)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Brian Payton

Datatools (PMC)

Y

Doug Gaff

Dsdp (PMC)

Neil Hauge

Oracle (Strategic Developer)

Mika Hoikkala

Nokia (Strategic Developer)

Anthony Hunter

Tools (PMC)

Oisin Hurley

Stp (PMC)

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

Ed Merks

Modeling (PMC)

Mike Milinkovich

Eclipse Foundation (appointed)

Kaloyan Raev

SAP AG (Strategic Developer)

Y

James Saliba

CA Inc. (Strategic Developer)

Sebastian Voigt

brox IT-Solutions GmbH (Strategic Developer)

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+


+Note: feel free to correct any errors/omissions in above attendance record.
+Y = attended
+R = regrets sent ahead of time

+ +## Topics + + - Announcements: + + + + - + + - + Congratulations and condolences to John Arthorne as new PC rep + from Eclipse PMC + Congratulations and condolences to Oisin Hurley as [new + EclipseCon program + chair](http://eclipse-projects.blogspot.com/2009/07/announcing-fabulous-eclipsecon-2010.html)\! + Congratulations and condolences to Brian Payton as new DTP rep + + + + - Finalize [SR1 Plan](Galileo_Simultaneous_Release#SR1 "wikilink"). + +:\* Now considered final. + +:\* A concern was raised that Platform's build is just to day, they are +not sure everyone knew and are ready for a delivery next Monday ... but, +first RC isn't critical if they can't update (but probably can). + +:\*A concern raised that in general given +0 is on Monday, and finalized +on Friday, that there could be a long period before a regression +(discovered, say, on Thursday or Friday) was fixed, since Thursday or +Friday is too late for following week's Platform. But ... + +::\*For one, there's nothing stopping highly dependent projects or +adopters from doing their testing earlier. For example, WTP doesn't have +to wait for the Common Discovery Repository delivery before starting +their testing. + +::\*For another, exceptions can be worked out on a case-by-case bases, +patches supplied, etc., if for example, a regression was so bad it +prevented another project or adopter from doing their testing. (I would +say this is unlikely ... but it does happen). + + - Review [Planning Council/Galileo + postmortem](Galileo_postmortem.md). + + + + - + + - + It was mentioned (from Eclipse Platform team) that they didn't + participate in forming these notes, but that it corresponds to + their own team-meeting notes, except they would have also added + the "+1", "+2" categories of dependencies may be too simplified, + since in reality, some projects need to deliver part of their + components, say, at +0 or +1, but another leaf component at +2 + or +3). They would also appreciate making sure that the + simultaneous release criteria be better explained. + We'll continually review list to make sure issues addressed, + action plans made, owners found, etc. + + + + - Begin Helios Discussions + +:\*similar process of having Common Discover Site + +:\*similar criteria? + + - + + - + to be in Common Discover Site + to be in Release + + + + - + But with graduated levels of achievement where appropriate (e.g. + 5 levels from none to excellent) + Instead of "pass/fail", require a "statement of intent" for each + item as part of Project Plan. + - + For example, some projects might declare "no intent to + support accessibility checklists". + Projects would still be excluded on a case by case bases, if + felt they interfered with the process, or other projects + functionality, but otherwise try to get more "consumer + oriented". + ''It was thought the above ideas worth pursuing (at least to the + point of making more concrete, for review). Nothing firm + decided. '' + +:\*Hot Items? *No time to discuss this topic.* + + - + + - + Granularity: sub-Projects vs. Top Level Project? + capabilities definitions and process? + others? + + + + - Helios Dates: + +*These dates were agreed to, with the change of using 4th Wednesday of +June, instead of last Wednesday of June, for the release*. + + - + + - + 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) + + + + - + Notes regarding the +0, +1, +2, +3, EPP, and 'available' days + :\*The first three milestones use a two-week window and the + remaining milestones use 1-week windows. + :\*The sub-deadline patterns within the windows are as follows: + +| \+0 | | \+1 | \+2 | \+3 | EPP | Available | +| ------ | --- | --- | --- | --- | --- | --------- | +| Friday | Sat | Sun | Mon | Tue | Wed | Thur | + +2-week window pattern + + - + + - + + +| \+0 | \+1 | \+2 | \+3 | EPP | Available | +| ------ | ------ | ------- | --------- | -------- | --------- | +| Friday | Monday | Tuesday | Wednesday | Thursday | Friday | + +1-week window pattern + +::\*This pattern was arrived at with a couple of considerations: a) it +is very important that teams have a consistent rhythm (so, for example, +easier for a team to "always deliver on Tuesday" rather than Monday's +some milestones, Thursdays other milestones, etc. b) it represents the +**latest** possible time to produce common-discovery site ... teams can, +still, either on their own or work with other projects to do their final +builds earlier, making their delivery available earlier to specific +teams or test groups. + +::\*Remember, the +n categories represent **latest** possible time to +complete what is required of common discovery site (generally, at noon, +Eastern time, of the day). Teams have to do their builds and testing +before these common-site deadlines. + +::\*In general, teams often have complicated inter-dependencies which +are not captured by the simple "+1", "+2" descriptions. In those cases, +it is up to those projects to work out their detailed inter-dependencies +and agree to a processes to satisfy what they need from each other. The +dates and deadlines listed by Planning Council, apply only to the final +deliverable to the common repository. + + + + - Do we have the right members? What to do about those that are + inactive? + + + + - + + - + For reference, there are 14 [Strategic + Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) + + + + - + *It was decided to form "inactive" list, and work with Strategic + members and/or EMO to get someone who can be active. Also, to better + document benefits of participation.* + + + + - Next Meeting + + + + - + September 2, Wednesday, Noon Eastern Time. + +## Reference + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") +and +[Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_05_2015.md b/wiki/Planning_Council/August_05_2015.md new file mode 100644 index 0000000..4ea38a3 --- /dev/null +++ b/wiki/Planning_Council/August_05_2015.md @@ -0,0 +1,429 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 5, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (occasional)

Cloud (PMC)

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel (Sam Davis)

Mylyn (ALM) PMC

D (?Chan?)

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

R

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before meeting, but if questions or + issues with previous minutes, this would be a good time to bring + them up. + +## Mars Planning + + - Any issues? + + + + - What to call September and February releases? + +:\* Propose to change name to "Mars.1" and "Mars.2" to avoid the +"service release" terminology, as one way to better reflect the rules +that have been in place for years (See [Policy +FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink")), and perhaps +name change alone would help correct the mis-perception that "new things +can be added only once per year". For some recent history discussion, on +how we ended up proposing a "point number", see [mailing list +thread](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02487.html) +on the topic. + + - + \- Largest impact would be to change "MarsSRn" type phrases to + simply "Mars.n" in the few places it is used. + \- When generic words are needed, instead of numbers, the June + Simultaneous Release can be called "the initial yearly Simultaneous + Release" and subsequent ones, when generic wording is needed can be + called "update (number)" or "point number" or "dot number". For + example, "Our project typically does XYZ in the first update, not + the initial release". + \- This terminology applies primarily to the "Simultaneous Release". + Individual projects should still refer to their releases as + accurately as possible (service release, or minor release, if not + specific number). + \* The "Policy" (currently in Policy FAQ) will be "moved up" to the + actual "plan" document. (Just as well move both items into the Plan, + even if as footnotes.) + - + \> In general, "the policy" will emphasize that new projects can + join in subsequent, as well as initial releases and projects can + contribute "minor releases" as well as "service releases" ... it + is up to the project. But, a) must be "backwards compatible" + with that train (for example, a minor release that changes + "internal methods" into API, should leave the "internal methods" + in place, but deprecated) and b) almost never would be a "major + release" -- the project would have to be a pure leaf component + in Simultaneous Release, and have good reason to believe would + not effect any adopters (hard to do, in practice), and would + require "exception process" in Planning Council (partially as + sanity check, but primarily to ensure well communicated). + \- We need to (also) add milestones for update releases. I propose + we have two milestones, M1 \[not sure when, yet\], and M2 become + what we currently call the "warm-up RC". So, we would end up the 2 + milestones, and 3 RC's. The milestones are needed primarily for + those new projects joining, or those adding large new features. But, + as with mainline development, everyone should contribute "their + latest", even if just working on service. + - + \> New Projects or features would have to be in the aggregation + build by M2 \[Or, should we be stricter, and say M1? -- at + least, for Neon's subsequent releases?\] + \> \[TODO: More of a Neon Item, but consider having more than 2 + streams being aggregated. Purpose would be to better enable + projects to be working on Update+2 before everyone else is + finished with Update+1 (for example).\] + + + + - Summary of discussion + + + + - + \- In the end, Simultaneous Release name for September and February + releases agreed to was "Mars.1", "Mars.2". This is the main name + that will occur in announcements, URLs, and "about box", and similar + -- anything that refers to a specific release. Initial releases will + still be named without numeral, such as "Neon". + \- It was also agreed that when a generic term is needed, then an + informal "update" or "update release" is suitable, such as "We'll + fix that in an update release". We considered the proposal of having + "Update" in the name, such as "Mars Update 1" but some thought that + would make URLs, and some names unnecessarily long, and for some + there might be an implication that "update" meant about the same + thing as "service" so we thought best to be as generic as possible. + The does indirectly imply a "minor + release" (but, that's only if you know about OSGi semantic naming + ... so, pretty generic for most users). The generic term "update" + was thought better that "minor release" since a) "minor release" + does not have any "industry wide" meaning; b) many projects may + still do only "service releases" so did not want to imply every + project "had to be" a minor release. Its believed too, that this + matches what a fair number of projects and products in the industry + do -- have a "main (or major) release" and "dot (or point) releases" + and "service releases". + \- Had a LONG discussion about "what an update release means" ... + some thought it still implied "nothing new", but most agreed it + obviously means "nothing breaking". Some (who missed meetings where + this was previously discussed) questioned "why not allow breaking" + changes -- completely new releases -- but some adopters in meeting + spoke up on the need and importance to have "nothing breaking". + - + \- While we agreed with the new emphasis on "users needs" we + reiterated our desire to balance that with not only adopters + needs, but more so committers needs ... every "coordinated + release" is extra work for committers, on a number of levels. If + nothing else, even if a project did not change anything + themselves, they might be effected by changes someone else made + in Simultaneous Release repo. Even a +3 project can effect a +1 + project, given the nature of plugins. They would not directly + break compiling code, but they can change the order that things + are done, or effect some critical path section of performance, + and other indirect effects. + \- It was agreed, that even breaking API changes might sometimes + be allowed in an update release, but that would be handled under + current Exception Process. The types of use-cases where this + might make sense is for a leaf project (effects nothing else in + Sim. Release) and where the project is fairly sure there are no + adopters yet (such as new, incubating project) or where + communication with adopters is thought to be adequate and + adopters have indicated their desire for the breaking change. + TODO: document this sort of exception explicitly in "Update + Release" description (to be in the Plan document). + \- After meeting, I realized we never discussed things like + "translations". Having something "new" in an update release, + could break some adopters "product translations" (that is, + English might "show up" in a translated product, if some "new + feature" was picked up by customer) but ... that seems to be + fairly low risk and low impact. + \- Some discussion of how much this was like "wild west" -- + especially considering long term potential process changes where + projects could update even more frequently. Only conclusion was + that to avoid "wild west" chaos was one reason to still have a + "coordinated release" and if users want to get latest release of + "uncoordinated changes" from some particular project, then they + should have to take explicit action, such as adding a new URL to + their software site repository list. This does have some + implications: projects should not automatically add reference + repositories to software site lists that are generic or "high + level" and which could automatically pick up new releases with + breaking changes. (I think everyone knows that, already). + \- There was some talk about how to make it so that EPP packages + could be "updated" by individual projects, without getting too + "wild west" about it. Left for future discussions. + \- There was some talk about how to better test packages + automatically, so for future, especially if "very frequent" + updates, there would not be too much increased burden on + project's committers to test EPP pages (say, if individual + projects in EPP packages released changes every month, every few + weeks?). Again, mostly left for future. Wayne did mentioned + Eclipse Foundation might be able to help fund/staff some + "automated testing" effort -- though, I am sure he was now aware + of how large this effort could be. :) + \- There was no talk of if or how "Oomph" played a role in "more + frequent releases", if any. Also left to future discussions of + having milestones in "Update Release" streams (not just RCs) or + more than two "update streams". Also left to future (not + discussed) was the idea of having having a single Sim. Release + repository instead of composite) which will become more + important, as we have more update releases. + \- Another thing not discussed, was the inability to remove + features, in an update release. (See ). + \- There was a repeat of statement of our desire to have 3 Update + Releases for Neon (not two). TODO: need to propose dates soon\! + \- It was agreed the Plan was the best place to put primary + description of "Update Release" (and deprecate that unfindable + "Policy FAQ"), but for Neon, to also add a section in Requirements + to better describe exactly what requirements are, for Update + Releases, such as when new projects need to be in a build. TODO: I + will update Mars Plan soon, give PC a short time to review for + errors, and then announce on cross-project list. + +## Neon Planning + + - See initial working draft of plan at + [Neon/Simultaneous_Release_Plan](Neon/Simultaneous_Release_Plan "wikilink"). + - Continuing Discussion of if and how to change "yearly release"? + - \- See ["design" wiki + page](SimRel/ChangingProcessAndTiming "wikilink"), which acts as + centralized place to document the main ideas and plans. + - Was there (and was there any good discussion) at possible meetup + during EclipseCon France - see + [PlanningCouncilToulouse](PlanningCouncilToulouse "wikilink"). + +## New Business + + - ? + +## Next Meeting + + - September 5, 2015 - Regular First Wednesday Meeting + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_06_2008.md b/wiki/Planning_Council/August_06_2008.md new file mode 100644 index 0000000..11c7374 --- /dev/null +++ b/wiki/Planning_Council/August_06_2008.md @@ -0,0 +1,99 @@ +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Thursday [August 06, 2008](August_06,_2008 "wikilink") at [1500 UTC / 0800 SFO / 1100 NYC / 1600 London / 1700 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2008&month=8&day=6&hour=15&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Bjorn Freeman-Benson + - Martin Oberhuber (for Doug Gaff) + - Ed Merks + - Anthony Hunter (for John Duimovich) + - John Graham + - Oliver Cole + - David Williams + - Neil Hauge + - Brian Fitzpatrick (came in late in the call, sorry) + +## Topics + + - Planning Council rotating chair position + - Is the current + [list](http://www.eclipse.org/org/foundation/council.php#planning) + of PC members accurate? + - Call and meeting schedule: + - Monthly until the train is rolling, then more frequently? - + **start with monthly calls** + - In person meeting to coincide with September Board meeting + (Dallas, TX), [EclipseWorld](http://www.eclipseworld.net), or + [Eclipse Summit + Europe](http://www.eclipsecon.org/summiteurope2008/)? Other + time? - **shoot for Sept in Dallas** (pun intended) + - December 10-11, 2008 - plenary session with Board + - 2009 release (a.k.a. 'Galileo'): + - must do and should do list update (deadline?) - **to be + discussed at next in-person meeting** + - dates (see [Galileo Simultaneous + Release](Galileo_Simultaneous_Release "wikilink")) - **initial + list OK, but M1 dates will be removed and conflicts raised as we + proceed** + - do we want update site, packages, or both? - **still undecided, + pending investigate of p2 capabilities** + - do we want to improve packaging/testing? - **starts with + providing a Galileo all-in-one download?** + - naming strategy moving forward - **agreed the community can + decide, Anthony proposed a contest to coincide with EclipseCon** + - [Project + Plan](http://wiki.eclipse.org/Development_Resources/Project_Plan) + (format and delivery) - **look at details during next in-person + meeting** + - Board interaction - **not much interest, it seems - though, plenary + sessions may be sufficient** + - Interested in IP process improvement discussion? - **potential PC + involvement, to be discussed at next in-person meeting** + +## Additional Topics + +\[Not necessarily in order ... before the meeting, the Program Chair can +blend with main list and order them depending on overall priorities.\] + + - Do we have an accurate, active [Planning Council member + list](http://www.eclipse.org/org/foundation/council.php)? + - What's the connection between simultaneous release, EPP packages, + and Planning Council? That is, what is our (Planning Council) + response to + [bug 238960](https://bugs.eclipse.org/bugs/show_bug.cgi?id=238960)? + Is it "none of our business"? and EPP can do what they want? If we + (Planning Council) do play a role, then what is the connection of + packages to the yearly simultaneous release? That is, should we + "insist" on one opportunity per year to create packages? Or, should + we have more than one semi-simultaneous release to accommodate "off + cycle" projects? + - Let's pick a new name for the 2009 simultaneous release. Just + kidding\!\!\! But, we should discuss what the process is. Do we, + Planning Council want to decide ourselves (for a 2010 release)? It + appears "the community" really, really\! likes participating. Should + we just always have a yearly "contest" like we did the first year? + - When should we document the "must do" lists for Galileo Release? I'd + assume we'd want to raise the bar a bit, so should be done done soon + so Projects can plan/decide if they want to and be able to + participate. + +## Action Items + + - ~~Propose the next in-person meeting to align with Board meeting in + Dallas, TX on Tuesday, Sept 16th.~~ (Rich) + - ~~Propose a monthly PC call the first Wednesday of each month at + 11:00 Eastern US time.~~ (Rich) + - Send Donald a list of missing/incorrect Planning Council members + found [here](http://www.eclipse.org/org/foundation/council.php) + (All) + - Investigate the use of p2 to create a "virtual" simultaneous release + update site, sans the jar copying (Rich) + - ~~Remove M1 from the Galileo release date calendar.~~ (Rich) + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) + - ~~Invite Janet to next in-person meeting (Dallas?) to discuss IP + process improvements.~~ (Rich) \ No newline at end of file diff --git a/wiki/Planning_Council/August_06_2014.md b/wiki/Planning_Council/August_06_2014.md new file mode 100644 index 0000000..3392fd3 --- /dev/null +++ b/wiki/Planning_Council/August_06_2014.md @@ -0,0 +1,328 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 6, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting + minutes](June_04_2014.md). + +## Luna SR1 + + - + Any issues? + + + + - + + - + *ECF Plans to contribute 'minor release'. No known issue with + that. Would be good if it was communicated well (e.g. what the + new function was, and what was **not** changing, such as assume + function used by p2 is not changing?* + *There is some question about 'httpcompnents' level (See - + Consider changing httpcomponents for Luna SR1), but seems + impossible to have a coordinated "downgrade". Will investigate + "moving up", but appears unlikely that would help. One + difficulty is having the right committers have access to the + right kind of proxy server that exhibited the regression. (see + bug for details).* + + + + - + Remember that SR1 RC1 is just a few weeks away (and overlaps Mars + M1). + +## Mars Planning + + - + Please Review [the plan](Mars/Simultaneous_Release_Plan "wikilink"), + especially the + [dates](Mars/Simultaneous_Release_Plan#Schedule "wikilink"). Goal is + to finalize the dates, if we can. + Current dates follow same pattern as previous years. + But there is an issue with what to do with M6, since EclipseCon is a + week earlier than last year (and, I'm told, last year was a week + earlier than the year before). + + + + - + + - + *The general, if not strong, feeling was that moving M6 a week + earlier makes it way too short for a milestone, which also makes + M7 extremely long. The proposal is to delay M6 by a week (so + then most attending EclipseCon do not need to worry about the + typical "last week" milestone activities) which also has the + benefit that then M6 and M7 are more balanced, at 7 weeks each. + Only downside is that those that "need the latest" for + EclipseCon (e.g. for tutorial or demo), will have to make due + with M5 or their own custom combination of "I-builds". I will + update the plan document with these proposed dates, but since + small attendance today, will wait until next meeting before + deciding it is official, in case others have other suggestions. + No one proposed we move EclipseCon. :)* + + + + - + *Note, though, that even extending it one week means those providing + +0 contributions would still be busy during EclipseCon with + final-week milestone activities.* + + + + - + *After the meeting, while editing the schedule, realized that might + be better to also extend M5 by one week. In the past, we always had + that be one of the "7 week" milestones, since most are on holiday + for at least a week during that period over the "end of the year". + In other words, M5 would be 7 weeks long, M6 be 6 weeks long, and M7 + be 7 weeks long. Obviously, some tweaks could be made to avoid the + +0 problem mentioned above ... extend M5 by a week, extend M6 by 2 + weeks (from original), so then M5 and M6 would each be 7 weeks long, + and M7 would be 6 weeks long.* + +## Progress on Action Items + + - Split stream aggregation builds (about half done, should finish + later today) + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + +## New Business + + - ? + +## Next Meeting + + - September 3, 2014 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_18_2010.md b/wiki/Planning_Council/August_18_2010.md new file mode 100644 index 0000000..6bd91da --- /dev/null +++ b/wiki/Planning_Council/August_18_2010.md @@ -0,0 +1,224 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, August 18, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=08&day=18&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne [and Paul Webster]

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Brian Payton

Datatools (PMC)

R

Anthony Hunter

Tools (PMC)

N

Oisin Hurley

Stp (PMC)

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

N

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

N

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

N

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

R

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - ? + +## Helios SR1 + + - ? + +### Maintenance Schedule + +SR1 Fourth Friday of September 9/24/2010 + +SR2 Fourth Friday of February 2/25/2011 + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Helios Retrospective + +Any additions? + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +## Indigo Plan and Schedule + +Tracking "setup" required from Foundation in + +See initial [Indigo Wiki page](indigo "wikilink") + +Are we agreed to +\[| +Indigo dates \]? All shifted by one calendar day (to keep same day of +week). Can we say these are official? + +### Issues and Proposal for 3.7 versus 4.1 + + - See working notes in + + +## Other business + + - ? + +## ToDo Items + + - ? + +## Next Meeting + +[September 15, 12 noon +(Eastern)](September_15_2010.md) + +## Reference + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/August_1_2018.md b/wiki/Planning_Council/August_1_2018.md new file mode 100644 index 0000000..78b5163 --- /dev/null +++ b/wiki/Planning_Council/August_1_2018.md @@ -0,0 +1,169 @@ +## Logistics + +**Pay attention time has changed, the meeting is one hour earlier than +before** + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 1, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Need chair for September, October & November meetings + - PC Call cadence + - 2018-09 : Status + - Opt-in process + - CQ deadline + - Update of the Simultaneous Release Requirements document : + + +## Attendance + +Aleksandar Kurtakov, Wayne Beaton, Frederic Gurr, Mikael Barbero, Martin +Lippert, Melanie Bats, Nick Boldt, Thomas Watson + +## Regrets + +Dani Megert + +## Notes + +### Need chair for September, October & November meetings + +Nick Boldt will be the Planning Council chair while Mélanie will be on +maternity leave (September, October & November), the next calls will be +on : + + - Sep 12 /\!\\ one week after the usual date (added to planning + council Google calendar) + - Oct 3 + - Nov 7 + +### PC Call cadence + +Nick proposed to re-think the Planning Council call cadence as the +Release train cadence changed. During the call it was discussed to +change the call to 3, 4 or 6 weeks, everyone aggreed to keep the actual +monthly call cadence and that if needed new call can be scheduled at any +time. + +### 2018-09 : Status + +M1 done, few changes around. Fred is working on free style jobs to +jenkins pipelines. M2 is coming up and M3 is for end of august. + +### Opt-in process + +It was discussed to clarify the opt-in process. The projects must +declare their intent once a year, our purpose is to be sure that they +are still paying attention. It was also discussed to just use the +aggregation files to detect whose in but it appears that some projects +are not contributing to the aggregation files but they are part of the +Simultaneaous Release. Wayne will start a conversation about that topic +on the Planning Council mailing list. We agreed that project could +declare their intent : + + - to continue to participate to the SimRel before M1 of the September + release, this means that they would participate to all the releases + from September to June. + - to integrate the SimRel before M1 of any releases. + - to drop off at any time. + +Mélanie will update the release requirements document accordingly. + +### CQ deadline + +Actually the CQ deadline was a 3 month deadline, as the entire cycle is +now compressed, Wayne proposed to put the CQ deadline to the end of the +3rd week in the release cycle, but we do not know what would be the IP +team workload. Alex said that we can't set deadline. It is convenient +for project to provide in last minutes some more dependencies used as +internal. He proposed to not provide deadlines but instead guidelines. +For example, CQ for external use should be done by M2. In general the +planning council would give advise and assume responsible behavior from +the projects. Wayne will rethink about how to manage the IP team work +queue & will continue the discussion on the Planning Council mailing +list. + +### Update of the Simultaneous Release Requirements document + +Mélanie updated the document and asks other to review it, it should be +updated accordingly to the opt-in process decision discussed before : + \ No newline at end of file diff --git a/wiki/Planning_Council/August_2_2017.md b/wiki/Planning_Council/August_2_2017.md new file mode 100644 index 0000000..e0bc743 --- /dev/null +++ b/wiki/Planning_Council/August_2_2017.md @@ -0,0 +1,244 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 02, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton, ~~interim chair~~ + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - OBEO (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + +### Date for Oxygen.1 release (Frederic Gurr) + +The Oxygen.1 release was planned for September 27, 2017. Since JDK 9 GA +is currently planned for September 21, I guess we need to realign. +However, moving the Oxygen.1 release to September 21 collides with the +Photon M2 release (September 22). Do we move Photon M2 to September 15 +or do we postpone it to September 29? Are there any alternatives? (see +also +) + +Suggestions raised in + involve +having JDT produce a release candidate build that includes Java 9 on +Sept 21. + + - Option \#1: Move the Oxygen.1 date to 2nd week October - GA on Oct + 11 or 18 + - Pro: neither of these conflict with the Photon dates (M2: + 09/15-22, M3: 10/27-11/03) + - Con: delays Oxygen support for JDK9 so we might lose market + share to other IDEs who can react faster (Mike's concern) + + + + - Option \#2: Add an extra release in October - GA on Oct 11 or 18 + - Pro: get out an .1 release in September, as we've always done, + even if it only has prelim support for JDK9 + - Con: more overhead to do another release, even if it's a "JDK9 + Update Only" change + + + + - Option \#3: Roll out Java 9 with Oxygen.2 in December (with + Marketplace-based rollout in the interim on Oct 11 or 18) + - Pro: regular update release schedule (Sept, Dec) is maintained; + early access support can be provided in Marketplace and updated + once finalized outside the simrel train schedule + - Con: might be perceived as being slow to market; marketplace + uptake might be small + +More recently, a 4th option was proposed in this thread: + + + - Option \#4: Move Oxygen.1 to mid-September (Sept 13?), with a + special JDK 9 / JUnit 5 Update release no more than a week later + (Sept 21?) (Dani's suggestion) + - Con: would require adjusting the Photon M2 dates (09/15-22) to + avoid overlap - could be 09/01-08 or 09/22-29 + - Pro: would allow prompt support for JDK 9 as close to the Sept + 21 GA date as possible + +## Notes + +### Attendance + +Stephan Merker (SAP) Tom Watson (IBM) Mikael Barbero (Eclipse +Foundation) Carl Anderson (Webtools PMC) Dani Megert (Eclipse PMC) +Melanie Bats (OBEO) Alexander Nyssen (Itemis) Fred Gurr (Eclipse +Foundation) Wayne Beaton (Eclipse Foundation) + +### Discussion + +Announcement: **Melanie Bats** is the new Eclipse Planning Council +Chair. Thanks, Melanie, for stepping up\! + +Fred walked us through the Oxygen.1 date options captured in the agenda. + +Fred: Date for the Oxygen.1 release. Currently September 27. Java 9’s +release date is September 21. Do we want to have these on the same date? +Note that Photon M2 release is in that week. + +Mikael: why is it an issue that Photon M2 and Oxygen.1 collide? + +Fred: definitely possible. Just complex. If anything goes wrong, there +could be delays. + +Dani: availability of resources to test things is an issue. + +Dani: direction from most people on last call. Update 1 without Java 9. +We can easily ship Java 9 + JUnit 5 support via Marketplace. More +predictable update schedule is more important that moving the date to +accommodate the new features. Oxygen.1 on Sept. 27 does not include Java +9 support. JDT will make an official release via Marketplace on Sept. +21. Target a Oxygen.1a release on October 11 that will include Java 9 +and JUnit 5. This will be included in updates to all users. Oxygen.1 +will be a stable usual release. JDT will issue updates as necessary. + +Dani: To put something into the extra release, a project must bring the +issue to their PMC. PMC brings it to the Planning Council for approval. +Oxygen.1a is for Java 9 and JUnit 5 related fixes only. The Planning +Council will decide what features will be included in Oxygen.1a. + +Wayne: After Oxygen.1a ships. If JDT identifies a critical bug, what +then? + +Dani: We’ll deal with that when we have to. + +**Conclusion: JDT will issue “official” Java 9 support via Marketplace +on Sept. 21/2017. Oxygen.1 will be released on September 27 without Java +9 or JUnit 5 support. Oxygen.1a on October 11/2017 will include Java +9+JUnit 5.** + +*Wayne's unvoiced observation: we're treating Oxygen.1 as an update +release. The Planning Council decided some time ago that these are not +update releases, but rather are more like minor (quarterly) releases and +it is okay for them to include new functionality. As we move forward +with Melanie's ideas (discussion started below; watch for the document +link), one big part of our challenge is break these old opinions and +habits.* + +Melanie will put a message on the mailing list to give the rest of the +Planning Council a chance to express concerns. + +Melanie: Mikael, Melanie, and Wayne have been discussing a change in the +way that we do the simultaneous release to be more of a rolling release +style. Melanie has reviewed how other open source organizations do +releases. We tried to image what could be done to the simultaneous +release. Melanie will distribute a working document that discusses this. +All members should please read the document. Melanie will start a thread +in the mailing list. + +Dani: The Eclipse project is planning to add a new top-level menu +labelled “Debug” for Photon. Nobody will be broken by the change, but to +avoid contributing menu items that look out of place, others projects +(and adopters) who contribute to the “Run” menu will have to change. +This is part of an effort to reorganize the Debug Perspective. The +Planning Council did not voice any dissent. Dani will put a note out on +the cross-project-issues-dev mailing list. + +Wayne; We’re rolling out some changes to the legal documentation. We +will not be asking projects that are following the current guidelines to +change. These changes are for projects using technology other than +Eclipse Platform Plug-ins and Features (e.g. for project that it makes +no sense to include an about.html file or a “Feature Blurb”). We will +regard the existing guidelines as a specific implementation of the more +general guidelines. We’re rolling those changes into the handbook and +will let the community know via the cross-project-issues-dev mailing +list. \ No newline at end of file diff --git a/wiki/Planning_Council/August_7_2013.md b/wiki/Planning_Council/August_7_2013.md new file mode 100644 index 0000000..0154321 --- /dev/null +++ b/wiki/Planning_Council/August_7_2013.md @@ -0,0 +1,579 @@ +## 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

R

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (or Bob Brodt?)

SOA (PMC)

Ed Merks

Modeling (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Y

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 . + + + + - + For reference, see [current + policy](SimRel/Simultaneous_Release_FAQ#Can_a_Simultaneous_Release_project_include_bundles_or_features_from_a_project_not_in_the_Simultaneous_Release.3F "wikilink"). + - + *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](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09221.html). + \[To be honest, I do not recall what specific situation this is + about?\] + + + + - + + - + *Ed explained the situation to us (involved 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 and not "adding features" with a + mere "service increment".* + + + + - 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](Luna/Simultaneous_Release_Plan "wikilink"). + - + *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 + + Possibly + \[Remember, we should make this decision based on principle, not + the one request for an "Ultimate Package" (), since a) we should + always work on principles\!, and b) this package may or may not + come to fruition.\] + - + *It was generally agreed 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 and 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 + . + For some fun reading, I looked up the original bug on how we got to + the names of "SR1/SR2" .. + For reference, see [current + policy](SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F "wikilink"). + + + + - + + - + *This item had a long discussion, covering many area, and for + the most part, the status quo will be maintained for now.* + + + + - + + - + *A couple of things seemed to be agreed upon:* + - + *1) This is not something to change "this year" ... + something longer term ... but, we need to continue the + discussion and sort out the issues and solve them in some + manner -- that is, there was no disagreement that the + current schedule/rhythm does not satisfy all adopters and + projects and we need to see if we can improve on that.* + ''2) Other groups/projects are leaning towards "continuous + delivery", why not us? (Or, do we already? :)" + *3) The _main_ issue (in terms of "deliverables") -- I + came to understand -- are the "EPP packages". That is, there + is nothing preventing projects from releasing any time they + would like to ... but the desire is that they'd like EPP + packages updated at the same time. Otherwise, only + "in-the-know" product adopters and a few savvy users know + how to go to a project-specific repo to get updates (or, + "new installs"). And ... some on planning council see that + as a bad thing (ha ha ... mostly my humor :) ... but ... + there are two sides to that story).* + *4) There appeared to be agreement that something like + "monthly releases" was not feasible ... too many places for + it to "go wrong" or cause lots of additional work for + projects (or, suffer from reduced quality). \[This was not + literally discussed at meeting, but to add an editorial + remark ... It seems hard enough to come out with 6 week + milestones. It is unclear if anyone actually needed + something as frequent as monthly or 6 week releases ... or + if it was more a "marketing" thing? If so, could there be + more/better/easier ways to "hype" milestones to get + equivalent interest? If the desire really is so + projects/adopters could release "whenever they were ready", + then I'll just point out there is a lot of hidden + assumptions being made in that case that in reality would + cause the same headaches the "release train" is meant to + solve -- primarily, it might appear to work fine the first + time through, if everyone goes in order, but then suddenly a + recent release, say of a commercial product, can not update + a few months later to get the latest of some pre-req, due to + some new feature/non-API use/deprecated API removal, subtle + change in behavior, etc, and then they end up having to wait + 4 to 12 months anyway to get the fixes needed so they can + "get on" that, now old, version of the pre-req ... and + perhaps by then that pre-req no longer works with some other + pre-req that has since released. So, point is, anyone who + really desires this needs to think through the hidden (long + term) assumptions and "solve" them.\] But, in general, "a + mass repository" that may or may not work together did not + seem to get much excitement from Planning Council, if I was + hearing correctly.* + + + + - + + - + ''A couple of items seemed to have very different points of + view: '' + - + *1) Is it a good thing to encourage "frequent feature/API + updates" or a bad thing? Examples were given on both sides. + On the one hand, it can be "hard on" adopters to react, if + there are large changes requiring adopters to do a lot of + re-testing/translating/marketing, etc. But, everyone sees + the advantages of it, especially for a "young" project like + EGit where they needed lots of quick improvements to be + complete, and useful.* + *2) An interesting, contrasting, case was made about "core + components" vs. "leaf components". To some, it seems clear + that something like the core platform should only apply + maintenance for SR1 and SR2 (to ensure only steady + improvements in quality) but on the other hand, there are + times that changes in the core platform is exactly what + other projects want, such as CDT, ... such as having a new + set of APIs added that allows them to come out with a better + (from their point of view) off-cycle release even though + "new API" can have unpredictable effects on other adopters. + Hard problem to solve. \[Just thinking aloud, perhaps some + special versioning conventions and tight p2 constraints + could allow relatively safe "forks" of something like core + platform APIs, without impacting adopters that were not + interested? In essence, CDT would release their own forked + version of the platform ... just thinking out loud ... not a + serious proposal.\]* + *3) Not to mention, sometimes even the core Platform may + want to add a new feature "off-cycle", such as if a new + version of Java comes out "mid-year", perhaps they'd want to + add "preliminary support" for it in SR2? Perhaps those types + of cases provides some hint of how to codify the practice of + adding features in a "service release" ... when ever + possible, they should be done as "optional", additional + features that adopters can take or leave. Not sure how to do + that with core API changes, though ... short lived fragments + that adopters can take or leave?* + + + + - + + - + So, lots to (continue to) discuss. Perhaps fundamentally, what + does "continuous delivery" mean for something consisting of + 60-70 projects? + + + + - + + - + *Dani did state that the Eclipse PMC discussed explicitly, and + they want to keep the status quo. Even the names "Service + Release". That while new features can be allowed in SR1 and SR2 + (as per our existing policy) that it is not something to + "encourage", in their view, ... they should be the exception + rather than the rule ... and the focus on SRs should be on + improving quality, not adding new features. (hard to do both, + with fixed resources ... or, more accurately, without vastly + increased resources :). New features should be "exposed" to + public in a number of milestones, before released. \[To + editorialize again, perhaps we need to do a better job of + encouraging use of milestones? I think some believe that a + "release" is the only thing consumers/users will use enough to + provide adequate feedback on a new feature.\]* + + + + - + + - + *Doug did state explicitly that his "focus on IDE" efforts (and + probable working group) were a whole separate issue and not in + the Planning Council realm. (whew)* + + + + - + + - + ''\[post-call\] Another comment I heard, on arch. council call, + was that some adopters have been surprised to hear that "we" + allow new features in SR releases at all -- while I think "we" + want that to continue to be allowed, we should probably do a + better job of documenting them, perhaps as a quasi-"exception + process" so that it is more obvious to the community of "sim. + rel. consumers" when it does happen ... and document better some + of the basic information: what they change or add, if they are + optional, etc. + + + + - 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 "project 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? + + + + - + + - + *Doug said he would try to work on some prototypes. But (if I + heard him over the spotting phone connection correctly) this + wouldn't be anything to prevent planning to use the b3 + aggregator approach as we have been and continue with that until + we know something more concrete, and then would be the time to + re-discuss). The approach (again, if I heard right) basically + makes use of a series of Jenkins (or Hudson) jobs, one + successful job triggering the next, and progressively "building + up" the repository. (I think is how he briefly described it). + \[Doug, please correct if I mis-heard any of this ... we didn't + spend much time on it.\]* + +## 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")\] + + + + - + *There were no "in-meeting" updates to any of these items, except + Dani said they should start the editing during M2.* + +## Kepler Retrospective + + - Propose to start in August (if any extra time), finish in September. + + + + - + ''No time for a retrospective, per se, we'll try again in September + ... please discuss with your projects or members you represent to + see if there is anything we should document about "what worked" and + "what didn't work". '' + +## Next Meeting + + - September 4, 2013 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Cross_Project_Teams/Accessibility(3).md b/wiki/Planning_Council/Cross_Project_Teams/Accessibility(3).md new file mode 100644 index 0000000..d8474e8 --- /dev/null +++ b/wiki/Planning_Council/Cross_Project_Teams/Accessibility(3).md @@ -0,0 +1,240 @@ +# Accessibility Team + +## Members + + - + Tammy Cornell, IBM + Kentarou Fukuda, ACTF Project + Neil Hauge, Oracle + Kaloyan Raev, SAP + Oliver Keim, SAP + +## Statement of Problem + +Currently, many Eclipse Members have a business need to make sure +software they consume from Eclipse meets certain Accessibility +requirements. Besides just being a nice thing to do, it is often +required to "prove" software is accessibility, in order to sell to +certain markets or bid on certain contracts. + +The "proof" often comes in the form of conducting certain tests and +checks and completing a checklist, for long term documentation of what +was done to ensure the software is accessible. + +Currently, many Eclipse members have their own process and checklists +for this accessibility work, but it would be simpler if there was one +"Eclipse Accessibility Checklist" which would set the expectation for +all Eclipse Projects ... at least all Eclipse Projects participating in +the yearly, simultaneous release. And, of course, this "required item" +for the yearly release can not be too burdensome for the Eclipse +projects. + +Our "required" item for Galileo simultaneous release was a 'should do' +item, and stated as simply as "... should design and test for +accessibility". So another way to state the problem, is whether or not +there is a stronger requirement that would lead to a stronger, more +demonstrable or measured statement about accessibility compliance. + +## Meetings and Notes + +Meeting 10/15 9:00am US EDT Attendees: Tammy, Neil, Kentarou & Kaloyan + + - reviewed the goal of this project + - discussed which Accessibility standards each company is following, + confirmed that all (involved in this meeting) are using the US + Section 508. + - Kentarou provided an overview of the incubator ACTF project: + + - The ACTF project needs to be enhanced more before it can be widely + adopted by Eclipse projects. Currently does not provide tooling for + SWT. It currently supports html, flash content, similar function as + inspect32... Helios timeframe is to short to build in the additional + function. + - For a short term solution we believe it would be valuable to update + the Accessibility guidance located at eclipse.org: + + This document was originally created by Tod Creasey in IBM, Tammy + will contact Tod to see about getting this webpage updated. + - Confirmed that each team is using the Software, Web & Documentation + checklists. Tammy will work on getting a copy of these checklists to + possibly include in the 'Should do'/guidelines section of the + release train/ emphasize/recommended . + + - Kaloyan is trying to locate an Accessibility rep to join him on the + team + - Will most likely break this up into two parts: short term/Helios: + update guidance documentation and provide stripped down checklists. + long term goal: provide tools (possibly ACTF) to automate + Accessibility checking during development. + - will meet again on 10/20 9:00am US EDT + +----- + +Meeting 10/20 9:00am US EDT Attendees: Tammy & Kentarou + + - Tammy confirmed that the following webpage will be updated by 11/30 + + - Need someone to review the accessibility checklists located here to + see if they can be trimmed down/reduced: + + - Tammy is verifying if the above checklists can be used on the + Eclipse website. + - Kentarou supplied an ACTF presentation that Tammy will distribute to + this team + - Kentarou will hold a meeting this week with some of the other + resources working on ACTF to see what they plan to accomplish in the + upcoming months. Kentarou mentioned that this project could use some + additional resources/active committers. + - May expand Accessibility guidelines webpage to contain basic testing + instructions and possibly a link to an open source screen reader + (NVDA) + - Will try to handle actions via email this week and schedule our next + meeting for 10/27. + +----- + +Meeting 10/27 9:00am US EDT Attendees: Tammy, Neil & Kentarou + + - the Accessibility checklists located here: + can not be + reproduced on the Eclipse website, if we use them we will need to + provide a link back to the IBM public website to reference them. + ACTION ITEM: The other accessibility cross project team members will + research and see if they can come up with something more generic + that can be stored on eclipse.org. + - will suggest an Accessibility Verification milestone be added to the + release train schedule (possibly around the API Freeze)so release + train projects will be reminded to do a first pass accessibility + check that is early enough so they have time to react to any + accessibility + +problems/issues. + + - Neil will draft a recommendation (proposal is due 11/4/09). Will + review recommendation in the next meeting on 10/29. + - Kentarou is meeting with the ACTF team tomorrow and will have an + update/outlook for us in the next meeting. + +Notes from Kentarou: Here are the URLs of other accessibility resources +on Eclipse. 1. Tips for making user interfaces accessible + +2. Accessibility features in Eclipse + +3. Accessibility check list example (Eclipse SDK 3.2, 3.3) + + +it might be a good reference for other projects to create their own +check list. Item 1 above and this article +(http://www.eclipse.org/articles/article.php?file=Article-Accessibility/index.html) +will be a good reference documentation (and starting point) for Eclipse +developers. We should break down the software accessibility check list +into work items suitable for Eclipse. However, it will be a middle/long +term work. + +----- + +Meeting 10/29 9:00am US EDT Attendees: Neil & Kentarou + + - Kentarou talked to ACTF team. Communicated that resources are + currently limited. The team's current focus is to provide an + inspection tool that can verify accessibility for platform UI + development (based on MSAA usage). + - The ACTF team would like to do more, but it's not clear whether they + will be able to provide the general automated testing tool for + Eclipse given current resource constraints. + - Kentarou recommended adding an open issue for the need to find more + resources for the ACTF project in the Eclipse community. Also + suggested removing dependency on the ACTF tooling from the long term + requirement, and add the presence of a checklist. Neil will make + these changes to the proposal. + - On the topic of the Accessibility Checklist + - We should be able to draft something like the IBM checklist, + creating it ourselves if necessary + - We can probably finalize the checklist after the recommendation + deadline since time is running out + - Kentarou and Neil will continue to look for accessibility + content for the checklist + +----- + +Meeting 11/3 9:00am US EST Attendees: Neil, Kentarou, Kaloyan & Tammy + + - Kentarou - we should also focus on web accessibility which will be + used with projects such as e4. Add WCAG to the guidelines. + - Kentarou - make sure the proposal explains that the platform focus + for now will be with Windows and that other platforms may need to be + considered in the future. + - Tammy - will add pointers to the generic checklists/guidelines + provided by the .gov sites. + - Kaloyan will have Oliver review the recommedation and also look into + a set of generic checklists that could possibly be used on the + Eclipse website. + - all agree that until this is automated more, that we will recommend + it be on the "should do" list. + - Tammy will make a couple of updates to recommendation and then send + it around to the cross-project team for final review. Will submit + proposal later this week. + +## Recommendation to Planning Council + +**Status**: Submitted 11/5 + +**Open Issues**: + + - Need testing to determine if we can recommend GNU licensed NVDA open + source screen reader. One current barrier for project testing is + having to buy a license for the predominant screen reader software. + Other short term options might include accessibility test tools such + as [AccChecker](http://www.codeplex.com/AccCheck) and [UIA + Verify](http://www.codeplex.com/UIAutomationVerify). + - The ACTF project is in need of more resources to pursue longer term + goals of automated accessibility testing for Eclipse. We need to + look for possible contributors in the Eclipse community. + +**Proposal**: + +Accessibility is a key requirement for many Eclipse adopters based on +business, legal, and ethical grounds. Accessibility is also an important +requirement for disabled end-users of Eclipse. Accessibility has +previously been on the "Should do" list with one line of information +describing the release train requirements. Building on this foundation +in the short-term (Helios), we propose: + +1. The requirement for accessibility remain in the "Should do" or "Good + citizen" category, with the thought of moving this to the "Required" + category in the future. + 1. Accessibility testing is not something that can be easily + automated using Eclipse tools (for now) and testing may require + purchase of screen reader software. +2. The main [accessibility + article](http://www.eclipse.org/articles/article.php?file=Article-Accessibility/index.html) + at Eclipse Corner should be made current (Todd Creasey has prepared + an update for this + page:) and + encourage all projects to follow the design guidelines contained + within. These guidelines will be expanded to include basic + verification instructions and links to open source Accessibility + tools that can be leveraged such as + NVDA:. + 1. This article is the basis for accessibility design at Eclipse. + Projects should use this article as a way to ensure + accessibility in their plugins. +3. Projects should document responses to a consolidated accessibility + checklist as a part of the release artifacts. Checklist reference + materials: + , + , . + 1. M6 should be listed as the recommended milestone for completing + initial accessibility testing to insure that there is time to + address any issues found. + 2. Initial platform focus should be Windows. + +In the long-term we propose: + +1. The ACTF project should be used to automate accessibility testing + for train projects within Eclipse. +2. The accessibility requirement should be moved to the "Required" list + or at least re-evaluated after Helios based on the status of open + source accessibility testing tools. + +[Planning_Council_Cross_Project_Teams](Category:Planning_Council_Cross_Project_Teams "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Cross_Project_Teams/Aggregation.md b/wiki/Planning_Council/Cross_Project_Teams/Aggregation.md new file mode 100644 index 0000000..9bfc16e --- /dev/null +++ b/wiki/Planning_Council/Cross_Project_Teams/Aggregation.md @@ -0,0 +1,70 @@ +## Members + +` John Arthorne (Platform)` +` Thomas Hallgren (Buckminster)` +` David Williams (WTP)` + +## Statement of Problem + +The current "Helios Builder", has many strong points, but some +weaknesses as well: + + - It is not truly reproducible. There are two sources of input, + specification (.build) files from cvs, and project's repositories. + We only have control over the CVS part, (it can be tagged, etc.) but + Projects can change their repo at any time (either on purpose, or + accidentally). This change in repo can cause the build to fail or it + might still succeed, but be a different set of bits than previous + runs. + + + + - The current build "builds" feature/product/and plugins (branding and + capabilities). Ideally, we would only aggregate, and not compile + anything. ~~~~ + + + + - The current builder/aggregator "fails" if anything is wrong. Even if + it is only a leaf node. At times, this requires tweaking the "build + model" to get the build operational again, while waiting for the + leaf node to correct itself. It would be better if the build tried + to "work" even if some components were in error, so that tests, + etc., (that don't depend on leaf node in repo) can get started. + + + + - When the build fails (due to conflicting dependencies, etc.) it is + hard to figure out the root of the problem, without a p2 trained + eye. + + + + - requires frequent "intervention" to add/remove projects in model + file (helios.build). + + + + - The +0, +1, +2 categories are an approximate categorization. + + + + - There is unspecified trade-offs between being "strict" vs. being + "lax". For example, in .build files, projects can specify version="" + and the highest version in the repo will be fetched or mirrored. + But, there's no guarantee that the repo has been updated yet, so in + some cases, it might appear to have "built", but is still using a + lower than expected version. + + + + - There are some steps in the process that require "hand editing" (or, + at least, running scripts that are not P2 API), for example + versioning categories, changing mirror URLs, and creating and + updating composite repository). + + + + - Should we migrate to improved aggregation tools (e.g. see [B3 + Aggregator](http://wiki.eclipse.org/Buckminster_Aggregator_User_Guide)). + And if so, how and when. \ No newline at end of file diff --git a/wiki/Planning_Council/Cross_Project_Teams/Tracking.md b/wiki/Planning_Council/Cross_Project_Teams/Tracking.md new file mode 100644 index 0000000..6564d29 --- /dev/null +++ b/wiki/Planning_Council/Cross_Project_Teams/Tracking.md @@ -0,0 +1,36 @@ +## Members + + - + David Williams (WTP) + ?Wayne? + ? + +## Statement of Problem + +Last year, we used bugzilla to track compliance, or not, with the +requirements of a Simultaneous Release. There was a couple of +limitations to that approach that makes us think we can do better. + + - The "summary" of bugs "fixed" or "won't fix" was cumbersome, took a + long time to run. + + + + - It seems "old fashioned" to capture tracking information in bugzilla + (why not make a custom web app, for something we do every year). + + + + - At best, you could note and summarize "yes/no" type responses. Much + of "the good stuff" in a simultaneous release process is buried, if + documented at all. For example, Projects can say, "yes we have a + documented build process", but why not include/require the URL to + that documentation. + +## A proposed Solution + +[Tracking Tool +Proposal](http://www.eclipse.org/helios/planning/trackingToolProposal.html) + +[Example Form +Input](http://www.eclipse.org/helios/planning/EclipseSimultaneousReleaseFormPrototype.html) \ No newline at end of file diff --git a/wiki/Planning_Council/Dec_03_2008.md b/wiki/Planning_Council/Dec_03_2008.md new file mode 100644 index 0000000..596bc4c --- /dev/null +++ b/wiki/Planning_Council/Dec_03_2008.md @@ -0,0 +1,126 @@ +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Dec 03, 2008](Dec_03,_2008 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2008&month=12&day=3&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Anthony Hunter + - David Williams + - Doug Gaff + - Brian Fitzpatrick + - Tom Watson + - Oliver Cole + - Pat Huff + - Bjorn Freeman-Benson + - Ed Merks + - Doug Schaefer + - Philippe Mulet + - Wenfeng Li + +### Regrets + + - Karsten Schmidt + - Markus Knauer (I'll try to be on the conference call, but I am not + sure if I can make it...) + +### MIA + + - Chris Aniszczyk (Technology PMC) + - John Graham + - Neil Hauge + - Mika Hoikkala + - Oisin Hurley + - Christian Kurzke + - Mike Milinkovich + - James Saliba + - Georg Schmidt + +## Topics + + - Galileo requirements... last chance to confirm or contest before M4 + - Unanimous confirmation that what we have is fine + - Bundles as jar requirement: applies to source jars as well? See + [bug 252800](https://bugs.eclipse.org/bugs/show_bug.cgi?id=252800#c3) + - Unanimous confirmation that source jars are also required, with + the same clause of documented deviations + - Capabilities, the next round of defining this requirement. See + [bug 252807](https://bugs.eclipse.org/bugs/show_bug.cgi?id=252807#c1) + - Agreed that minimal approach is all we require in Galileo, and + that project wishing to avoid creation of a new feature/bundle + can contribute to Galileo directly + - TPTP questions on requirements (see below) + - All issues resolved, with a suggestion to add the offer from + TPTP to aid with performance testing be added to the + corresponding requirement bug + - Provider names in the About dialog. See + [bug 198941](https://bugs.eclipse.org/bugs/show_bug.cgi?id=198941#c16) + - Agreed to promote this should-do to a must-do and include that + provider names be more descriptive, per the bug discussion. PMCs + to determine the best approach for their projects. + - Continue discussion of [SDK Composition](SDK_Composition "wikilink") + - Nothing further to add at this point. Philippe to look at the + page in detail to help address the platform issues identified. + +### Reminders + + - December 10-11, 2008 - plenary session with Board + +## Additional Topics + + - TBD + +### TPTP Questions + +There has been much discussion regarding the Must and Should do's for +Galileo. At today's TPTP PMC call, we went over each of the Must and +Shoulds with regard to TPTP and also with regard to the others on the +train. + +We weighed the effort for each against the expected benefits for each. +Overall, we thought the list was fine. We have the following comments: + + - New and Noteworthy - the bugzilla + +(https://bugs.eclipse.org/bugs/show_bug.cgi?id=252805) says that these +are done on each milestone. The Requirements page +(http://wiki.eclipse.org/Galileo_Simultaneous_Release\#Requirements_For_Participation) +says RC (Release Candidate). TPTP agrees with this for the Release +Candidate but it seems a bit much to have it as a must do for each and +every milestone. + + - Capabilities - TPTP will provide a single point of capability 'TPTP' + +in a plugin that will enable user to disable/enable TPTP UI +contributions (import/export, launch configurations, views, preferences, +and perspective). 254151 is already opened by Anne for such requirement. +Does this single point comply with the must do? + + - Also, we have a question regarding dependencies as TPTP has features + +that depend on other projects (e.g., Profile on server has a dependency +on WTP). Do we leave the choice to the user or do we act smart and +enable all the optional dependencies for the user? + + - Performance - Please add that TPTP is appropriate for profiling and + +performance work. As you know, we are putting resources into the +community profiler and this is exactly the kind of thing that we are +trying to encourage. We will do good support. + +## Action Items + + - Send out updated requirement to all, particularly for new About + dialog must-do (Rich) + - Devise an example of using Bugzilla to document N\&N using + attachments/comments (Rich) + - Document Galileo build repository location and notify general public + that M3 bits are available on + (Rich) + +**Carry over items** + + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/December_01_2010.md b/wiki/Planning_Council/December_01_2010.md new file mode 100644 index 0000000..9551f4a --- /dev/null +++ b/wiki/Planning_Council/December_01_2010.md @@ -0,0 +1,488 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, December 01, 2010, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=12&day=10&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Y

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - *Announced new members: Mik, Pascal, Adrian* + +## Maintenance Schedule + +### Helios SR2 + +2/25/2011 (Fourth Friday of February) + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Indigo Status + + - nearing M4. Is everyone in? Any known exceptions? + + + + - + + - + *Kaloyan mentioned OSGi Enterprise Tools project will likely be + one exception. Not ready by M4. And while still incubating for + Indigo, will (likely) be put forth, later, as an exception to + the M4 deadline.* + *After the meeting, Pascal mentioned to to me in email that m2e + might be delayed due to waiting for some CQs. He should know + more next week.* + +## Indigo Plan and Schedule + + - [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - Discuss "namespace" issues discussed in and elsewhere. + + + + - + + - + *Several issues came up: One, more concerned with EDP proposed + changes, rather than sim. rel., is that some projects do not use + the "org.eclipse" namespace through out ... ETF and AspectJ. + That is, there are known exceptions. The issue for Sim. Rel has + more to do with "overlapping" or "reusing" someone else's + namespace, especially in a common repository.* + + + + - + + - + *While it was acknowledged that "it has happened once", the + general feeling of the council was that it is so rare, that + rules and procedures did not need to be documented. That is was + indeed "common sense" that you can not use someone else's + namespace, and we do not need to document such common knowledge + or such rare exceptional cases.* + + + + - Discuss issue (from last year) ... to what extent should Sim. Rel. + materials (checklist) be part of official release docuware. + + + + - + + - + *It was felt we did not need the "persistence" of a PDF copy and + that a link would be nice, but no hard requirement. So, I added + this sentence:* + +> "This may be in the form of providing a URL to the checklist, ideally +> as part of the normal docuware." + + - + *following the original statement:* + +> "In addition to the ordinarily required Release Review Archival +> Materials, all Projects participating in yearly Release agree to +> provide a checklist-with-detail form that describes their compliance +> (or not) with all of the criteria items described in this document." + + - Suggestions during (previous) meeting: + + + + - + ''The req. doc was deemed ready, acceptable, with one exception: + + + + - + + - + The requirement wording on 'jarred bundles' needs to be improved + so no explicit exception required (it is required for any + requirement in that section) and to also make it more generic + and easier for a project to document why a bundle is not jarred. + Or, maybe even detail when it should be documented, and what is + an automatically acceptable?'' + + + + - Proposed new workings to replaces "jarred bundles" paragragh: + +Jarred Bundles. Projects must use jarred plug-ins (with +unpack=false) unless there are technical reasons not to do so. Also, +nested jars should be avoided if possible since it creates problems for +projects that has dependencies to such plug-ins. The OSGi runtime is +fine with it but the PDE environment is not able to handle classpaths +that contain nested jars. Exceptions to these principles should be +documented by the project, so we can learn the reasons and extent of +unjarred bundles. + + - + Discussed "once in always in". + + + + - + + - + ''No proposal to change, but given the discussion and + misunderstandings, some wording should be improved, maybe 'once + participating, always participating', or 'participation is + continuous', or something. Plus, should improve the wording of + 'Exception process' to better emphasize its purposes: a) improve + communication, b) improve PMCs shepherding their own projects + (not the planning council, or planning council chair), and c) be + sure decision point is not just one person (the planning council + chair) but is instead a group effort. '' + + + + - Proposed new wording to replace "once in always in" paragraph: + +Joining implies continuous participation. After a release, there +are two follow on activities that must be planned for. First is that +releases maintenance stream. The second is the subsequent year's +release. In both cases, it is (as always) up to the project to decide +what to fix or what to enhance, but being part of the train implies you +will always be able to build, in maintenance and in the subsequent +release's milestone builds. Sometimes this means simply leaving +repositories intact, etc., but occasionally projects may need to fix +"prereqs" or similar. Put another way, being part of the Simultaneous +Release is not a "one time" activity, covering only the literal release +date and not even a "part time" activity covering only part of the +yearly development cycle. Instead it is a commitment to stay +"simultaneous" on an on-going basis. + + - + + - + ''It was requested to beef up the "communication" aspect better, + that if a project is going to drop out, or suspend activities + for a long time, they should announce broadly since could effect + dependent projects. + + + + - Tracking "setup" required from Foundation in + + + + - See initial [Indigo Wiki page](indigo "wikilink") + + + + - + Review: There is a subtle implication of specifying Java 6 as + "minimum runtime" requirement. Currently, we require contributors to + use Java 5 when using pack200, since if not, and if involves a jar + that contains no Java (e.g. source or documentation) then it can not + be unpacked with Java 5, Java 6 would be required. This has been a + headache for people since for many it means tweaking build scripts + so an "old" (1.5) VM is used for that one step. During aggregation, + we purposely use Java 5 to catch errors in this regard. For Indigo, + I propose we not worry about being consistent here, and just use + Java 6 during aggregation. Some projects may still want to use 1.5 + VMs to do their pack200 ... if their adopters want it ... but I see + no reason for mass consistency here ... if Java 6 is assumed to be + minimum runtime VM. Any issues? Dissent? + + + + - + *Some concern expressed, but mostly a matter of letting people know + and documenting options. For example, for projects that **want** + compatibility with VMs less than 1.6, they still can, of course, but + will no longer get "built in" test from aggregation. Plus, should + make clear, even a VM less than 1.6 can still use a pack200 (or, an + unpack200 executable) from another VM, such as a 1.6 distribution, + and [specify it on their command + line](Pack200#Pack200_Executable_location "wikilink") using + `-Dorg.eclipse.update.jarprocessor.pack200`.* + +### Issues and Proposal for 3.7 versus 4.1 + + - See working notes in + + +## Other business + + - *TODO: the question of "3.7 or 4.1" came up again ... I should add a + FAQ item* + - ''TODO: I (dw) agreed to make initial +1, +2, ... table for project + signup. '' + + + + - + + - + Done. See + [Indigo/Participating_Projects](Indigo/Participating_Projects "wikilink") + + + + - Eclipse Platform 4.1 must move to be +1 because of dependency on + EMF. We should discuss how this will be coordinated because there + may eventually be cyclic dependencies (JohnA). + + + + - + ''John opened to see if part of emf could be +0. + + + + - Discussion on build machine QoS (JohnA): + - Is build machine contention/availability currently an issue for + projects? + - Do we need to adjust schedules to account for this? + - Consider other measures such as reducing continuous or regular + builds during milestone periods? + + + + - + *There was agreement this might become a problem (has been in the + past), but not sure if it currently is, and not sure what to do + about it if/when it becomes a problem. Its hard to pick favorite + projects or take away resources from some committers ... though is + is a shared, constrained resource, so might come to that. And by + "take away" it it meant to reduce, have various rules about niceness + level that are enforced, etc.* + + + + - + *TODO: I (dw) agreed to ask webmasters if there was some way to see + who was using what how much, as improved understanding might lead to + better solutions.* + + + + - + ''Long term, if it is only a matter of "peak usage", may want to + investigate (or, encourage others to investigate:) some sort of + "cloud" solution so during final milestone/release weeks we could + have 10 slaves, or something, whereas most of the time we just need + one or two. '' + + + + - ''Tom wondered if we need a "central" patch repository ... that + could be "built in" to all versions of Eclipse. It was suggested to + try to keep at project level, but agreed, some improvements might + make that better. For example, if in EPP packages, there was more + than one top level feature? Also, there maybe should be some other + attributes identifying patches, such as "security fix", or something + ... as some people may want to turn off checking for routine + updates, but turning off security fixes should probably be a + separate decision, as it is on many OS platforms. I was so excited, + I opened . Plus, later, I opened to improve the EPP package update + story, if possible. '' + +## ToDo Items + + - *Note from Wayne, to Wayne: (actually from last meeting) Remember to + review plans starting after M4 (at latest) so questions can be + clarified before "road map" produced.* + + + + - *Wayne teased us all with promise of new tools to check CQs against + downloads, which we projects can use ourselves ... but he wasn't + ready to tell us about them today and he'll be saying more over next + few days or weeks.* + + + + - *dw to sort out tracking path.* + +## Next Meeting + +November 3, 12 noon Eastern + +## Reference + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_02_2009.md b/wiki/Planning_Council/December_02_2009.md new file mode 100644 index 0000000..4344e84 --- /dev/null +++ b/wiki/Planning_Council/December_02_2009.md @@ -0,0 +1,288 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, December 02, 2009, at [1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=11&day=4&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

Y

?Doug Gaff?

Dsdp (PMC)

Anthony Hunter

Tools (PMC)

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)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

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)

Y

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

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 + +Any issues or news about SR2? + +*None raised.* + +## Helios + +### Criteria and Process + +Discuss/approve + +[main planning document](Helios_Simultaneous_Release "wikilink") + +Made current. Added SR dates (exactly one day early that Galileo's to +keep Monday to Friday patterns). + +*Notes: some suggestions made, such as to emphasize the repeating +pattern of dates (fourth Wednesday of June, forth Fridays of September +and February). Decided to pull 'participating projects' table into its +own page.* + +*Was approved, by the 'hearing no objection' method.* + +Discuss/approve + +[Eclipse Simultaneous Release +Requirements](http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php). + +Removed 'maturity' requirement. Tweaked capabilities requirement. Added +Accessibility requirement per advice of [Cross Project +Team](Cross_Project_Teams/Accessibility.md). +General cleanup. + +*Notes: Some general comments made, but unanimously approved by +roll-call vote. (As promised, Ed did follow up with email, and he even +approved\! :) Oisin and Cedric had to leave call early, before the vote, +but I will follow up on mailing list*. + +*One comment was that we might need some "summary" of the requirements, +such as a one page checklist. It is believed the eventual "reporting +app" will provide this sort of view, but if not we can write a summary +later.* + +*Another comment was that Helios itself should have a Retention Policy +explicitly stated. Tom will followup with proposed wording.* + +*Another comment was that there is no 'helios' field for projects to +mark in Portal. Request was made this morning, and Karl has updated, and +it should be on 12/3, after the next Portal update code rolls out.* + +### Proposed (initial) Cross-Project Teams + +#### Aggregation + + - + John Arthorne (Platform) + Thomas Hallgren (Buckminster) + +#### Accessibiity + +See +[Cross_Project_Teams/Accessibility](Planning_Council/Cross_Project_Teams/Accessibility.md) + +Their advice was incorporated into requirements document. + +Their work is done. Much thanks to Tammy, Kentarou, Neil, and Kaloyan. + +#### Capabilities + + + + - + Tim deBoer (IBM/WTP) + Oleg Besedin (Platform) + + Have decided not needed ... improvement is possible (with work) +but not enough interest. + +#### 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. + +## ToDo Items + +(volunteers welcome) + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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 + + - + [January 6, Wednesday](January_06_2010.md), + Noon Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_02_2015.md b/wiki/Planning_Council/December_02_2015.md new file mode 100644 index 0000000..b4022b5 --- /dev/null +++ b/wiki/Planning_Council/December_02_2015.md @@ -0,0 +1,483 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, December 2, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (occasional)

Cloud (PMC)

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Not official yet, but has been proposed to slip Java 9 about 6 + months, to March 2017. That will be near our Neon.3 release so may + have to adjust? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is review them before the meeting, but if questions + or issues with previous minutes, this would be a good time to bring + them up. + +## Mars Planning + + - Mars.2 issues? + - Remember Mars.2 RCs begin Jan 15 to Jan 22. + +## Neon Planning + + - See initial working draft of our plan at + [Neon/Simultaneous_Release_Plan](Neon/Simultaneous_Release_Plan "wikilink"). + + + + - \- Neon's Update Release Dates + + + + - + At our [previous + meeting](September_02_2015.md) it was + decided to have 3 update releases (instead of current 2), and have + them approximately equally spaced: + - + June (3) September (3) December (3) March \[(3) June\] + \* I propose we plan the availability of Update Releases to be + the same as the end of specific Neon+1 milestones. + \- That would be M2, M4, and M6. (See Neon's schedule, for a + rough idea of when Neon+1 milestones would be. + + + + - + + - + \- *There was a general agreement this seemed reasonable, but, + some wanted more detail, such as how "test time" would line up, + for the milestone vs. update releases. So that will be the next + step, for me to map our some detail, and show both milestones + and update releases on same schedule or calendar.* + + + + - + + - + \- The "two milestone pattern" (one-week-window period) + +| | +| | +| | +| | +| | +| | + + - + + - + \- The "two milestone pattern" (two-week-window period) + +| | +| | +| | +| | +| | +| | + +::\* Questions on patterns: + + - + + - + Do we still need the RC1 "warmup" to be two weeks "early"? I + think nearly all projects are so good at this, we no longer need + a "warmup" and could jump right into "real" RCs. + Do we still need the "two-week-window pattern? Or, is one week + always enough? Again, I think it speaks to the skill of the + projects that we may no longer need it. + + + + - + + - + \-*There was agreement on this proposed plan, as well as + agreement that we no longer need a 2 week RC1 warm up, and that + we no longer need a two week window for 3 milestones.* + \-*We were reminded -- and reminded to remind our projects\! -- + that one implication of the change is that the last service + release will be AFTER EclipseCon NA.* + + + + - + + - + \- This has one obvious advantage: for projects that are + essentially working on one stream only (such as fixes-only, + especially for first Update Release), they can submit same + content to the Update Release, and the Milestones stream. + + + + - + + - + \- ''Nick suggested: Would this be a good time to look at + changing the /staging/ and /maintenance/ URLs so they're + \*release-specific\*? + - + Will track with + + + + - + + - + \- Also, looking at the schedule, the December "match up" seems + a no brainer ... not much other time to do it? + \- M6 matching the last Update Release is nice since gives + "clear focus" for M7 and the end-game of Neon+1. + \- And Neon.1 matching M2 completes the rhythm. + \- From those "end dates" we would count backward, to establish + the same RC pattern we have now. + - + \- I've not looked closely, but believe the first "warmup" + RC, would be same or near the previous Neon+1 milestone. + (one quiet week, plus 3 one week RCs, plus 1 two week RC + equals 6 weeks) \[Is that good or bad? Do we still need that + early warm up RC? (I'm inclined to say yes, if for nothing + else, "new projects" joining the train, and for those adding + minor feature updates -- we still want a relatively early + warm-up for them, similar to an update release milestone). + +:\* Can we say now we all agree with these dates? (I suggest "official +vote" for next meeting, but if disagreement or concerns speak up now\!) + +:\* Has everyone had a chance to talk to their PMCs, Projects, or +Strategic Members they represent? (Please do, we need, and want, +complete buy-in from all stack holders -- that is, not so much what we +dictate, as it is what they want ... or, at least tolerate). + + - Off-cycle "hot fix" releases/patches. This is being tracked in . + + + + - + \- *We did not discuss this topic much, at this meeting.* + + + + - + One proposal: have all features in EPP packages be "root features" + and establish a procedure of adding new code to the Sim. Release + repository "at any time" -- for "hot fixes" only ... after + review/approval by Planning Council? + AND, change p2? to "not allow" addition of reference repositories + during feature installs. + - + + - + (Would likely have to be a "product preference" since some + adopters may depend on that feature, but EPP could "set" the + preference). + Easy for me to say "change p2" :) but ... who would do the + work? + + This "reference repositories issue" was a discussed as a concern + at Architecture Council + + - + Apparently there have been cases of users getting "mixed" + installs because reference repositories are sometimes very + broad. \[I hope I've captured that issue correctly, I was + not there, so please correct if I read it wrong.\] + Does Oomph solve this problem at all? Does it have a possible + solution? + + + + - Rolling "release" issue + + + + - + \- *We did not discuss this topic much, at this meeting.* + +:\* Upon re-reading, that was another topic discussed at Arch. Council. + +:\* Probably several ways to solve ... if it is a real issue? ... and, +if I understood what the "end goal" was better? + +### Neon new requirements + + - If a bundle is already signed by "Eclipse" it must not be re-signed. + + + + - Projects must provide b3aggrcon file change for every new + contribution. Either change exact feature versions if pointing to a + composite or change URL if pointing to a simple repository. (i.e. No + more "set it and forget it" practice of pointing to a composite, and + hoping the correct "latest version" gets picked). + + + + - others? + + + + - + + - + \-*No other requirements were named, and these two new ones were + thought reasonable, and agreement "we were ready (and capable) + of more rigor".* + \-*DW to update plan and requirement document, notify PC and + allow a few days for comments, and then notify cross-project + list.* + +## New Business + + - Any volunteers to drive the naming of "Neon + 1"? We normally start + this process in December or January. + + + + - + + - + \- *No volunteers, so far. But it was suggested I send Chris a + note (which I have done).* + + + + - TODO: It was mentioned at a previous meeting it would be nice if not + important to "rekindle" the face-face meetings at EclipseCon NA ... + or, some other form of more active Planning Council participation, + such "meeting your Planning Council Rep Hour"? (or BOF?) + + + + - + + - + \- *Wayne took the action of creating [a doodle + poll](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02542.html) + and coming up with 'topics' for a face-to-face meeting. Such as + "how can we be more "product like".* + +## Next Meeting + + - January 6, 2016 - Regular First Wednesday Meeting + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_03_2014.md b/wiki/Planning_Council/December_03_2014.md new file mode 100644 index 0000000..735297a --- /dev/null +++ b/wiki/Planning_Council/December_03_2014.md @@ -0,0 +1,349 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, December 3, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Thanks goes to Chris for staring the yearly "name that release" + process: + + + + - + + - + + \- Naming Mars+1 (2016 Eclipse Simultaneous Release) + + + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Luna SR2 + + - Any issues? + + + + - Should we change "signing certificate" as soon as possible? Or wait + until right after Luna ships? Please see . + + + + - + The issue is that there are cases, usually not related to the "IDE", + where Java checks that "split packages" were signed by "same + certificate", and it is unclear exactly what counts as "same + certificate". According to Denis, it is the "same certificate", just + "resigned and re-keyed". But, I would not be surprised if Java + doesn't count that as "different". + + + + - + + - + ''Ian reminded us that if certificate is changed, but nothing + else, then many projects will continue to use "old, previously + signed bundle", since the qualifier did not change, and normally + no harm in that (since they have TSA timestamp) but if the goal + is to "find all problematic cases" and "touch them" so their + qualifier changes, then Luna SR2 is not a good time to do that. + Too little time, resources, etc. and starting to get close to + "rampdown" for Luna SR2, and most desire to "keep changes to a + minimum, for maintenance stream ... so, would be better to + change after Luna SR2 so even if there are issues in Mars stream + (due to this same-qualifier principle) then they will likely be + found "naturally" over the last few months of Mars, instead of + needing any sort of last minute "fire drill". '' + + + + - A different signing issue: I suspect there is some risk that the + "signing of Mac executable" will not be working for SR2. Any + business impact? + + + + - + + \- Need to update "Mac signing service" + + \- Change location of eclipse.ini (for Max OS X signing) + +## Mars Planning + + - Please Review [the plan](Mars/Simultaneous_Release_Plan "wikilink") + and the [the + requirements](SimRel/Simultaneous_Release_Requirements "wikilink"). + + + + - + + - + Ready to consider these final? + *No issues, so considered final.* + + + + - Categories for Sim. Release Repo: Any comments/objections to adding + a category as described in ? + + + + - + + - + *A few voiced concern over the state of the categories as a + whole. And Wayne volunteered to "take a step back", look at them + holistically, think about the purpose and audience they are to + serve, and come up with a proposal -- by our January meeting.* + + + + - + + - + *I'll capture the work in progress here: [SimRel/Feature + Categories](SimRel/Feature_Categories "wikilink")* -- Wayne + +## Progress on Action Items + + - Prune "callisto-dev" group soon . nearly done. + - Improve "aggregator examples/doc". (dw -- no progress). + +## New Business + + - ? + +## Next Meeting + + - January 7, 2015 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_05_2012.md b/wiki/Planning_Council/December_05_2012.md new file mode 100644 index 0000000..34c5bf5 --- /dev/null +++ b/wiki/Planning_Council/December_05_2012.md @@ -0,0 +1,318 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, December 05, 2012, at 1200 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

R

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Achim Loerke

BREDEX (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Juno + + - SR2 to get active in January + +## Kepler + + - I have completely transcribed dates for Kepler (release and + maintenance releases) to the [Simultaneous Release Planning + Calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York). + Please proof read. + + + + - I have made a cleanup pass to the [Simultaneous Release + Requirements](SimRel/Simultaneous_Release_Requirements "wikilink"). + No new requirements, but made the following edits: + +:\* Removed "what's changed for Juno" section. (And so far, no changed +requirements for Kepler and ... the history is in the wiki). + +:\* Removed the 3.8 compatibility section. + +:\* Deleted requirements previously removed (but which were left in +document as "strikout"). + +:\* Deleted "\[date clarified\]" editor notes (since a little +distracting). + +:\* Changed Juno to Kepler where appropriate. + +:\* Changed Indigo to Juno where appropriate (such as help URLs). + +:\* Ran "linkchecker" and found a few broken links and updated as best I +could. + +:\* Improved grammar or wording in a dozen spots (usually to remove +words, honest). + +:\* Corrected spelling of one word. :) + +:\* Added "reasons" for why non-greedy-ness was important (and sent a +note to p2-dev list to sanity check in advance -- thanks Ian, Pascal, +for reviewing). + +:\* Based on Ian's comments, I added phrase pointing to the issue the +Java 7 and nested jars (). + + - Any other changes/edits? Can we formally approve this version, and + schedule, for Kepler? (It is, after all, almost M4\!) + + + + - + *Removed sentence about "Roadmap" since there is no longer such as + "roll up" of plans.* + *Removed mention of "CVS" and changed spelling of 'GIT' to 'Git'.* + *Agreement it was ready to be "formalized" (especially since little + changed from previous year).* + + + + - It is almost M4\! Everyone in? Anyone know of delayed projects? + Complications? + + + + - + *None noted. dw to send reminder to cross-project list.* + +## Other Business + + - ? + + + + - + *Wayne mentioned he thought new Portal would be ready in January.* + +## Next Meeting + + - No meeting January 2, 2012 (our regular "first Wednesday" meeting) + due to Holidays/vacations. + - Can we skip January? Or just defer it a week or two? If skipped, + next would be February 6 (which does get near Juno SR2). + + + + - + *Decided to plan for February (skip January), but that if anything + comes up, we can always schedule one later for second week or so of + January*. + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_07_2011.md b/wiki/Planning_Council/December_07_2011.md new file mode 100644 index 0000000..519523f --- /dev/null +++ b/wiki/Planning_Council/December_07_2011.md @@ -0,0 +1,322 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, December 07, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=12&day=07&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Mik Kersten

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo)

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

R

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

R

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Any? + +## Indigo SR2 + + - Anything? + +## Juno Plan and Requirements + +### M4 + + - Any issues? Everyone in? Any exceptions known? + +:\* *John reminded us that the platform is moving to "Jetty 8" for the +Help system in M4, which carries along other 3rd party prereq changes, +such as Javax.servlet. (Though, has been well discussed on +cross-project, and else where).* + +:\* *We wondered if recent Hudson change would effect our ability to +deliver M4 on time. (So, far, we think not, but need to monitor).* + + - Thanks to Wayne for handsome ["participating + projects"](http://eclipse.org/projects/releases/releases.php?release=juno) + page. + +:\* *Compliments and kudos given during the meeting ... "why didn't we +know about this nice history of releases before?\!" :)* + + - Yearly reminder to Wayne: allow some time in January to consolidate + plans for "Road-map" to make sure you have what you need for March + board meeting. + +### Requirements + +Review +[Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") for +substance and wording. See [last meeting notes from November 23, +2011](November_23_2011.md) for notes of +previous discussion. + +The things to focus on, for this meeting, are + + - the [proposed changes for Juno + Release](SimRel/Simultaneous_Release_Requirements#Changes_for_Juno_Release "wikilink") + + + + - in particular, the new requirement: [Documenting + compliance](SimRel/Simultaneous_Release_Requirements#Release_Review_and_compliance_to_requirements_documentation_.28approximately_RC3.29 "wikilink") + including the paragraph on "Tracking and Compliance" on our [Juno + Wiki page](:category:Juno "wikilink") + + + + - and, since last meeting was not well attended, we will confirm, + again, everyone supports the new requirement asking to [make it easy + to get released + source](SimRel/Simultaneous_Release_Requirements#Make_it_easy_to_get_released_source_from_repository "wikilink"). + +*Those attending thought plan was "ok" or "good". Sill some concern +about length (not so much number of items ... just that it takes a while +to read) but no concrete suggestions (and, it was mentioned, better than +it was). Hopefully can improve a little every year?* + +*I will send note to planning list, ask for any other comments by +Thursday 5 PM Eastern, from anyone who could not attend meeting. +Otherwise consider it "done" and send note to cross project list on +Friday. (We can make wording or clarification changes anytime, but do +not change any substance after M4).* + +#### Other clarifications? + + - Other comments/improvements to plan? + + + + - + *None* + +### Checklist (aka tracker) + +From [last +meeting](November_23_2011#Checklist_.28aka_tracker.29.md), +concluded there was not resources at Eclipse Foundation to support +information on Portal, but we'd add section asking for "statement" in +review documentation, as I've written up in the new requirement: +[Documenting +compliance](SimRel/Simultaneous_Release_Requirements#Release_Review_and_compliance_to_requirements_documentation_.28approximately_RC3.29 "wikilink"). +Need to "disconnect" portal dialogs, tracked in . + +From last meeting, *Longer term, not in time for Juno, fields such as +link to rampdown plan, link to accessibility testing, link to API +policy, retention policy, etc. will be part of the new "super portal" +for projects to fill in, or not, depending on type of release, needs of +the project, etc.* + +### Other business + + - Name that release: Juno+1. Need volunteer to drive community + discussion and vote. + +:\* Need to "launch" this effort first thing in January. + +:\* Goal is to have "completely done" by EclipseCon. We have missed this +last two years (at least) since we didn't allow enough time (at least 4 +weeks?) for Eclipse Foundation to do their legal vetting of the proposed +(and most popular) name. + + - + *Chris kindly volunteered to drive the process for the new name + (again). Thanks Chris\!* + + + + - Anything else? + +## Next Meeting + + - January 4, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + + + + - + *John mentioned Canada's schools (at least, Ottawa's?) are still + "out" so he won't be able to attend, but we will still plan on 4th, + unless we decide otherwise on planning list. (And, we can always + discuss issues on planning list, or have an "extra meeting" in + January, or anytime, if issues some up outside the monthly cycle.)* + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_07_2016.md b/wiki/Planning_Council/December_07_2016.md new file mode 100644 index 0000000..9391055 --- /dev/null +++ b/wiki/Planning_Council/December_07_2016.md @@ -0,0 +1,479 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Dec 07, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Adrian Mos

SOA (PMC)

D (Bob Brodt)

Fred Gurr

Eclipse Foundation (releng)

Y

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Alexander Nyssen

itemis AG (Strategic Developer)

Y

Nick Boldt

Red Hat (Strategic Developer)

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

EPP (appointed)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Brian Payton

Datatools (PMC)

X

Chuck Bridgham

WTP (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Remaining from previous action item: Need to establish new "Info + Center procedure" for Neon.2. () + + + + - + + - + *Fred reported he is working on a Hudson job to automate this, + and should be done by end-of-week".* + + + + - FYI from previous "New and Noteworthy" action item: + + + + - + \- Wayne added New and Noteworthy procedure to + + \- and I added short pointer to it in the "Final Daze" document + + +## Oxygen Planning + +### Java 9 Coordination \[Dani\] + + - Dani, anything to report? + - We (Platform Project) create a report that runs jdeps during our + build. We have to investigate how this can be pushed down to + Tyhco. + + + + - + + - + \[dw\] FYI, there is a Maven plugin that can be configured. See + [maven-jdeps-plugin](https://maven.apache.org/plugins/maven-jdeps-plugin/). + It does, apparently, offer only "pass/fail" (that is, no setting + to list violations as "warnings") so it may not be useful to + everyone. + + + + - - I expect to send out information for the projects on January. + +### Stop using Release Name? + + - Reminder to open bugs where "release name" is used by itself: See . + +### New levels of IP + + - + \- Do we, as Planning Council, want to stipulate a participating + project must be of "type B"? Or, do we not care? It may depend on + "how labeled"? How do users or companies know? What do they expect? + Comment in . + - + \- In a previous meeting are most recent conclusion was: + + + + - + + - + \- "Anyone can be in the Simultaneous Release repository + regardless of IP method chosen". :::- But, this was conditional + on users and adopters being able to easily know which method + applies -- in case it does matter to them. Suggestions were made + to provide meaningful names (other than "Type A and Type B") and + to provide the information in something like the about.html + file. We all agreed with Wayne that it should not be part of a + package name or bundle id, etc. Just something more "self + documenting" than the "release record" (Wayne's currently + planning on providing that). + + + + - + \- Wayne, any news on "names" or how "documented" for end-users and + adopters? + +*It appears the names "Type A" and "Type B" will stay. Wayne had some +ideas on how to describe them on any user facing pages, such as "License +Compatibility" for former and "License Compatibility, providence, and +code scans" for the latter. And, it appears the only way to tell will be +to look in the IP Log (and maybe Release Docs?). No one at the meeting +voiced any issue with that.* + +### Potential new requirements + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + From last meeting: + \- *After a brief discussion, it was decided this should not be a + **requirement** though we should encourage projects to test that + scenario and keep track of issues.* + \- *Doug surprised us all saying current "root features" do not work + as expected. That items can to be removed or added? Doug, please + clarify in what issues you are seeing.* + + + + - + \-- The issue was that they could not be removed. Appears to be no + deep concern. + + + + - I would like to suggest we "beef up" our current "update" policy: + + + + - + \- It is currently captured as an "optional" requirement. See + + - I propose moving it to "required", where the **required** part + is to simply document if the project supports updating from + previous yearly releases. And we should be explicit that + "supports updating ..." means: + + - + \- Testing it + \- Accepting bugs against it + \- Following best practices, such as migrating preferences that + changed ids, etc. \[Can anyone provide more detail here?\] + Naturally, a project may decide to document "No, not supported", but + then at least we (and users) would know. + + + + - + + - + *This item was agreed to put in the "requirements" document. I + will work on exact wording and "move up" the 'workspace + compatibility' item currently in optional. ACTION-ITEM: Wayne + will open a bug for him to update PMI for "release record" with + a check box that would have 'unspecified', 'no' 'yes' for a + response to "Is Update-able across yearly releases". + ACTION-ITEM: dw to open cross-project bug "for issues defining + what is means to be 'update-able'".* + + + + - Similarly, I propose we **require** that projects document if they + are "Java 9 ready". + + + + - + \- This would mean \[more detail welcome\]: + - + \- They have tested **running** on Java 9. + \- Will accept bugs that occur only when running on on Java 9. + \- They have tested with "jdepends" for "VM internal use" + methods. (And, ideally, removed such uses). + \- Anything else? + \- If a project provides Java "functionality" (such as + generating code, having special natures, etc.) that they either + have that functionality in Oxygen, or will have for the "Java 9 + update release" currently planned for July. + Again, projects can simply say "no", but then at least we (and + users) would know. + + + + - + + - + *This item was agreed NOT to put in requirement document. If + nothing else it is "too early" since Java 9 is not out yet. But + also, there were some concern how important it would be if Java + 9 is not truly "backward compatible" then many Eclipse projects + may never run well on it. But, the PC thought we, as Eclipse's + Leaders, should begin "socializing" the idea of getting ready + for it, and what project can/should do, such as Wayne said he + may blog about using "jdep" and dw said he may open a + cross-project bug about "Java 9 readiness". One thing mentioned + was that Eclipse would not run "out of the box" as it currently + is, but "out of the box" only the "bare-bones" module would "be + in the stack" (at least, as things currently stand).* + +### Release Policy vs. Release mechanics + + - For details, see . + + + + - + In Neon M6 we changed to have (nearly) all features to be "root + features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + Can we make an official policy on "off scheduled fixes" (as we are + considering for MPC)? + + + + - + + - + \- We have not discussed this topic for a long time. I think it + is important, but will remove from "ongoing issues" unless + someone at December meeting asks that it remain. + + + + - + + - + *No comments about importance, so will remove. But will leaving + a "closing" comment on the bug, to the effect that "It is hard + to make a general rule about it, especially since it is rule + that would only apply to projects as part of the Sim. Release. + Most of our other rules apply as a "good practice" for any + Eclipse project, even if not at the Eclipse Foundation. We agree + projects should not install reference repositories when their + features are installed but that was more a "project by project" + decision and what they judge their users want. Users and + adopters are welcome to open bugs against projects that abuse + its use, if desired, but nothing the Planning Council could + do."* + +## New Business + + - ? + +## Next Meeting + + - January 4, 2017 - Regular First Wednesday Meeting + +## Reference + + - + \- Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + \- [Neon Wiki page](Neon "wikilink") + \- [Oxygen Wiki page](Oxygen "wikilink") + \- [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + \- [Simultaneous Release + Roles](Simultaneous_Release_Roles "wikilink") and [Simultaneous + Release Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_11_2013.md b/wiki/Planning_Council/December_11_2013.md new file mode 100644 index 0000000..e5f9f69 --- /dev/null +++ b/wiki/Planning_Council/December_11_2013.md @@ -0,0 +1,379 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, December 4, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Have started the "Luna+1" naming process (See ). Thanks Chris, for + taking the initiative. + +## Kepler SR2 + + - ? + +## Luna Planning + + - Review Policy Wording + + + + - + After our last meeting, I realized we had never incorporated "Doug's + wording" about new features in SRs into the actual Policy FAQ + (though we discussed and agreed, though left open a month in case + strategic members needed to discuss internally). I have now + incorporated the wording in the FAQ. See + [SimRel/Simultaneous_Release_Policy_FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink"), + the note that starts "\[added April, 2013, modified November + 2013\]". + + + + - + Please review and approve to make sure I've correctly captured what + we discussed -- and then "we" will announce on cross-project list. + + + + - + + - + *Approved.* + + + + - Any new requirements? Any to remove or change? + +:\* Do we formally approve +[requirements](SimRel/Simultaneous_Release_Requirements "wikilink") for +Luna? + + - + + - + *Approved.* + +:\* If we ask people to specify exact feature (or repository) versions +in b3 aggregator files (see ) is that a new "requirement" or +implementation detail? For some, it would require "more work" and/or +better tools to generate the files more easily. (Maybe make a +requirement for next cycle?) + + - + + - + *No discussion. At best, we'll get some "recommendations" + documented and have on-going discussion about how best to + accomplish the objective.* + + + + - Anyone concerned about EPP's plans to require Java 7? + + + + - + See . Don't we usually encourage (but not require) projects to + support the same "Target Environments" as the [Eclipse Platform + Plan](http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_4.xml#target_environments)? + + + + - + + - + *There were concerns raised, and is the advise of the Planning + Council that "minimum required" set in eclipse.ini file be set + on a package-by-package basis, based on that package's needs, + instead of having same requirement for every package, even when + not needed. But, it is formally up to the EPP project and its + committers (and package maintainers) to decide, not the Planning + Council ... we are just giving advise.* + - + *- The main argument "for" doing all packages the same way + was that it's easier and more consistent message to end-user + to get message "at the beginning" of trying to run, rather + than something just "not working" (with at best a vague + information message in the log).* + *- The main argument "against" is that there are still some + users of "Java 6" so why limit them if not really required + and that its more in-line with our traditional approach (of + not constraining projects to particular levels of a JRE).* + *- Ian raised the use-case that p2 does not constrain + installation, based on BREE levels. For example, if someone + is using Java 6, and "starts off" with plain SDK (or any + product that is not constrained to Java 7), then they can + install features/bundles that require Java 7 (e.g. CDT) that + p2 will allow them to be installed, but the Java 7 pieces + still won't work, as long as user stays on Java 6 -- i.e. + user still won't get "friendly message". I'm not sure if + that is an argument "for or against" EPP's plans, but since + the "plain SDK" is not going to constrain execution to 1.7, + it seems inconsistent (and probably always has always been, + to some degree). Projects considering constraining their + BREEs to Java 7 may want to remember that use-case and + document it well for end-users and adopters that Java 7 is + required.* + +## Progress on Action Items + + - GSoC project for "Development Channel"? (Wayne) + + + + - + + - + '' While GSoC is over, for a year, Wayne will at least recall + history and open a bug for this.''. + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + - Complete Google Calendar. (dw) + - Compute Luna SR dates. (dw) + +## Next Meeting + + - No meeting in January? Or move to "second Wednesday" (January 8, + 2014) + + + + - + + - + '' decided to plan meeting on "second Wednesday", since M4 will + have passed, and SR2 starting up.'' + + + + - February 5, 2014 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/December_5_2018.md b/wiki/Planning_Council/December_5_2018.md new file mode 100644 index 0000000..c91dcaf --- /dev/null +++ b/wiki/Planning_Council/December_5_2018.md @@ -0,0 +1,206 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Dec 5, 2018, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Temporary Planning Council Chair: Nick Boldt Planning Council Chair: +Melanie Bats (returns Dec 2018) + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Fujitsu Limited + - IBM (Thomas Watson) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Payara Services Ltd. + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + - Tomitribe + +### PMC Representatives + + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - Eclipse EE4J PMC + - Eclipse IoT PMC + - LocationTech PMC + - Eclipse Modeling Project PMC (Ed Merks) + - Eclipse Mylyn PMC (Sam Davis) + - PolarSys PMC + - Eclipse Runtime Project (RT) PMC + - Eclipse Science PMC + - Eclipse SOA PMC (Adrian Mos) + - Eclipse Technology PMC (Chris Aniszczyk) + - Eclipse Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Chuck Bridgham) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +Write your name here if you attended and you enjoy collecting this type +of metadata. + + - Eclipse Project PMC (Dani Megert) + +## Agenda + + - Nick: + [Calendar](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&ctz=America/New_York) + updated with + [2019-03](https://wiki.eclipse.org/Category:SimRel-2019-03) and + [2019-06](https://wiki.eclipse.org/Category:SimRel-2019-06) dates + - Dani: Either approve in the meeting or set a deadline + - Dani, Nick, Alex, Wayne: approves + + + + - Wayne: Process items + - **AI**: Wayne: add item to calendar: validate participation list + (on March 8); repeat for 2019-06 schedule + - **AI**: Wayne document participation validation process + - **AI**: Wayne make sure that aggrcon file touching is a MUST DO + in + + - **AI**: Nick to talk to Wayne re: automating the validation + process via a new job/script hosted on simrel JIPP + - **AI**: Nick update wiki re: Jan meeting on 9th, not 2nd + (because NYE / holidays) + - **AI**: Wayne to remove offsets from project pages, but keep it + in the simrel release req + + + + - Fred: Simrel status + - RC1 is due Friday, RC2 next week. No problems at the moment, + release should be done before holidays. + + + + - Wayne: Birt and DTP demoted from top level projects to subprojects + of tools/tech. + - **AI**: Wayne to clean up PMC rep list + - **AI**: Wayne prune inactive members, contact members/orgs to + find new participants - + + +### Actions from last time + +Per: + + - **AI**: Fred to delegate to web team to push all & mark red w/ bug + details - maybe for M2? + - + **DONE** + + + + - **AI**: Dani to email Thabang (cc: Ed) about replacing "Simrel" with + "IDE" on download and marketing pages because "Simrel" makes his + eyes hurt (though it should be noted that instead of calling the + release a "train" he does refer to it as "the simrel") :P + - + **DONE** + + + + - **AI**: Alex to talk to Wayne about appointing Sopot + - + **DONE** Sopot has is now an appointed member of the Eclipse + Planning Council + + + + - **AI**: Wayne: add a new date to the simrel schedule for when an + announcement is send to cross-projects@, to report who we think is + participating. If URLs are found w/ /latest/ or snapshot, they + should be disabled? + - + **DONE** in principle. Wayne did send out the report and has + responded to feedback to update the list of participating + projects and versions. + + + + - **AI**: Wayne: send note to cross-projects@ to announce not opting + in + - + **DONE** in principle. Wayne derived and communicated the list + of participating projects; in that communication, he provided + instructions for opting out. + + + + - **AI**: Wayne: update "ASAP" re: "Create your release record (for + new releases)". Actual date is on/before Oct 19. + - + **DONE** Communication regarding participation includes a + reminder to create a release record. + + + + - **AI**: Wayne to produce documentation re: rules and send to + planning-council list + - + **NOT DONE** Wayne forgets the requirements, but we think this + might have been about participation validation / process + + + + - **AI**: Fred restrict pushing to simrel w/o gerrit review + - + **DONE** + +### New business + + - TBD + +## Regrets + +## Notes \ No newline at end of file diff --git a/wiki/Planning_Council/December_6_2017.md b/wiki/Planning_Council/December_6_2017.md new file mode 100644 index 0000000..186d10f --- /dev/null +++ b/wiki/Planning_Council/December_6_2017.md @@ -0,0 +1,153 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, December 6, 2017, at 1200 Noon Eastern

Dial in:

Topic: PC call - Dec 6 only Time: Dec 6, 2017 12:00 AM Eastern Time (US and Canada)

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/636198543?pwd=tWzAHHXJzXQ

+

   Password: 123456

+

Or iPhone one-tap :

+

   US: +14086380968,,636198543#  or +16468769923,,636198543#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 408 638 0968  or +1 646 876 9923  or +1 669 900 6833
+   Meeting ID: 636 198 543
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=nNBU6gfmKc0Nc84Dn4eAG6zY9BDa2x6C

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) - R + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Oxygen & Photon status (by Fred Gurr/Mikael Barbero) + - Future of the SimRel (by Mélanie Bats) + +## Notes + +### Oxygen & Photon status (by Fred Gurr) + +Everything is going nicely, there is no big issue. + +Oxygen.2: + + - this week = RC4 + - next week = quiet week + - release for Wednesday, December 20, 2017 + +Photon M4 is for Friday, December 15, 2017 + +Fred works on cleaning the SimRel Jenkins instance, some disk space, +improving wiki pages... + +### Future of the SimRel + +The planning council has decided to propose for the future of the SimRel +that : + + - A new release will occur every 12 weeks. + - All the work will be done only on one stream. + - And that only one repository will be used that will be continuously + updated. A stable "latest" URL will be used to allow the user to + update continuously. + - Specific URLs will be available to reference any release. + - The opt-in process will evolve, mostly projects would be assumed + "in" and someone will take care of cleaning the outdated projects + from time to time. + - It would be possible to add, update and remove API on any release. + +Before deletion an announcement of the intention would be done a long +time before (1 year or 2 year) in order that the depending projects have +time to upgrade to the new API. + + - As The release cycle will be shorter, we will have also shorter + period for breakage and shorter testing phase. A proposed planning + will be discussed on the mailing list + - A nightly SimRel build should be running. + +Remaining questions : + + - How do we organize the verification & tests in order to evolve from + a by hand homologation to a more automatic one ? + +How do we implement integration testing ? Do we automatically create +something which contains everything starting it and see how it is going +on ? who would be responsible for that ? + + - Do the EDP delays, release review and manual IP log would scale ? + +Theoretically release review should be done 2 weeks before the release. +But it is possible to continue to accept new contributions after that. +So changing the frequency should not change nothing for this point. + + - How do we name the releases ? What do we do about code names? \ No newline at end of file diff --git a/wiki/Planning_Council/Feb_04_2009.md b/wiki/Planning_Council/Feb_04_2009.md new file mode 100644 index 0000000..68178d7 --- /dev/null +++ b/wiki/Planning_Council/Feb_04_2009.md @@ -0,0 +1,65 @@ +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Feb 04, 2009](Feb_04,_2009 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=2&day=4&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Ed Merks + - Oliver Cole + - Doug Gaff + - David Williams + - Thomas Watson + - Oisin Hurley + - Cédric Brun + - ACTF Project: Kentarou Fukuda + - Sorry, I didn't catch the rest... please add yourself here + +### Regrets + + - Chris Aniszczyk (on a plane) + - Markus Knauer (on a train) + +### MIA + + - TBD + +## Topics + + - Antoine, Babel committer, would like the Planning Council to + consider the following + [proposal](https://bugs.eclipse.org/bugs/show_bug.cgi?id=261766) for + the Galileo release train projects. + - We all agreed that it's a good recommendation item, but not a + must-do or should-do item. David added a comment to the bug + above to this effect. + - What are the implications of increasing your runtime environment + version, TPTP asks? + - Mostly up to your clients, and within the project's + responsibility to decide. There are no formal requirements for + Galileo overall. + - Build update + - Minor + [snag](https://bugs.eclipse.org/bugs/show_bug.cgi?id=263568) + when updating to M5 + - Please notify when your M5 build model is updated so that they + can be added in a controlled manner to the build + +### Reminders + + - TBD + +## Additional Topics + + - TBD + +## Action Items + + - TBD + +**Carry over items** + + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/February_01_2012.md b/wiki/Planning_Council/February_01_2012.md new file mode 100644 index 0000000..fb394a0 --- /dev/null +++ b/wiki/Planning_Council/February_01_2012.md @@ -0,0 +1,390 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, February 01, 2012, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=02&day=01&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos (R.... ?)

SOA (PMC)

D

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Any? + +## Indigo SR2 + + - Any issues? + +## Juno + +### Issues or Exceptions + + - Any issues? Everyone in? Any exceptions known? + + + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo approved during 1/05 meeting (from rt PMC list, will be in + M6) + BPEL approved on mailing list (as late for M4, but in M5) + ~~... code recommenders (in by M5, but not in M4?) Did anyone + bring them forward for exception?~~ + - + Issue Resolved (good to know some people read agenda :) ... + but, is process unclear? ... Chris? :) + Code Recommenders approved on mailing list (as late for M4, but + in M5). + Others? + + + + - Anyone "dropping out" that should be removed from aggregation build? + + + + - + + - + I know there are potential, possible issues with Riena (not + being in common repo, as _might_ not "achieve 4.2". + Discussions on-going. + + + + - + + - + Anyone else? How to compare "participating projects" list with + "b3aggrcon" files? + +### Plans + + - anything to look at? In particular, plans specifying "planned + support for 3.8 workbench"? + +### Juno+1 Name + + - Kepler (EMO has vetted the name ... thanks Chris\!) + + + + - + + - + Guess I should announce? Or do you want to Chris? On committers + list? + - + *Chris agreed to send announcement note to 'committers + list*' + +### Other Business + + - Need discussion and decision on "what is allowed in common info + center". Pros? Cons? Alternatives? See . + + + + - + + - + Concern expressed for "extra work" on webmasters part but we can + leave to them to throttle that, but no objections to following + the "if you run on Indigo, you can be in Indigo Help" (that is, + not that confusing if then not in Indigo repo). It was also + suggested there might be easier ways to let projects "add their + own jars to info center" (reducing workload on webmasters, + allowing faster turn around, etc.) ... suggested to open + enhancement request in bugzilla if desired, as slightly separate + issue.'' + + + + - Thoughts on "Java Development Tools" category? See \[Immediate + issue has been resolved, but, not many comments ... so, feel free to + comment or open new bugs on "categories"\]. + + + + - + + - + *No particular comment ... might want to change the current + label of "Programming Languages" to "Programming Languages and + Tools" or something ... but, the idea of having one category for + all languages was thought good.* + + + + - Fair (and desired?) to add "provide non-greedy repository" to + requirements? 'Should' or 'must'? See + [Provide_optimized_p2_repository + section](SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29 "wikilink"). + I propose: + +*Clarification on 01/23/2012: the repositories produced and contributed +(for Juno and subsequent releases) must use p2 publishers that use +greedy='false' by default. See and the [p2 Publisher +wiki](http://wiki.eclipse.org/Equinox/p2/Publisher) for some history and +details on this issue of greedy vs. non-greedy requirements.* + + - + + - + *It was affirmed this is important and ok to add to "must do" + requirements. If, for some reason, a project can not, they can + always file for an exception and we can assess impact then.* + + + + - Project Priorities: Please review and be prepared to discuss this + proposed "policy document" about [project + priorities](SimRel/Priorities "wikilink"). + + + + - + *Good discussion* + - + *Somme concern about "E" \[now "F", after edits\] ... might be + some merit to it, but should be reworded to emphasize + "abnormally high" amount of CQs, not simply "number of".* + ''Suggested to mention LTS, as we do EPP. + *Some tangential discussion to get more detailed about ... such + as, are there ways still to simplify the process? Such as for + "minor" updates to a package. Will continue at next meeting.* + *Is was suggested a "flow chart" was needed (like the IP + process?) but a) I think that was made in jest, and b) think it + will be "next year" before we could formalize into a heuristic.* + *Will discus more at March meeting, before considering the + document "reviewed and approved" by Planning Council.* + *No overall objection to having PC state priorities, but some + concern that a lot depends on the context in which the + priorities were needed or used. Perhaps add a note these are + priorities for producing a timely, predictable release train for + adopters, products, and projects, and not that related to + "importance" of a project, which could depend on factors such as + innovation, demand, and others.* + + + + - Still comfortable with "4.2 as primary"? + + + + - + ''Overall, Mike Wilson's note to cross-project list was + "comforting", but still some concern that overall, to the general + user, it might seem like a step backwards, if they lose function or + performance (and, hence, hurt the reputation of Eclipse) ... that is + a strong **if** they lose function or performance (which is + currently not known, just feared). In particular, they might not + "see" any benefit to using 4.2 since much of the improvement is in + the internal architecture, for the future. \[One member, you can + guess who :), made an analogy to p2 ... had to push trough a rough + patch to end up with a much better solution ... and wondered if 4.2 + would be like that?\] It was suggested that "messaging" will be very + important, to set expectations appropriately. dw TODO: send note to + McQ with suggestion that he (and Eclipse PMC) and Ian work on + appropriate messaging. '' + + + + - Anything else? + + + + - + + Not known yet, but some solution is likely needed, and that might + require a "mass change" to not "packing" (and not signing?) nested + jars. + +## Next Meeting + + - March 7, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_01_2017.md b/wiki/Planning_Council/February_01_2017.md new file mode 100644 index 0000000..fe12958 --- /dev/null +++ b/wiki/Planning_Council/February_01_2017.md @@ -0,0 +1,142 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Feb 01, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + +### Eclipse Foundation + + - Wayne Beaton, interim chair Y + - Frederic Gurr Y + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (Marc Khouzam) Y + - IBM (Thomas Watson) Y + - itemis AG (Alexander Nyssen) Y + - OBEO (Melanie Bats) Y + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) Y + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) Y + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Doug Schaefer) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) Y + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Notes + +Melanie Bats joins us as the new representative for strategic member +OBEO. + +Dani's team is working on a tool (based on JDeps) to test for +dependencies on internal APIs that may break project code running on +Java 9. Dani will provide links. We need a means for projects to state +their support for Java 9. There are two (at least) concerns: does the +project code run on Java 9, and does the project code leverage Java 9 +features. + +The Eclipse Platform is almost done with their own process of ensuring +that they're not using internal APIs. + +We will need to have a release that coincides with the release of Java +9. This includes the repository, packages, and the installer. Expected +delivery date for Java 9 is July 27/2017 (we feel that the Java 9 team +will is about 80% likely to meet this date). This release will likely be +in addition to our planned Oxygen.1 release in September. There was some +discussion regarding who can and should participate in this release. The +extra release is generally intended for those projects that do something +related to Java 9; in the end, I think that we decided that all projects +that want to can participate in this special release. We need to get the +EF Marketing team engaged. + +We've acknowledged that vacations may be a problem with the timing of +this release and we'll have to proactively sort out schedules to give us +the best chances of success. + +Fred provided a brief update. His biggest concern is that lots of +feature/bundle versions have changed and there's been some merge +conflicts. Fred has asked that project teams push to Gerrit rather than +directly. + +As of this point-in-time, we haven't heard from the LDT project (Wayne +has since managed to get commitment from them to join and has engaged +the Tools PMC). + +OSGi R7 spec is releasing in September. We should get the EF Marketing +team to do some outreach. \ No newline at end of file diff --git a/wiki/Planning_Council/February_02_2011.md b/wiki/Planning_Council/February_02_2011.md new file mode 100644 index 0000000..5ced833 --- /dev/null +++ b/wiki/Planning_Council/February_02_2011.md @@ -0,0 +1,435 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, February 02, 2010, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=01&day=05&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

N

John Arthorne

Eclipse (PMC)

R

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Y ("finally" :)

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

N

Adrian Mos

SOA (PMC)

N

Ed Merks

Modeling (PMC)

N

Thomas Watson

Rt (PMC)

N

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

N

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

N

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

N

Christian Kurzke

Motorola (Strategic Developer)

N

Achim Loerke

BREDEX (Strategic Developer)

Y

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - A change to the Eclipse Software User Agreement is coming (). It is + recommended that you adopt the new PDE [license feature + support](http://relengofthenerds.blogspot.com/2011/01/implementing-shared-licenses-with-37m5.html) + so you can more easily adapt to license changes. You can simply + refer to the license feature defined by the Eclipse top-level + project, which will be updated whenever the SUA changes. You should + wait for to be resolved before switching. + +## Maintenance Schedule + +### Helios SR2 + +2/25/2011 (Fourth Friday of February) + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + + - RC2 is this week ... release is later this month ... any issues? + + + + - + '' No issues raised'' + +## Indigo Status + + - M5 this week ... any issues? + + + + - + *Pascal mentioned a new build of market-place client is needed for + M5 due to some p2 (internal) changes.* + + + + - any exceptions to discuss? + + + + - + *No exceptions were specifically approved at this meeting, but we + discussed some that will be requested for M6:* + - + *Libra. Provisioned. Building (just for day or two). Plans to + release as incubating subproject of WTP. Kaloyan to prepare + pages, information about project, and he (and WTP) will come + back with costs and benefits explanations when requesting the + exception.* + *WindowBuilder. Just provisioned. Still CQ work to do. (Wayne + was optimistic, but ... less certainty that it can get going in + time).* + *RAT: Not yet provisioned, nor had creation review. Wayne to + followup with them.* + + + + - (ongoing reminder) remember to aggregate project tracking, IP logs, + docuware, etc., and [update project + meta-data](Development_Resources/HOWTO/Project_Meta-Data "wikilink") + as Wayne requested in [cross-project + note](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05063.html). + +## Indigo Plan and Schedule + + - Should we provide (whole) Orbit Repository as a "runtime target" + category? Should it be a "trusted repo"? See + + + + + - + ''To summarize discussion: It was thought this was not a good time. + Maybe next release? There was no insurmountable problems known, but + many questions, that should be discussed widely, and over time, to + make sure we were not setting a precedent we couldn't support. Such + as, this is a "change in philosophy" for the common repo. Until now + it has been oriented towards end-user function, and just last year, + runtime targets (which is more for committers or extenders) but + still function/feature oriented. So, do we want to be/provide such a + general purpose 'common bundle repository'. Should we wait till + Orbit provides "one repo for all time" repository of bundles, or + change every release. Currently Orbit itself does not "release" in + the normal Eclipse sense, the bundles it provides do via being + included in other projects, but seems if we had a common repo, it + should have it's own "release review". (In fact, due to history and + evolution, there are bundles still produced by Orbit that are not + released in any specific yearly release, as an Eclipse Project does + not release with it included). Would this lead to Eclipse projects + not "including" a bundle in their distribution, and just relying on + the common repo for p2 to find it? And ... would this be a good or + bad thing? Currently, PC members had not seen many problems or + difficulties in this area, so some question about "what problem are + we solving" and while everyone could imagine it'd be a little + usability improvement, over users having to add the Orbit repo URL + themselves, didn't seem worth solving right now with so many + questions. In fact, even lead to one question of is a valid solution + would be just to provide the URL "pre-populated" with some of the + standard or common distributions, such as from EPP). While not + certain, it may be that Orbit can not be part of an operation where + a user says "install everything" ... that is, some known, + unavoidable conflicts. While there are certainly fixes or ways + around this ... it is work someone would have to do. So, did not + rule out the concept for all time ... but, more work needed. I'll + update the bugzilla with this summary. + + + + - recently [announced EMO dates for Indigo + release](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01860.html): + (I have added these to our [Planning + Calendar](https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&ctz=America/New_York&gsessionid=OK) + for convenience). + +`February 11, 2011 - Last day to enter CQs for Indigo projects` +`May 18, 2011 - Please submit your IP Logs` +`June 1, 2011 - Review documentation submitted to EMO for release review` +`June 1-8, 2011 - Review period.` + +## Other business + + - EclipseCon face-to-face meeting: Sunday, 3/20, 3-4? Alternatives? + + + + - + + - + *confirmed/agreed 3-4, 3/20* + + + + - Name that release. Indigo+1. Need volunteer to drive community + discussion and vote. + + + + - + + - + ''Pascal graciously volunteered to drive this year's "name that + release" effort/process. + +## ToDo Items + + - How is the RoadMap coming along? (Wayne) + + + + - + + - + *Progress, but slow. Wayne still working with individual + projects that have not provided one (and maybe didn't even know + they needed one ... so, sounds like some PMC/mentoring guidance + needed?).* + + + + - + + - + *Wayne would like to "extend" the meaning and use of some fields + in project meta-data so there projects could summarize their + release, etc., instead of sending email or making part of + docuware*. More could be automated then. Overall summaries + provided, etc. Wayne will (likely) send note to cross-project + soon with this request.'' + + + + - New [project release tools](http://www.eclipse.org/projects/tools/). + Some ready. Some near ready? (Wayne) + + + + - + + - + ''Sounds like Wayne's made some excellent tools to ease and + improve the quality of the process. He'll be posting more notes + soon (approximately Friday). '' + + + + - Please encourage your projects to add links to "central" Indigo wiki + for [New and Noteworthy](Indigo/New_and_Noteworthy "wikilink") and + [Migration Guides](Indigo/Migration_Guides "wikilink"). + + + + - + + - + TODO: Platform needs to have their own central page, like WTP + does ... or, update this wiki every milestone. It currently + points to M4 N\&N. + + + + - TODO (from previous meeting): dw to add/create add a FAQ item around + "what to handle 3.7 vs. 4.1". Will draw from previous [working + notes](Indigo/HowToAddress37And41Platform "wikilink"). + +## Next Meeting + + - [March 2, 12 noon + Eastern](March_02_2011.md) + + + + - EclipseCon Meetings: Sunday, March 20, At Hyatt, Exact location to + be announced + + + + - + + - + 3-4 (Pacific Time) PC face-to-face meeting + 4-5 (Pacific Time) Joint Councils Meeting (See [Donald's note to + list](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01858.html)). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](indigo "wikilink") + + + + - + [Helios_retrospective](Planning_Council/Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_03_2010.md b/wiki/Planning_Council/February_03_2010.md new file mode 100644 index 0000000..289410c --- /dev/null +++ b/wiki/Planning_Council/February_03_2010.md @@ -0,0 +1,363 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, February 03, 2010, at [1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=02&day=3&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

 

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)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

R

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 + +Any SR2 issues? + +## Helios + +### Exceptions for post-M4 + + - LinuxTools + - EEF + - EGit + - Riena + +### Exceptions for post-M5 + + - Sequoyah + - Jetty + - Heads up for Exception coming for Market Place Client () + +### Late M5 builds\!? + + - + And what are we going to do about them? + - + *It was agreed in meeting to advocate "warm up" builds beginning + at least the week (or two) before +0. This has the advantage + that others, less comfortable with .build files and P2 + repositories, can do their own warm up build (or, early testing) + before their deadline. This may, however, sometimes "break" the + build if higher level items have to adjust their prereq + versions, or similar. \[revisit in postmortem to explore better + ways than '+0, +1, +2\]* + + + + - Platform. John? + + + + - + + - + *Build was done on time, but tests take a long time to finish. + \[good case for warm up builds to start on Helios, without + necessarily final bits. Plus, good time for reminder that + "meeting deadline" means build is done, tests are done, all + votes in, builds promoted, and and ep.build file updated.*\] + + + + - EMF. Ed? + + + + - + + - + *Unexpected, or poorly communicated, loss of member who used to + do the builds. A replacement has been found, but will take some + time to ramp up*. + + + + - **In all cases of a missed deadline, it is essential to keep + everyone informed on cross-project list, or else others end up + thinking deadline was met, and may have to do extra debugging, + re-work, or re-builds, etc. thus compounding the problem that could + have been avoided with just a little better communication.** + +### Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +Status: me, john, and thomas meeting on Friday + +#### Structure of Common Discovery Site + +*Due to lack of interest or volunteers, it was decided to drop this +item, and what we have must be good enough.* + + - + users vs. extenders (minimum runtimes vs. SDKs) + runtime targets vs. tools + hierarchical categories (are more levels required?) + +Anyone care? Any volunteers? (If not ... and you leave it up to me ... +you know what's going to happen, right?) + +#### Tracking progress and compliance + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + - + me, gabe, and wayne have meetings once a week to check on + progress. Sample: ![Image:Screenshot-1.png](Screenshot-1.png + "Image:Screenshot-1.png") + + + + - + + - + Interim Plan: provide "check list style" version of + requirements, similar to [original sample + prototype](http://www.eclipse.org/helios/planning/EclipseSimultaneousReleaseFormPrototype.html) + + + + - + + - + Backup Plan? + - + xml files? (that can be transformed to pretty web page + reports + + + + - + + - + ''Wayne did not have any additional information, but said he + would check with Gabe. It is "high priority", but still under + "EclipseCon work". '' + + + + - + + - + *Backup Plan C: revert to bugzilla* + +## Other business + + - Propose face-face EclipseCon meeting 2:00 (local time) on the Sunday + before EclispeCon (3/21)? + + + + - + + - + ''Confirmed (there was no clear alternative, so "like last year" + seems best course). '' + +## ToDo Items + +(volunteers welcome) + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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). + + + + - add automatic tests (e.g. non-api scans, layouts, presence of BREE, + versioning, signed, etc.) + +## Next Meeting + + - + [March 3, Wednesday](March_03_2010.md), + Noon Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_03_2016.md b/wiki/Planning_Council/February_03_2016.md new file mode 100644 index 0000000..0122ef0 --- /dev/null +++ b/wiki/Planning_Council/February_03_2016.md @@ -0,0 +1,452 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 3, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Alexander Nyssen

Itemis

Y

Nick Boldt

Redhat (Strategic Developer)

Y (plus Michael to "listen in")

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

(was John Arthorne)

Cloud (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Alexander Nyssen as new Planning Council member representing + Itemis. + + + + - Any others? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Mars Planning + + - Mars.2 issues? + - Tracking participation in minor releases + +## Neon Planning (and beyond) + + - Should we change "maintenance" staging name now? for Mars.2? See . + + + + - + \- \[See also for unreleated additional URL.\] + + + + - + + - + \- Still "todo" item. (i.e. not done yet, apologies for delay) + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + One proposal: have all features in EPP packages be "root features" + and establish a procedure of adding new code to the Sim. Release + repository "at any time" (or, say, once per month?) -- say for "hot + fixes" only ... say after review/approval by Planning Council? + AND, to avoid "contamination" of update site lists (without the user + being in charge of it) change p2 install/update to not allow the + addition of reference repositories during feature installs. But, it + has been stated, adopters still want that ability ... so, not sure + how "we" could ever know the difference. + - + Perhaps could solve with a "product preference" so EPP could + "set" the preference one way, and adopters creating products + could set it another way? Or, direct users to do so? + - + Easy for me to say "change p2" :) but ... who would do the + work? + Perhaps solve simply with a "policy" of "do not add reference + repositories" (with feature installs)? + - + But without some way to enforce it, I think some projects + still would. + This "reference repositories issue" was a discussed as a concern + at Architecture Council + - + Apparently there have been cases of users getting "mixed" + installs because reference repositories are sometimes very + broad. \[I hope I've captured the issue correctly, I was not + there, so please correct if I read it wrong.\] + Does Oomph solve this problem at all? Does it have a possible + solution? + - + From [Ed's note to ide-dev + list](https://dev.eclipse.org/mhonarc/lists/ide-dev/msg01043.html), + it sounds like it solves the issue of updating non-root features + (as long as they are "in the repository"?). + + + + - + *We had a constructive discussion about this issue, even if not + complete agreement. We, at least, have some items to investigate.* + - + \- *Markus will propose to EPP packages that they (or, he) begin + building EPP packages with their "main features" in EPP products + as "root features". Thus, if we updated the Sim. Release repo, + users would get a "fix" via "check for update". Note: I believe + projects would have to come out with a new "release" of the + features -- that is "patch features" would not automatically be + found -- I THINK. Another implication is that "check for + updates" would take longer, I believe, since more features to + "fetch" to see if they have changed.* + \- *With the above root features in place, it would be easier to + do an off-schedule re-build of the Sim. Release repository -- + with just the "changed features" being used as input. We would + not rebuild the packages, just the repository. This should + minimize the amount of work required from other projects.* + \- *The issue for which there was still disagreement is how to + manage these off-schedule changes. I think there are basically + three proposals, and we agreed that by next meeting we would + list "pros and cons" of each:* + - + \* *A. Status quo: even if not a recommended practice, + projects can add "reference repositories" when their feature + is installed, so their users can get easy updates when ever + and what ever the project desires. No Planning Council + involvement.* + \* *B. Provide a "built-in" URL, disabled by default, that + would point to a composite repo named something like + "hotfixes" or simply "fixes" or perhaps even "extras" -- + depending on the policy that was adopted. The argument being + that then at least "what projects do there" is a little more + visible. Minimal Planning Council involvement.* + \* *C. Provide a process, and make it easier, for projects + to contribute off-schedule "service" and re-spin the Sim. + Release repository. This would likely be a special + repository, where only the "changed bits" would be included, + and the rest point to the previous, unchanged repository (a + "trusted repository" in b3 aggregator terminology). The + Planning Council would briefly review these "requests for + off-schedule builds" primarily to make sure they were + "blocking" or "critical" bugs, and perhaps to briefly assess + if there was any chance of impacting other projects. i.e. a + change in a "leaf" project or a "leaf" function would be + pretty easy to "approve", but if someone wanted to make a + big change to the way "jobs" worked, then it would take more + review and/or testing (if allowed at all).* + + + + - Rolling "release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + What testing would projects have to do? + May become "defacto requirement" once is implemented. + + + + - + *Seemed to be no objection to "trying it" and with Neon we will "try + it" by having the "streamless-URL" proposed in . For Neon, we will + not use that URL automatically anywhere but users can add it if they + would like. Will be interesting to see if many bug reports occur + from people trying that "update to next main release" (that is, from + Mars to Neon).* + +## Neon + 1 Planning + + - How's "naming" coming? + - Poll: -\> + + - Current winner (with 242 total votes) and 8 days left: Oxygen + - Per Oxygen was approved as the name for the 2017 Simultaneous + Release. + +## EclipseCon Face-to-face + + - Joint meeting with Arch. Council. + - Participate on + [EclipseCon2016/Councils_Face-to-Face](EclipseCon2016/Councils_Face-to-Face "wikilink"). + - ~~Suggest times on [doodle + poll](http://doodle.com/poll/7xphrzbeis678d5n).~~ Thursday, March 10 + +## New Business + + - Nick suggested moving b3 editor to Gerrit to facilitate + contributions and evolution of b3 + + + + - + David vetoed that change as being "not worth it (at this point in + time)" according to him. + + + + - Great Fixes for Neon + + + + - + *Wayne outlined his proposal for "great fixes" for Neon. It is + desired the winners (3 or so per milestone) be announced + concurrently with M6 and M7. He believes he can automate, via Git, + the task of finding non-committers who have made a lot of + contributions to one or more projects at Eclipse, for Neon. He would + like to identify about 10 candidates, and then have Architecture and + Planning Council members vote on who had the "most impact". There + was no disagreement with this approach, and the PC members thought + they would have time to participate. Details remain to be worked + out.* + +## Next Meeting + + - March 2, 2016 - Regular First Wednesday Meeting (The week before + EclipseCon\!) + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_04_2015.md b/wiki/Planning_Council/February_04_2015.md new file mode 100644 index 0000000..3f71bef --- /dev/null +++ b/wiki/Planning_Council/February_04_2015.md @@ -0,0 +1,333 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 4, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

D

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - \- Naming Mars+1 (2016 Eclipse Simultaneous Release) + + - 'Neptune' and 'Nova' are dead in the water due to trademarks; + 'Neo' is being considered now + - Neo will most likely pass trademark review; if not, we may need + to do a new poll + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Luna SR2 + + - Any issues? + - SR2 drawing to a close. + - Reminders left from previous meetings: + +:\* Reminder: "signing certificate" will be changed (renewed) right +after SR2. () (Not expected to have any effect on "Simultaneous +Release", but might on some in eco-system, or perhaps some "testing +systems"). + +:\* Reminder: There is high risk that the "signing of Mac executable" +will not be working for SR2. Perhaps not Mars? Any business impact? + + - + + - + + \- Need to update "Mac signing service" + + \- Change location of eclipse.ini (for Max OS X signing) + +## Mars Planning + + - Any issues? + - Remember that "M5" is the "EclipseCon milestone". + - Remember that Feb 13, 2015 is the CQ Submission deadline for Mars. + - Improving categories in Simultaneous Release repo? See + [SimRel/Feature Categories](SimRel/Feature_Categories "wikilink") -- + Wayne? Have a proposal yet? + + + + - + Wayne could not make last months meeting, but posted [status and + questions](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02331.html) + on mailing list. Was not much response? + *Not much progress, but still committed to improvements for Mars.* + + + + - Any objections to "using Gerrit" with Sim. Release aggregation + files? + + + + - + + \- Contribute to simrel with Gerrit + + - + "Everyone" would have to change the URL they access the repo + with, to the "remote access URL". (According to Denis, in a + comment in the bug.) + "Human Review" won't be required, but, I am guessing, would be + easy to add a "validate" check -- those are the ones that "break + the build" when someone adds a feature or category or contact + (and does not bother using the b3 aggregator to make the change, + or to validate the change). + + *No comments at meeting. I did clarify it would be "after SR2".* + +## Progress on Action Items + + - Prune "callisto-dev" group soon . (done) + - Improve "aggregator examples/doc". (dw -- in progress). + +## New Business + + - EclipseCon "meet-up"? + + + + - + + - + No meetings planned (not Planning Council, nor "Joint Meeting") + ... likely a "breakfast"? + *Wayne will send out note (before EclipseCon) ... he did some + "research" and appears likely to be Tuesday morning, at + restaurant "across from" Conference Hotel.* + + + + - *Wayne briefly mentioned "Great Fixes" program that is being + developed/proposed ... he is still working with projects to get firm + commitments from committers to review patches submitted for the + contest. And will announce after that.* + +## Next Meeting + + - March 4, 2015 - Regular First Wednesday Meeting. (The week before + EclipseCon.) + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_05_2014.md b/wiki/Planning_Council/February_05_2014.md new file mode 100644 index 0000000..3f02251 --- /dev/null +++ b/wiki/Planning_Council/February_05_2014.md @@ -0,0 +1,362 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 5, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

D Linda Chan

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

R

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Wayne announced Foundation's [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + +## Kepler SR2 + + - Any issues? Releasing [this + month\!](Kepler/Simultaneous_Release_Plan#SR2 "wikilink"). + + + + - + *Nothing mentioned.* + + + + - Any new (minor) releases other than CDT, Linux Tools, and EGit? + + + + - + *Nothing mentioned.* + +## Luna Planning + + - Can we consider [Luna/Simultaneous_Release_Plan\#Service_Releases + Luna SR1 and SR2 + dates](Luna/Simultaneous_Release_Plan#Service_Releases_Luna_SR1_and_SR2_dates "wikilink") + "final"? I used exact same pattern as previous years. + + + + - + + - + *Agreed.* + + + + - Why are not more projects using "Eclipse Source References" (See + and ). Only about 20% of bundles have it. + + + + - + + - + *No one really knew, so just reminded council members to remind + their projects.* + + + + - Have any Windows users tried setting git core.autocrlf=true? + + + + - + + - + *There was some disagreement, but sounded like they meant "in + general" and had not really worked with aggregator editor. I + asked those concerned to read and comment in the bug.* + + + + - When should we start to "fail builds" if bundles unsigned? Missing + about.html files? Missing EUA files? + + + + - + + - + *Just talked briefly, but generally thought it was a good idea, + especially for those things "really required" (such as, start + with 'about.html' files) since if we wait until the end, it's a + little hard to not allow someone to release, due to a few cases + of missing about.html files. Better for all to know early. No + immediate plans to change (since requires some work) but will + structure HIPP build with this in mind.* + +## Progress on Action Items + + - Any word on Luna+1 name? No to Magellan ... any word on Mercury? or, + do we need new vote? + + + + - + *Probably won't need new vote ... though waiting on others for + official word.* + + + + - GSoC project for "Development Channel"? (Wayne) + + + + - + + - + '' While GSoC is over, for a year, Wayne will at least recall + history and open a bug for this.''. + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + - Complete Google Calendar. (dw - done) + - Compute Luna SR dates. (dw - done) + +## New Business + + - *Status of EclipseLink in Sim. Release was briefly discussed, and + Wayne was (pretty) sure he had gotten a note that they are not going + to be in Luna, intentionally. It was wondered if Dali knew this, and + while I explained "how they work", I also agreed to send Neil a note + to confirm he was aware. (which has been done)* + +## Next Meeting + + - March 5, 2014 - Regular First Wednesday Meeting + - And then EclipseCon "face-to-face" ... ? + + + + - + *Ian Bull volunteered to lead this meeting, since I won't be able to + attend in person ... note sent to Anne, CC'd Ian.* + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_06_2013.md b/wiki/Planning_Council/February_06_2013.md new file mode 100644 index 0000000..437305e --- /dev/null +++ b/wiki/Planning_Council/February_06_2013.md @@ -0,0 +1,319 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 06, 2013, at 1200 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

R

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

R

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Kepler ["legal" + deadlines](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08603.html) + announced: + + + + - + Feb 8/2013 - CQ deadline for Kepler; CQs for participating projects + received by this date will be placed in the IP team's priority + queue. + May 24/2013 - Deadline to submit IP Logs for Kepler releases + June 12/2013 - Kepler Uber Release review + June 26/2013 - Kepler release + +## Juno + + - SR2 coming up. + +:\* Issues? + + - + EGit planning 2.3, but 2.1 is still their common repo contribution? + (That is, why aren't they "fully participating"?) See . Kepler + contribution is even further behind. + + + + - + **Action Item:** Chris will "get back to us" on what EGit's plans + are ... he initially thought "final code" would be done in two + weeks, but I reminded him RC4/final builds are next Wednesday. + +## Kepler + + - It is almost M5\! Everyone in? + + + + - + + - + Exceptions to M4 deadline: XWT, m2e-wtp (Kepler M6) + **Action Items:** Chris, and Wayne, respectively, will send out + more detailed proposal/justification for these to "come in late" + during M6. There were questions on if they would be "Incubating" + or not (currently are, but might be ready for a "graduation + review"). + + + + - Approved exceptions: + + + + - + + - + Stardust for M5 approved on mailing list. + +## Other Business + + - Any discussion of Kepler +1 name: Luna. + + + + - + See [vote + results](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02094.html). + + + + - Thank you Chris for driving this naming process\! + - ''Wayne briefed us on status of "PMI" (?Project Management + Information?) and said he's about to blog and "send instructions" + for new system, but soon, metadata will be accessed for editing, by + committers, from their own project page. '' + + + + - + *He had question/proposal about projects "adding themselves to + release train" ... first, technically, only he could do it now + ("tracker" removed from Portal), but he was thinking it'd be good to + change the process a little where each project would had to request + it (say, on cross project list?), and then be added by him, or + Planning Council member. This improves communication, but also + prevent "accidental" abuse of projects just adding themselves at any + time ... such as under old system, someone could add their project + during RC3 if they misunderstood the process (or, even, a previous + release\!).* + +## Next Meeting + + - March 6, 2013 + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_22_2013.md b/wiki/Planning_Council/February_22_2013.md new file mode 100644 index 0000000..31281fc --- /dev/null +++ b/wiki/Planning_Council/February_22_2013.md @@ -0,0 +1,413 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 22, 2013, at 1300 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

R

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

D (Mike)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Juno SR2 + + - SR2 Recovery Plan + +(I've left in the "issues bullet" from last meeting ... to highlight +some of the history here). + +### Background + + - + + - + + , , and maybe ? + + [Egit message + list](http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html) + + Numerous posts to cross-project list + +### Alternatives + +Please come prepared to discuss alternatives + + - + Does anyone know of any impact of delays to strategic members that + might effect choices? + Impact to the projects you represent on ability to do the re-work if + needed? + +#### Do nothing + + - + let EGit provide updated project repo with fix + - + Pro: easy + Con: EPP users especially get the bad bug right away ?and could + damage data? before applying the fix + +#### Simply remove EGit 2.3 from common repo + + - + thus effectively reverting to their 2.1 in SR1, re-spining EPP + packages, allow to re-mirror, etc. + - + Pro: moderately easy -- assuming I could do the p2.remove script + to remove just their bits (not a certainty) + Con: EGit starts off pretty far behind + +#### Full respin cycle + + - + Turn on the aggregator, let people update their contributions so it + runs, hope we get same content, respin EPP, re-test, etc. + - + Pro: best quality + Con: would take 2 weeks (IMHO), sounds like several projects + would want to contribute new bits, lots of work for all + participants + - + Other bugs mentioned as desired in a respin, if we did one. + Please comment in these bugs if you have + questions/suggestions for them. + GEF (No "perfect fix", even if we did a respin, due to + version number snafu even in SR1) + M2E (They will effectively be providing an SR2a, it sounds + like, even if we don't respin) + +#### Provide a 4th "composite" to Juno SR2 + + - + Would have only EGit in it. Assuming all was versioned correctly, + EPP packages and "end-user updates" would find their latest ones + - + Pro: moderately easy, with minimal work from other projects. + Con: The "bad bits" would still be in repo and theoretically + installable, if someone happened to deliberately pick an older + version + +#### Do a "branched respin" + + - + In the past, we did a respin once to remove some invalid, + non-approved third party code (so, "bad bits" *could not* stay, even + if "not most recent"). + In short, means creating a branch of b3 contribution files, me + changing everyone's URL to point to the current, specific SR2 site, + except for those that are allowed to contribute to a respin (which + would end up pointing to what ever they say is corrected). + - + Pro: more assured of getting same bits as before, yet having a + "clean" SR2 repo (instead of "bad bits" intermingled). + Con: maybe more work for me (will have to study scripts to find + where "branch" is specified). Still need to respin EPP, due + minimal test or "compare" to make sure only what was intended to + change did in fact change. + We would still need to decide "who gets to participate". + - + I'm most concerned about GEF's versioning problem, since no + way to fix that after released ... no way to "go down" in + version numbering ... adopters can "work around" if they + have a full fledge, new "product", but not if just providing + new features/plugins or updating an existing product. + +#### Summary + + - The most agreed-to item was should not ship as-is. + - Second most agreed-to item was a full respin was too risky and too + much time delay. + - The M2E and GEF bugs are bad (especially the GEF version snafu) but + felt they were not stop ship bugs, and respin for them not required. + Though it was recommend GEF move to "3.10" for Kepler, since various + Juno distributions will end up with a mix of 3.8 and 3.9. + - GEF's issue was related to having multiple releases in the same + repo, but specifying only "minimum requirement" in aggregation + files. Everyone likely needs a refresher on importance (and syntax) + of making contributions very specific ... and testing early. Just + because your component is correct, doesn't mean repo or EPP package + is. + - The EGit problem was discussed the most; pros and cons to "moving + up" to 2.3.1 and re-spinning, or revert to SR1 or some point before + their RC4 update. Pros were lots of fixes improvements have been + made. Cons were there is still risk in last minute changes to such + and important piece of Eclipse. + - Historically, we (PC) started off saying maintenance releases were + bug fixes only (changes in service field only), but "loosened" the + rules to accommodate projects that did frequent releases and desired + to get their latest code to Eclipse users -- a noble and desirable + goal. + - PC probably needs to "tighten rules" about minor updates in + maintenance releases ... say, must be in by RC1, at a minimum. + Perhaps as much as "released at least one month before RC1" even? + - EGit probably needs a "refresher course" on the value of the + Simultaneous Release rules/procedures ... advantages of incremental + contributions, having a cool-off or ramp-down process. (Mike + volunteered Wayne to help :) + - dw will explore easiest way to revert the repo: alternatives are to + try and use the p2.remove task to remove just EGit/JGit + features/bundles from the SR2 specific repo (and then EPP process + would pick up what was in SR1); if that doesn't work the "make an + aggregate repo from the aggregate repo" should do the trick ... just + more "search and replace" in a branch of the contribution files, and + time to literally respin. + - Once new repo is done, Markus's existing process for spinning EPP + packages will be ran. + - Goal was to finish new repo on Monday (or, Tuesday, if complicated). + EPP packages on Tuesday (or Wednesday). Some extra eyes/sanity + checks Wednesday (or Thursday). Allow mirrors to repopulate, and + make "GA" on Friday morning. + - Ian volunteered use of his ["p2 diff" + tool](http://eclipsesource.com/blogs/2012/10/10/introducing-p2diff/) + to compare repos. + - \[After meeting, Matthias Sohn said, in message to cross-project + list, that "SR2 RC3 contains EGit 2.2.0 \[1\] which was released in + December and SR1 contains EGit 2.1.0". But, still, RC3 is late to + change a minor version ... especially now that "trust" is weakened + ... but assume its a little bit more stable? if "pure removal" works + I'd prefer that, since easier and more predicable. If not, I'll look + around and ask others if they feel 2.2 has gotten enough exposure -- + but, that solution requires the "make an aggregate from the + aggregate" approach ... and still lightly tested by package + maintainers.\] + - The trade off on "meeting schedule" vs. "quality release" were + discussed and I reminded all the importance of our timely releases + are not so much for us, or even the Eclipse community, but that + commercial adopters make their product plans based on our dates, so + any delays introduced by us starts to cost real money to them + (rescheduling tests, and what ever else) ... but, agreed that + "software industry" is used to such problems and normally buffers in + plans can accommodate a one week slip for data-damaging bugs, and a + one-time slip of maintenance release should not hurt our + trustworthiness to deliver when we say we will. + +## Issues (from previous meeting) + + - + EGit planning 2.3, but 2.1 is still their common repo contribution? + (That is, why aren't they "fully participating"?) See . Kepler + contribution is even further behind. + + + + - + **Action Item:** Chris will "get back to us" on what EGit's plans + are ... he initially thought "final code" would be done in two + weeks, but I reminded him RC4/final builds are next Wednesday. + +## Next Meeting + + - March 6, 2013 + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/February_7_2018.md b/wiki/Planning_Council/February_7_2018.md new file mode 100644 index 0000000..ba73690 --- /dev/null +++ b/wiki/Planning_Council/February_7_2018.md @@ -0,0 +1,189 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 7, 2018, at 1200 Noon Eastern

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Photon & Oxygen status + - Oxygen 3.a for Java 10 support + - Future of SimRel + +## Attendance + +Aleksandar Kurtakov (Tools Project), Dani Megert (Eclipse Project), Ed +Merks (Eclipse Modeling Project), Frederic Gurr (Eclipse Foundation), +Martin Lippert (Eclipse Cloud Development), Mickael Barbero (Eclipse +Foundation), Mélanie Bats (Obeo), Nick Boldt (Red Hat), Sam Davis +(Mylyn), Thomas Watson (IBM), Wayne Beaton (Eclipse Foundation), EE4J + +## Notes + +### Photon & Oxygen status + +Photon M5 shipped last Friday 02/02. Some project were disable as +EGerrit, Subversive... and the dependent project were disable as well. +LDT missed Photon M5 but will rejoin on M6. + +There were some issues for EPP built see for details. In the end, build +succeeded and packages are available on website. + +Next steps : Oxygen.3 RC1 February 9. Photon M6 March 16. + +### Oxygen 3.a for Java 10 support + +Support for Java 10 will be delivered as an update 3a as what we did for +1a and Java 9. Only projects providing changes needed for Java 10 can +participate in this release. + +The planning approved by the council is : + + - \+0 on Friday + - \+1 on Monday + - \+2 on Tuesday + - \+3 on Wednesday + - EPP on Thursday + - Complete RC Available on (next) Friday + + + + - RC1 +0: Friday, March 23 + - RC2 +0: Friday, March 30 + - GA: Wednesday, April 11 + +Java 10 is mostly a test bend for Oracle short release cycle, there is +few features. From the JDT point of view it is mostly the support of +local variable type inference : + +### Future of SimRel + +The Planning Council has decided for the future of the SimRel that : + + - The release will be 12 weeks long. The releases will occur almost + every 12 weeks +1 or +2 weeks depending on period to prevent + holidays time and keep the planning equal each year. + - All the work will be done only on one stream. + - And that only one repository will be used that will be continuously + updated. A stable "latest" update site will be used to allow the + user to update continuously. + - Specific update sites will be available to reference any release. No + composite repos will be built. + - The opt-in process will evolve, mostly projects would be assumed + "in" and someone will take care of cleaning the outdated projects + from time to time. + - It would be possible to add, update and remove API on any release. + +The Planning Council proposed the following release cycle planning: + + - C1 Friday Week 3 Checkpoint + - M1 Friday Week 5 --\> testing & packages, API breakage in + - C2 Friday Week 7 + - RC1 Friday Week 10 API & Feature freeze + - RC2 Friday Week 11, it is assumed all code is done by the end of + RC2. + - GA Wednesday Week 12 + +Mikael asked if a solution should be developed for rollbacking to a +previous release in order to revert stuff. The conclusion was that it +would be prefered to make efforts to release a new version pretty fast +if needed. + +According to the proposed plan EPP packages will be built at M1, RC1 & +RC2, this means 3 times in 5 weeks. How many manual work it needs? We +should take care of that and discuss this with EPP packages maintainers? +3 in 6 weeks ? Produce packages can be automated ? Mélanie will launch +this discussion on the EPP mailing list to ask the EPP maintainers what +they think about this. + + - How do we name the releases ? What do we do about code names? + +It exists at least 3 different possibilities: + +`* Using a year/month pattern : YYYY-MM` +`* Using codename pattern : CodeName.X` +`* Using a mix of the two previous patterns : YYYY-MM CodeName.X` + +Mélanie will propose something on the mailing list but a first +conclusion was that changing name pattern could just reflect the fact +that things are changing. + +Mélanie will prepare also a mail to cross project to share our post +photon plans to a larger part of the community. \ No newline at end of file diff --git a/wiki/Planning_Council/Galileo_postmortem.md b/wiki/Planning_Council/Galileo_postmortem.md new file mode 100644 index 0000000..64f2ec0 --- /dev/null +++ b/wiki/Planning_Council/Galileo_postmortem.md @@ -0,0 +1,199 @@ +# Galileo Planning Council postmortem + +*These notes were collected at the end of the Galileo Release, +6/17/2009, specifically just to collect them. And not to solve them, or +even suggest solutions, but just to capture issues (good and bad) while +the release was still fresh on our minds. Where solutions are suggested +below, it was just to better capture the issue discussed .. not really +to propose a solution. Action plans and solutions will be discussed in +the Fall.* + +## History + +Galileo is the fourth simultaneous release, following Callisto, Europa, +and Ganymede. The Planning Council met regularly, starting in August +2008, firming up much planning at the face-face meeting in October, +2008, at EclipseWorld. For meeting minutes, see +. + +The number of "must do" requirements was increased from previous years, +with an explicit desire to "raise the bar" and have projects reach a +(slightly) higher level of quality than in the past. The focus remained, +as in previous years, on the 'simultaneous' part of Simultaneous Release +(as opposed to, say, a "one huge product" emphasis). + +The original Galileo-PC Chair (Richard Gronbech) "retired" in January +2009 (due to change in membership at Eclipse) \[thanks for getting us +off to a good start, Rich\!\] and a new chair (David Williams) was named +in March. + +Our first delivered Simultaneous milestone was M6 (previous years were +M5 or M4). + +## Comments from PC during 6/17 meeting + +In general, PC members thought it went "ok", accomplished what was +intended. + +The predictable date is great. + +The common P2 repository is good, and very important (such as for EPP, +and others). Allows a common place to get code that at least is roughly +"correct" (in that the versions match up, the jars are retrievable, etc) +as compared to what it would be like going to 33 different URLs to get +the code that would be needed. + +### Quantities + +And, we did increase the number of projects participating, to 33 (or +so). The quantity was seen as important, and a positive aspect (best for +Eclipse and adopters) ... as long as quality is reasonable, and it is +understandable by consumers. + +One issue related to "quantity" was the inconsistent nature of Project +level. Some, such as DTP, WTP, release and are tracked as one Top Level +Project (even though each made up of a number of sub-projects). Others, +such as Modeling projects not only had sub- projects, but also +sub-sub-projects. It was noted that even then, while there were 33 +"projects" tracked for Galileo, there were 50 "projects" from the +Foundation's records and IP Logs. So at least consistency could be +improved, if not perhaps even have an explicit "roll up" to top-level +projects. + +Another issue related to quantity: consistency with things like the type +and location of New and Noteworthy would be good. + +Automated tests are good (e.g. to check version numbers, about files) +especially if earlier than this time and those test should be "rolled +out" to Projects to run during their own builds\! + +### Communication + +Many noted that communication with projects (Project Leads) needed to be +improved. + + - + One idea was to have large group meetings. + + + + - + Another was encourage PMC reps to communicate more with their + Project Leads they are representing. + + + + - + Another was to perhaps meet "with everyone" once per milestone. + +Some specific communication issues: + + - + 'Capabilities' requirements were not communicated well, and could + improve their "delivery". + + + + - + Late breaking requirement for Projects to update their meta-data to + signify participation was not communicated to each PL. + +### Quality and Purpose + +The nature of "must do" was questioned. Some voicing support that most +really are "must do" to use project code as a coordinated release (for +example, signing doesn't help much unless everyone does it), even "new +and noteworthy" (not done by several projects) was probably not +communicated well that the goal is to "communicate with your users and +get your early testers motivated to do some early testing" .... and +without some early testing, it's not much of a release. + +Some suggested presenting "must do" more along the lines of +"good-for-you to do" (i.e. in a project's best interests ... not an +arbitrary rule "for everyone else"). + +Question raised about if "the release" and "update site" should be +decoupled? Then projects could be in common discovery site, even if not +in simultaneous release. \[In previous meetings, we discussed and +concluded "no" ... just documenting here what was discussed\]. + +Keep emphasis on ability to meaningfully consumed (by end-users and +adopters). + +Keep emphasis on "participation" by projects (and even increase that) +(that is, attend meetings, respond to notes, etc.) + +Could "participation" be defined differently for different projects (for +example, some might want to be "date only", some meet some core +requirements, but not all). + +Perhaps projects could decide (in advance) in which capacity they would +participate. And then, "declare intent" early, so adopters know what to +expect. + +Discussion lead to the question of why do projects participate in the +first place? No one seemed to know :) so thought we should ask them. +Some reasons that have been heard in the past: + +\- they want mutual dates to allow easier consumption + +\- coolness + +\- right of passage (a recognized "real" Eclipse project then) + +\- learn a lot from the community of those releasing + +\- publicity and visibility + +\[See Ian's BLOG on the 10 new projects for this release.\] + +### Misc + +Some wondered if we could improve the "delivery" of the code? + +\- new front end to discovery site? Such as more "questions and answers" +or wizard to narrow choices. + +\- should we still have EPP Packages. + +\- not to mention issues of zip files versus installable repositories. + +Some would like longer-than-a-year maintenance. + +P2 is still not used by all adopters, being unpredictable and not +understandable whereas update manager works as expected (in same +context). \[Sort of unrelated to Simultaneous Release ... but kind of +is.\] + +## Notes after the meeting + +One of the 'good' things about this cycle was improvements in the +"aggregation" process; First with the builder created by Rich, which +introduced the concept of modeling in the builds and build process (doh, +why didn't we think of that before\!) and then later with the +Buckminster based builder which, among other things, worked around some +P2 limitations to mirror sites much more quickly than otherwise +possible, and added better 'integrity' checking and not, for example, +accept bundles with incorrect checksums. Hopefully, many of these +concepts can be carried forward into PDE and/or P2 directly, but we +could not have done the Galileo release without these innovative +approaches to dealing with thousands of plugins. + +A thought during final few days. There's really no process in place to +"approve" changes at the last minute. It would be best to have an +initial PMC Review, and then a request come from that PMC to Planning +Council for final "vote" on respin or not respin. + +During August Planning Council, John Arthorne provided some additional +feedback (to paraphrase): The Eclipse Platform team did not participate +in forming these notes, but that it corresponds to their own +team-meeting notes, except they would have also added the "+1", "+2" +categories of dependencies may be too simplified, since in reality, some +projects need to deliver part of their components, say, at +0 or +1, but +another leaf component at +2 or +3). They would also appreciate making +sure that the simultaneous release criteria be better explained. + +See also +[Galileo_postmortem_PLs](Planning_Council/Galileo_postmortem_PLs.md) + +[Category:Galileo](Category:Galileo "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Galileo_postmortem_PLs.md b/wiki/Planning_Council/Galileo_postmortem_PLs.md new file mode 100644 index 0000000..e172cce --- /dev/null +++ b/wiki/Planning_Council/Galileo_postmortem_PLs.md @@ -0,0 +1,52 @@ +# Galileo Planning Council postmortem: Project Lead feedback + +*Please see +[Galileo_postmortem](Planning_Council/Galileo_postmortem.md) +for similar page produced by Planning Council (PC) itself. This page is +for Project Leads not on PC who think maybe something wasn't captured on +that PC page.* + +*These notes were collected at the end of the Galileo Release, +approximately 6/17/2009, specifically just to collect them. And not to +solve any problems, or even suggest solutions, but just to capture +issues (good and bad) while the release was still fresh on our minds. +Action plans and solutions will be discussed in the Fall.* + +''Please keep comments concrete and actionable, to the extent possible, +for example "communication was not very good" is a bit vague; would be +better to be specific, such as "we were not told about the Foundation +meta-data requirements until the last week, even though others were told +during M7" or "I don't understand the importance of New and Noteworthy +requirement" instead of "I don't like any requirements". '' + +''Also, please consider documenting why you wanted to participate at all +in Simultaneous Release? Would you do it again? Would you recommend it +to a friend? :) What, specifically, could the PC do to make your life +easier next time? '' + +*Thanks for your help\!* + +
+ + - Paul Slauenwhite - TPTP: + - Provide a single release notes page (similar to + + for TPTP 4.6.0) for documenting known issues and possible + work-arounds with the release train. This could be as simple as + a grouping of existing release notes for the projects in the + release train. From the user's perspective, if provides a single + reference of known problems and possible solutions when + experiencing issues with the release, instead of automatically + opening a new Bugzilla. + - Include each project's new and noteworthy page (or reference) in + the release train's new and noteworthy page (see + ). + Note, the release train's new and noteworthy page is currently + called the release notes for the release on the download page. + - Provide a release train 'PMC' review and voting process for the + release train to regualte/process late defects/build requests. + + + + - +[Category:Galileo](Category:Galileo "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Helios_retrospective.md b/wiki/Planning_Council/Helios_retrospective.md new file mode 100644 index 0000000..b61dff6 --- /dev/null +++ b/wiki/Planning_Council/Helios_retrospective.md @@ -0,0 +1,222 @@ +# Helios Planning Council retrospective + +These notes were collected at the end of the Helios Release, at 7/7/2010 +Planning Council call, specifically just to collect them. And not to +solve issues, or even necessarily to suggest solutions, but just to +capture issues (good and bad) while the release was still fresh on our +minds. Where solutions are suggested below, it is intended to primarily +better capture the issue discussed .. not to dictate a or pre-judge a +solution. Action plans and solutions will be discussed in the Fall. + +## History + +Helios is the fifth simultaneous release, following Callisto, Europa, +Ganymede, Galileo. The Planning Council met regularly to firm come up +with plan and requirements. For meeting minutes, see +. + +## Comments from PC during 7/7 meeting + +### Positive things mentioned + + - Released on time + + + + - Infrastructure performance improvements (e.g. bugzilla and cvs) made + things easier, and were appreciated + + + + - Documentation of requirements has improved, over previous years + + + + - Tracking system was better than previous methods + + + + - Dependent projects were done on time, rolled up easily + + + + - IP Process went well, was timely + +### Things that could have been better + + - project identity problem continues: + + + + - + + - + 39 projects in Helios tracking + 54 sets of documents + 62 IP logs + 71 "eclipse projects" + + + + - + + - + need to figure out how to "roll up" to have consistent view. + or, perhaps improve definition of "project to participate" + + + + - + + - + webtools, good examples of "self rollup" + gemeni is an up coming example of ?how to rollup? + modeling ... are there really so many independent sub-projects? + too much "hand waving" about "what's a project". + + + + - problems with "legal documents" not discovered until late + + + + - + + - + how to do earlier, without over burdening projects + + + + - hard to do "testing" ahead of time before final "milestone declared + done". + + + + - + + - + partially since not enough time to fix problem between +1, +2; + especially when projects did not provide "warmup" builds + + + + - Composite repo with 'old stuff' was confusing; something might have + worked in 'staging', but not once rolled up to repo, since there + different content (due to having multiple milestone composites). + + + + - + + - + This was intentional, to find problems, but how to balance + testing composites with being accurate + + + + - too little testing of EPP Packages ... what's expectations? how to + document? + + + + - + + - + in particular, need to document to include "install other stuff" + in the general testing procedures documentation + + + + - too little testing of staging or milestones ... what's expectations? + how to document? + + + + - Tracking tool was good (especially if HTML version produced, and + included in release documents ... was that really said, or was I + hearing things? :) + + + + - One person mentioned requirements were too much "for one person" to + track (esp. for those projects containing many small projects, maybe + with only one committer, maybe on "life support"). + + + + - One mentioned they will "push back" on the list of requirements, + they will ask "why required" ... but didn't mention any specifics in + this call. + + + + - One on Arch. Council wondered if there should be wider "sim. + release" meetings, to encourage more participation on defining or + explaining requirements ... didn't seem to be wide spread desired + expressed at this meeting, but ... should listen carefully if + expressed by others. + +### items from John's note to planning council list + +\- First, I think the post-mortem is a bit early. Last year we did this +in August, and we haven't had a chance to have all the necessary +discussions within our own project to provide good input yet. I hope we +will also have some time in the August call for further discussion on +it. + +\- For planning purposes, it would be useful to know the subsequent +release name earlier. We only selected the Indigo name a few weeks +before the Helios release was out. I'm sure many projects start thinking +about their next release before June and it would help to have a name +associated with it. Perhaps we should even select the next two or three +release names all at once - both for continuity/consistency of naming +and avoid the annual churn of the name selection process (I vaguely +remember this being done before). + +\- Every release train milestone and RC starting with M1 was delivered +on time\! This an amazing accomplishment and the first time this has +been on time for the entire release cycle as far as I remember. Actually +there was one exception: M2 was released a day early. + +\- Having the +0,+1,+2,+3 dates on contiguous days felt a bit tight. +There was no room for build failures or last minute problems. I.e., a +project team has only 24 hours from when their prerequisites are +available until they must deliver their final bits for the milestone. If +they discover a problem caused by their prerequisite they have very +little time to diagnose and iterate with the upstream project. Having +said that, we did manage to ship on schedule every time so maybe it is +ok. One possible improvement would be to encourage projects to deliver +"candidate" builds to the staging repository before their milestone +release date, with the caveat that their bits could still change. That +would allow downstream projects to build/test against the candidate, and +report problems upstream before it is too late. + +\- If we are going to test and enforce legal files in bundles +(about.html, etc), we need to start doing it earlier. It appears this +was only tested \*after\* RC4 and it caused a last minute firestorm for +several projects (bug 316720). I know this is the responsibility of each +project, but if we have the tools available to run on the release train +repository we should try doing it earlier (say M7). + +\- There were a few cases of unexpected contributions sneaking into the +build unannounced after their due date. I think we should have the +flexibility to accomodate late changes but they at least need to be +communicated so anyone downstream can react. It would be nice if we +could avoid it, but maybe we need to "lock" the build at the end of the ++2 date and only rebuild if requested on the list for all to see. I can +give examples where this happened but it's nicer to avoid naming names +;) + +### Items from Architecture Council meeting + +Callers to Architecture Council meeting discussed on July 8. See [those +meeting +notes](Architecture_Council/Meetings/July_8_2010#Helios_Retrospective "wikilink") +for additional feedback items. Some overlap, but some distinct comments. + +## Reference + +See also [last year's +retrospective](Galileo_postmortem.md) + +[Category:Helios](Category:Helios "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Indigo_retrospective.md b/wiki/Planning_Council/Indigo_retrospective.md new file mode 100644 index 0000000..db589cc --- /dev/null +++ b/wiki/Planning_Council/Indigo_retrospective.md @@ -0,0 +1,88 @@ +# Indigo Planning Council retrospective + +These notes were collected at the end of the Indigo Release, at 9/7/2011 +Planning Council call, specifically just to collect them. And not to +solve issues, or even necessarily to suggest solutions, but just to +capture issues (good and bad) while the release was still fresh on our +minds. Where solutions are suggested below, it is intended to primarily +better capture the issue discussed .. not to dictate a or pre-judge a +solution. Action plans and solutions will be discussed later. + +## History + +Indigo is the sixth simultaneous release, following Callisto, Europa, +Ganymede, Galileo, Helios. The Planning Council meets regularly to come +up with plans and requirements. Eclipse Foundation projects can +voluntarily join the simultaneous release. For meeting minutes, see +. + +## Comments from PC during 9/7 meeting + +These rough notes were captured from the "brainstorming" session. We +will refine in future meetings. + +### Positive things mentioned + +communication was good, such as on cross-project mailing list, + +seemed a little smoother than previous cycles + +builds went smoother, mostly passing, only one respin needed + +pretty standard, little hassle + +quality was good + +liked that "checklist" was de-emphasised (i.e. that I did not hound +everyone to complete it, if they did not want to :) + +happy with people willing to help get through issues + +no surprise, dates as expected + +### Things that could have been better + +could use more "in depth" testing or stress testing, especially of EPP +packages, to catch regressions + +some issues with b3 aggregator editor (over all, some thought editor +hard to use) + + - + would expect "repository" view, + would be nice to show how site would look "in the end" + would be nice to make part of build, instead of separate process and + edits + many project "hand edit" files, when b3 aggregator editor used other + files change too (as whole model is saved) + when working with build files, prefer not to need "eclipse" (too + heavy), just adding a file would be better + some use "constant repository" to "get latest" (pros and cons ... + need to be careful) + could be be easier to only "change URL" ... such as perhaps in a + properties file + +late changes to EPP packages (e.g. EGit, etc.); + +easier builds (or example builds) would be good (Tycho, maven, etc., is +working in right direction) +(Jesse reported that he, Chris A., and Dave Carver are working on some +improvements in "dash" project). + +Some mentioned they liked that more and more projects are using Tycho + +Many requirements seem oriented to "IDE", but not "runtime". Maybe we +could distinguish better in write-ups or statements of requirements. + +## Reference + +See also [last year's +retrospective](Helios_retrospective.md) + +See also others' retrospectives (which may or may not be related to +"simultaneous release", per se) + + - [Web Tools + Platform](Team_thoughts_on_continuous_improvement_33 "wikilink") + +[Indigo](Category:Indigo "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Jan_07_2009.md b/wiki/Planning_Council/Jan_07_2009.md new file mode 100644 index 0000000..8624f9f --- /dev/null +++ b/wiki/Planning_Council/Jan_07_2009.md @@ -0,0 +1,71 @@ +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Jan 07, 2009](Jan_07,_2009 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=1&day=7&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Wenfeng Li + - David Williams + - Brian Fitzpatrick + - Thomas Watson + - Oisin Hurley + - JWT project : Mickaël Istria (Release Engineer) and Marc Dutoo + (Project co-lead) + - Ed Merks + - ACTF project : Kentarou Fukuda + - Chris Aniszczyk + - Markus Knauer (but 6 minutes late...) + - Martin Oberhuber (for DSDP on behalf of Doug Gaff, 17 minutes late) + +### Regrets + + - Anthony Hunter + - Doug Gaff + +### MIA + + - TBD + +## Topics + + - Update to dev process to require project plan for + continuation/release/graduation reviews + - Need to clarify requirements for EPP package maintenance, + specifically add link to appropriate place to submit a bug for each + package + - Again, need to announce/clarify what Galileo is, and what it's not + - Working with Requirements Council on potential package testing $ in + budget + - Face-to-face meeting at EclipseCon? If so, what day/time? + - SOA Development category was added to galileo build... OK? + - M4 contribution status to build model + - How to deal with platform-specific bundles in Galileo build - add + each bundle to build model + - TPTP bug that fails p2.director build: + [259603](https://bugs.eclipse.org/bugs/show_bug.cgi?id=259603) + - Follow up on Eclipse SDK packaging/capability definition issues + (Phillipe) + - DTP's many features + +### Reminders + + - TBD + +## Additional Topics + + - MartinO: clarify wording for the [API + requirement](https://bugs.eclipse.org/bugs/show_bug.cgi?id=252794#c1) + (updated on the [Galileo Simultaneous Release\#Must + Do](Galileo_Simultaneous_Release#Must_Do "wikilink") as well as ) + +## Action Items + + - TBD + +**Carry over items** + + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/January_04_2012.md b/wiki/Planning_Council/January_04_2012.md new file mode 100644 index 0000000..da1f493 --- /dev/null +++ b/wiki/Planning_Council/January_04_2012.md @@ -0,0 +1,328 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, January 04, 2012, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=01&day=04&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne (Kim Moir)

Eclipse (PMC)

D

Mik Kersten

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo)

SOA (PMC)

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

(N, but Borislav from Virgo joined in, in case questions about Virgo exception)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Any? + +## Indigo SR2 + + - Reminder: Indigo "warmup" RC1 January 13 to January 20th. Remember + it is called "warmup" since we do not expect it to be a true + "release candidate", important fixes will be not necessarily be in + it, and they will be added in subsequent RCs, we don't expect + adopters to invest much in final acceptance testing with RC1, and + its purpose it to mostly make sure we can all still build the Indigo + stream, get in sync with each other, etc. Subsequent RCs (2, 3) + should be planned to be true release candidates (ideally final + builds, for many projects) with the absolute final build being RC4: + final aggregation build 2/15, for release on 2/24. + +## Juno + +### Issues or Exceptions + + - Any issues? Everyone in? Any exceptions known? + + + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo *(3 +1 approve votes during meeting, Doug, Kaloyan, Kim)* + ''Some from Modeling ... It was thought EMF Query 2 would be + "replacing" EMF Query, perhaps one from GMF Tooling? '' + - + *TODO: DW to send follow-up note to Ed asking him to clarify + exceptions and send note to planning council list, since Ed + was not at meeting.* + +### Plans + + - Yearly reminder to Wayne: allow some time in January to consolidate + plans for "Road-map" to make sure you have what you need for March + board meeting. + + + + - + *Wayne reminded us there is no "road map" for board approval any + longer (due to by-law and dev. process changes), but the plans will + still be "rolled up" and be part of the "report to the Board". Wayne + will look into "pulling out" the "3.8 support" information for + summary, if that's feasible and make sure planning council can + see/review rolled up plans.* + +### Juno+1 Name + + - Name that release: Juno+1. We should review the "candidate" list + before voting, being sure to remove any that we know we could not + live with, so people do not feel they "waste" a vote on a name that + would never be accepted. (Though, we do reserve the right to remove + any, at any time, if new information comes to light, such as a word + has an inappropriate meaning in another language, etc.). \[.\] + +#### Release History + + - 2006 Callisto + - 2007 Europa + - 2008 Ganymede + - 2009 Galileo + - 2010 Helios + - 2011 Indigo + - 2012 Juno + +#### Potential Names + + - Kepler + - Koala + - Kirk + - Kuiper + - Krakatoa + - Kosmos + - Kelvin + - Kinetic + - Krypton + - Knuth + - Kapteyn + - Kahn + - Kratos + - Kronos + - Kore + - Klio + - Koronis + - Kari + - Kale + - Ketu + +#### Voting Names + + - Kronos (probably an issue due to existing companies and trademarks, + can lead to confusion) + - Koronis: + - Kari: + - Kale: + - Kartos: + - Kuiper: + - Kepler: + - Ketu: + +*During meeting, "kale" was removed, due to similarity with vegetable +name, and "Kronos" was removed, agreeing its been used before for +software/OS names. "kepler" was questioned because it was once the name +of an Eclipse project, now archived, but it is believed it never did +much (existed for only a year and a half, and never had an official +release) so Wayne will investigate some to confirm that, but it probably +would not be ruled out. That would leave 6 names to vote-on. Chris will +work with Wayne and webmasters to setup "Eclipse voting poll" (similar +to previous years, where you can vote just once, and have to have at +least a bugzilla account to vote). Thanks Chris\!* + +### Other Business + + - Anything else? + + + + - + *We briefly discussed "priorities" of projects, such as for IP + Review, and in case of the (remote) possibility that the build + machine would have to be rationed, etc. As one aspect of this, we + will keep the "offset" field in tracker and ask projects to fill + that it (many have already) and Wayne agreed to "link in" that + information better in the "list of participating projects" (or + similar). Thanks Wayne\!* + +## Next Meeting + + - February 1, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_04_2017.md b/wiki/Planning_Council/January_04_2017.md new file mode 100644 index 0000000..f2adc45 --- /dev/null +++ b/wiki/Planning_Council/January_04_2017.md @@ -0,0 +1,269 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Jan 04, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

N

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

N

Adrian Mos

SOA (PMC)

N

Carl Anderson

Web Tools (PMC)

N

Fred Gurr

Eclipse Foundation (releng)

Y

Wayne Beaton

Eclipse Foundation (appointed, interim chair)

Y <!--

David Williams

(appointed Chair)

N -->

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

N

Alexander Nyssen

itemis AG (Strategic Developer)

N

Nick Boldt

Red Hat (Strategic Developer)

D (Alexander Kurtakov)

Cedric Brun

OBEO (Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

N

Stephan Merker

SAP AG (Strategic Developer)

N

Markus Knauer

EPP (appointed)

N

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

Ed Merks

Modeling (PMC)

X

Brian Payton

Datatools (PMC)

X

Chris Aniszczyk

Technology (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - No new issues + +## Oxygen Planning + +The following projects have dropped out of the simultaneous release: + + - Andmore - Eclipse Android Tooling + - Eclipse Gyrex Project + - Eclipse Graphical Modeling Framework (GMF) Tooling + - Riena Project + +The GMF Notation Project will merge with GMF Runtime (See ): + + - Eclipse Graphical Modeling Framework (GMF) Notation + - Eclipse Graphical Modeling Framework (GMF) Runtime + +The EMF Transaction, Validation, and Query projects will merge and +reboot (see ). + +We have not heard definitively from these projects: + + - Data Tools Platform + - Thym + - Lua Development Tools (LDT) + +The Data Tools project currently has a single active committer. Neil +Hauge is (reportedly) investigating options for bringing resources to +Data Tools. The Data Tools project is no longer acting as a top-level +project and so will likely be moved into a subproject of either Tools or +Web Tools (see ). + +## New Business + +The EMO is in the process of identifying a new Planning Council Chair. +We are hopeful that we'll have this resolved in time for a new Chair to +take over in July 2017 (immediately post-Oxygen). In the meantime, Wayne +Beaton will assume the Planning Council Chair role on an interim basis. + +Fred Gurr will--effective immediately--take over primary responsibility +for release engineering in the simultaneous release. + +## Next Meeting + + - [February 1, 2017](February_01_2017.md) - + Regular First Wednesday Meeting + +## Reference + + - + \- Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + \- [Neon Wiki page](Neon "wikilink") + \- [Oxygen Wiki page](Oxygen "wikilink") + \- [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + \- [Simultaneous Release + Roles](Simultaneous_Release_Roles "wikilink") and [Simultaneous + Release Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_05_2011.md b/wiki/Planning_Council/January_05_2011.md new file mode 100644 index 0000000..50f5533 --- /dev/null +++ b/wiki/Planning_Council/January_05_2011.md @@ -0,0 +1,430 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, January 05, 2010, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=01&day=05&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

N

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

N

Adrian Mos

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

N

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

N

Christian Kurzke

Motorola (Strategic Developer)

N

Achim Loerke

BREDEX (Strategic Developer)

Y

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

R

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - Welcome and introduce new members ... + +:\*[Achim Loerke, BREDEX (Strategic +Developer)](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05055.html) + + - + + - + [Jubula Project](http://www.eclipse.org/jubula/) + +:\*Others? (that is, who am I missing?) + +## Maintenance Schedule + +### Helios SR2 + +2/25/2011 (Fourth Friday of February) + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +RC1 is getting near ... warmup RC week of 1/17 - 1/21. + +## Indigo Status + + - nearing M5 + + + + - Approved? exceptions for projects joining (late) in M5 (remember, if + any of these projects do not make M5, new exceptions should be + requested for M6). + + + + - + [Jubula](http://www.eclipse.org/jubula/) *Achimim reports "on track" + for M5* + [Window + Builder](http://www.eclipse.org/proposals/tools.windowbuilder/) (see + also [intro msg on cross-project + list](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05064.html)) + *realistic for M5?* + [Runtime Analysis + Tools](http://www.eclipse.org/proposals/tools.rat/) (see also [intro + msg on cross-project + list](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05100.html)) + *realistic for M5?* + [Enterprise Tools for OSGi (tm) Service + Platform](http://www.eclipse.org/proposals/libra/) *Kaloyan reports + unlikely for M5, "just being realistic". We'll re-assess at 2/2 + meeting for M6.* + [Subversive](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05177.html)? + *concerns expressed: inconsistent and unpredictable and unresponsive + ... they likely need "help" from their PMC?* + [GMF Tooling (GMF + Codegen)?](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05133.html) + *Ed reports it is believed its releng woes are being addressed, but + doesn't know detailed status ... there are people, but maybe not yet + required skills? ... it would be disruptive if not in release (some + do depend on it) ... and, obviously, disruptive if they continue to + "break the build".* + + + + - + + - + *The Planning Council formally approved exceptions for all 6 of + the above projects; joining Indigo Release, in M5 ... but, with + concerns expressed (summarized above), and much discussed. In + particular, it is not believed to be realistic for those new + projects still being reviewed and provisioned, especially those + with large, existing code bases (can they even get through IP + review?). We discussed alternatives, such as them joining in + Indigo SR1. Also, we reminded ourselves projects can "release" + with Indigo, but not be part of the common repository ... fewer + requirements on them, in that case ... and users just have to + get that code/function from those project's own sites, instead + of central repo. The excellent point was made that its not just + a matter of "mechanics" of getting things done in time, but also + getting adequate "community review and testing". For an example + (just as an example) would the "window builder" play well with + others, or subtly change the behavior of Java Editor? And it + might be just fine to "change behavior" ... but, need adequate + community review and testing **before** being released to know + if its ok, or not. There might be willingness to allow late + comers to M6 ... but, beyond that, other alternatives (SR1, or + project-only repos) would likely be preferable solutions. It + mostly comes down to how "disruptive" they are ... disruptive to + end-users, or disruptive to other projects trying to + build/aggregate/release. In the code/benefit curve, it was + acknowledge there is great benefit ... but not above all cost. + So, while we approve for M5 ... we expect we will be discussing + more at future meetings.* + + + + - remember to aggregate project tracking, IP logs, docuware, etc., and + [update project + meta-data](Development_Resources/HOWTO/Project_Meta-Data "wikilink") + as Wayne requested in [cross-project + note](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05063.html). + + + + - Any concrete ideas on how to improve aggregation timing or workflow? + If so, please comment in ... or, should I close it as "won't fix"? + +## Indigo Plan and Schedule + + - [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - See also [Indigo Wiki page](indigo "wikilink") + +## Other business + + - Discussion on build machine QoS (JohnA): + + + + - - Is build machine contention/availability currently an issue for + projects? + - Do we need to adjust schedules to account for this? + - Consider other measures such as reducing continuous or regular + builds during milestone periods? + + + + - + *There was agreement this might become a problem (has been in the + past), but not sure if it currently is, and not sure what to do + about it if/when it becomes a problem. Its hard to pick favorite + projects or take away resources from some committers ... though is + is a shared, constrained resource, so might come to that. And by + "take away" it it meant to reduce, have various rules about niceness + level that are enforced, etc.* + + + + - + *TODO: I (dw) agreed to ask webmasters if there was some way to see + who was using what how much, as improved understanding might lead to + better solutions.* + + + + - + ''Long term, if it is only a matter of "peak usage", may want to + investigate (or, encourage others to investigate:) some sort of + "cloud" solution so during final milestone/release weeks we could + have 10 slaves, or something, whereas most of the time we just need + one or two. '' + + + + - + + - + '''Response: '''(from email discussion with master webmaster, + Denis) + - + No resources to do "cloud computing" (unless, someone + donates it). + In current system, greatest bottlenecks will be hard disk + access: "Everyone pulling CVS/SVN/Git files, writing to + /shared, uploading to downloads, and so on takes a toll on + disk performance. The separation of anonymous/external + pserver to another dataset will likely help tons." + There is no way to monitor/track CPU Utilization "by + project". + Specific advice to minimize risk (riskiest usage): + - + Building only when needed, \[and, **testing** only when + needed\]. + not running too many builds concurrently, + avoid scanning the file system for nothing (by using + find, or chmod \* -R for instance), + building during off-peak hours (Fridays, weekend), + minimizing disk operations (copies, moves, deletes, zip, + caching 3rd party dependencies, etc), + respecting the [Server Storage + chart](http://wiki.eclipse.org/Image:Build_infra_layout.png), + avoiding hogging all the RAM... + + + + - + + - + *As Eclipse Leaders, we need to infuse "efficient use of + resources" in our development culture ... but, as Planning + Council, no known actions.* + *The "cloud computing" solution was discussed and questioned ... + wondering if it was technically feasible, with security + concerns, and all. It was suggested that more hardware might be + "easier" to make use of than "the cloud". Although that sounds + like a challenging dare for someone with cloud computing + solutions to prove or show case. (hint hint :)* + +## ToDo Items + + - **It is time? ==\>** Note from Wayne, to Wayne: (from previous + meeting) Remember to review plans starting after M4 (at latest) so + questions can be clarified before "road map" produced. + + + + - **Was there a note for this item?** Wayne teased us all with promise + of new tools to check CQs against downloads, which we projects can + use ourselves ... but he wasn't ready to tell us about them today + and he'll be saying more over next few days or weeks. + + + + - TODO (from previous meeting): dw to add/create add a FAQ item around + "what to handle 3.7 vs. 4.1". Will draw from previous [working + notes](Indigo/HowToAddress37And41Platform "wikilink"). + + + + - '''New TODO?: ''' Need common pages for a) plans b) migration c) + N\&N? + + + + - + A contributor (Hendy.rainbowpurple.com) added these for Eclipse + project to [Indigo Wiki Page](Indigo "wikilink") ... but, shouldn't + we have central page, with potential for each project to add links + to their plans, migration guides, and N\&N? Is there a better way? + +## Next Meeting + +February 2, 12 noon Eastern + +## Reference + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_06_2010.md b/wiki/Planning_Council/January_06_2010.md new file mode 100644 index 0000000..533e98f --- /dev/null +++ b/wiki/Planning_Council/January_06_2010.md @@ -0,0 +1,394 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, January 06, 2010, at [1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=01&day=6&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) 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)

Y

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)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

R

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

N

Christian Kurzke

Motorola (Strategic Developer)

N

+

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 + +Any SR2 issues? We will try RC1 as a rollup-warmup. RC2 will be true +"release candidate". + + +Note: Remember we need to make SR2 "additive" with SR1 ... which + +1. requires some changes in builder to version categories +2. provides opportunity for more testing? + +## Helios + + - Remember to get your projects to + \[| + submit CQ's by end of M5\], and write in comments they are required + for "helios" + + + + - Thanks for the [summary](Simultaneous_Release "wikilink"), John\! + +:\*John asks, What do we call this thing we do? "simultaneous release", +"coordinated release", "annual release", "release train"? + +:\*And ... who releases it? "The Eclipse Foundation", "The Eclipse +Community", "The Eclipse Projects"? + +Resolved: best to use "Simultaneous Release" and "The Eclipse +Foundation". (There was discussion that maybe "the PLanning Council" +(but, no), and concerns that "the Community" was too inclusive, and "The +Eclipse Projects", while correct :), is included as part of "The Eclipse +Foundation". + + + + + - Discuss [Helios/Participating + Projects](Helios/Participating_Projects "wikilink") document? + Finalize? + +:\*Runtime + + - + + - + Where's Riena? + *Tom to follow up with Riena and request exception if needed.* + + +:\*Technology + + - + + - + egit and linux-distros have "expressed intent" but since not in + build, require an + [exception](http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php#pcExceptionProcess). + ''Wayne to follow up with these projects and request exception + if appropriate. (He note 'egit' in particular was important to + the "business" of Eclipse). '' + + + +:\*Modeling ... where to start? :) + + - + + - + What is EEF? They (Cedric?\!) just today are adding themselves + to build. Appears a clear case where an + [exception](http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php#pcExceptionProcess) + is required first? + ''Thanks to Cedric for reading agenda ahead of time and knowing + he needs an exception. Him and Ed will discuss sending "formal" + request to planning council list. * + *Ed acknowledge projects such as GMF "are hard to contact" due + to changes in companies and individuals status ... but, he will + work on and resolve, since GMF is so important. '' + + + + + - How is the "one row == one release" rule looking? + +*Ed agreed to fix up his part of table ... as well as make sure the +subprojects do "roll up" with in the primary rows.* + +''We still need rep for dsdp. '' + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

TLP

N Projects

BIRT

1

Datatools

1

DSDP

3 ?

Eclipse

1

RT

5

SOA

1

TPTP

1

Web Tools

1

Tools

6

Technology

6

Modeling

10?
+

+ + + + +### Proposed (initial) Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +#### Structure of Common Discovery Site + + - + users vs. extenders (minimum runtimes vs. SDKs) + runtime targets vs. tools + hierarchical categories (are more levels required?) + +#### Tracking progress and compliance + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + +## Long Term + +### What needs to be done for e4? + + +Notes: The fundamental question is if it will be a requirement, in 2011, +that to be part of the Simultaneious Release, such as "Projects must +build on and fit in with e4 (even if not exploit it)". Our intuition is +this would be a nice requirement ... but, its unclear how hard this is +and if it is feasible. And ... the point is, we should begin that +investigation before Helios and before e4 0.9 (so, we'd know early if +feasible or if fundamental prohibitive issues. + +Some things, like "building on e4" is not posible right now, but should +be in March or April. + +Other things, like running API cleanliness tests, can be started soon. +API cleanliness is critical to have an easy transition to e4. +*Chris will put that test/measurement in place. +* + +''David to add some small infrastructure to kick off junit tests, so +Chris can add a plugin to do the tests. '' + + +## Other business + +Need to clarify "capabilities" requirement, even remove them from the M5 +build. After note to cross-project list (David to send). + +## ToDo Items + +(volunteers welcome) + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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 + + - [February 03, 2010](February_03_2010.md) + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_06_2016.md b/wiki/Planning_Council/January_06_2016.md new file mode 100644 index 0000000..86486a4 --- /dev/null +++ b/wiki/Planning_Council/January_06_2016.md @@ -0,0 +1,394 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 6, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Nick Boldt

Redhat (Strategic Developer)

Y (plus Michael to "listen in")

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

(was John Arthorne)

Cloud (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Mars Planning + + - Mars.2 issues? + - Remember Mars.2 RCs begin Jan 15 to Jan 22. + - Tracking participation in minor releases + +## Neon Planning (and beyond) + + - Our [Neon Plan](Neon/Simultaneous_Release_Plan "wikilink") is now + official. + + + + - Should we change "maintenance" staging name now? for Mars.2? See . + + + + - + \- Since "Nick votes for soon", I will ask: "Any objections"? + + + + - + ''No objections. And one "good idea since is currently confusing". I + will look into implementing and see what breaks. :) '' + + + + - + \- \[See also for unreleated additional URL.\] + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + One proposal: have all features in EPP packages be "root features" + and establish a procedure of adding new code to the Sim. Release + repository "at any time" (or, say, once per month?) -- say for "hot + fixes" only ... say after review/approval by Planning Council? + AND, to avoid "contamination" of update site lists (without the user + being in charge of it) change p2 install/update to not allow the + addition of reference repositories during feature installs. But, it + has been stated, adopters still want that ability ... so, not sure + how "we" could ever know the difference. + - + Perhaps could solve with a "product preference" so EPP could + "set" the preference one way, and adopters creating products + could set it another way? Or, direct users to do so? + - + Easy for me to say "change p2" :) but ... who would do the + work? + Perhaps solve simply with a "policy" of "do not add reference + repositories" (with feature installs)? + - + But without some way to enforce it, I think some projects + still would. + This "reference repositories issue" was a discussed as a concern + at Architecture Council + - + Apparently there have been cases of users getting "mixed" + installs because reference repositories are sometimes very + broad. \[I hope I've captured the issue correctly, I was not + there, so please correct if I read it wrong.\] + Does Oomph solve this problem at all? Does it have a possible + solution? + - + From [Ed's note to ide-dev + list](https://dev.eclipse.org/mhonarc/lists/ide-dev/msg01043.html), + it sounds like it solves the issue of updating non-root features + (as long as they are "in the repository"?). + + + + - + *Appears there is little consensus on "what the problem is" and even + less on "how to solve". There was a consensus that "users get bad + bugs fixes quickly" and "users should not need to know a lot to get + them", but other than that little consensus. It is believed that not + all projects who use "reference repos" use them for the purpose of + "hot bug fixes" and some may use for "anything". Are "reference + repos" all that bad? (Those that produce "products" can "work + around" the problem by "stripping out" that part of the content + metadata they mirror.) Is there "another way" that is feasible, from + a technology/manpower point of view. Discussion to continue. I do + think current situation and many proposals are a little too "wild + west" (uncontrolled) for Sim. Release) but a well-controlled + method/procedure will take work.* + + + + - Rolling "release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + What testing would projects have to do? + May become "defacto requirement" once is implemented. + + + + - + *Seemed to be no objection to "trying it" and with Neon we will "try + it" by having the "streamless-URL" proposed in . For Neon, we will + not use that URL automatically anywhere but users can add it if they + would like. Will be interesting to see if many bug reports occur + from people trying that "update to next main release" (that is, from + Mars to Neon).* + +## Neon + 1 Planning + + - How's "naming" coming? + - Poll: -\> + + - Current winner (with 242 total votes) and 8 days left: Oxygen + +*Not quite a "majority", last I looked, but guess that is supposedly the +advantage of the voting method used. (Sort of an automatic "runoff", +conceptually.)* + +## EclipseCon Face-to-face + + - Joint meeting with Arch. Council. + - Participate on + [EclipseCon2016/Councils_Face-to-Face](EclipseCon2016/Councils_Face-to-Face "wikilink"). + - Suggest times on [doodle + poll](http://doodle.com/poll/7xphrzbeis678d5n). + +## New Business + + - ? + +## Next Meeting + + - February 3, 2016 - Regular First Wednesday Meeting + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_06_2016/bug483322.md b/wiki/Planning_Council/January_06_2016/bug483322.md new file mode 100644 index 0000000..cabeafa --- /dev/null +++ b/wiki/Planning_Council/January_06_2016/bug483322.md @@ -0,0 +1,101 @@ +This is a discussion / proposal page for how we could implement a +solution for . + +----- + +For Neon, if we wanted, we could easily produce *only the most stable* +releases (Neon.0, Neon.1, Neon.2, Neon.3), releases with +emergency/maintenance updates, and even a third option to include +**minor** updates. + +Here's how that could work, and what would be in the sites. + +## Sites + +1\. + +` * This composite would only reference the main Neon(.x) site` +` * No additional project-specific refs would appear here; we could even scrub them out of the content.xml if we wanted [1].` +` * No out-of-band updates (ie., CDT couldn't push a 1.0.1.Final update into this site until Neon.1)` +` * Projects would contribute x.y.0.Final bits only` + +2\. + +` * This composite would include the main Neon site + composite site refs to child projects' update sites (for emergency/maintenance updates only)` +` * No additional project-specific refs would be exposed to Eclipse's Available Update Sites preference page, but p2 could still find & load those child sites` +` * Out-of-band updates possible here (ie., CDT could push a 1.0.1.Final update into this site one day after Neon.0, without having to wait months for Neon.1)` +` * Projects would contribute x.y.0.Final bits, plus any x.y.z.Final bits too` +` * No x.(y+1).0 or (x+1).0.0 updates permitted, as those are minor/major updates and could break API/introduce new/unexpected features` + +3\. + +` * This composite would include the main Neon site + composite site refs to child projects' update sites (for minor & maintenance updates)` +` * No additional project-specific refs would be exposed to Eclipse's Available Update Sites preference page, but p2 could still find & load those child sites` +` * Out-of-band updates possible here (ie., Mylyn could push a 3.18.0 update to its 3.17.0 bits in Neon.0 a day after Neon.0 ships, without having to wait months for Neon.1)` +` * Projects would contribute x.y.0.Final bits, plus any x.y.z.Final or x.(y+1).0.Final bits too` +` * x.(y+1).0 updates are permitted, at the projects' discretion, as long as no features are REMOVED or unexpected UI changes occur without reasonable cause (eg., fixing a UX problem?)` +` * No (x+1).0.0 updates permitted, as those are major updates and could break API.` + +Here's a sample of what these composite\*.xml files could look like: + + + +## Steps to implement + +Implementation requires small changes by each project that contributes +to the simrel process. + +These changes effectively separate artifact publishing from artifact +update policy. + +1\. All the projects would be required to remove any *feature.xml*, +*p2.inf*, or other instructions/metadata that hard-code an update site +URL into their update site or their contributions to the Neon site. This +would allow site \#1 above to be *pure*, with no external update site +references to projects' update sites. + +2\. All the projects would be encouraged to submit a pull request to +\*.xml +(and to +\*.xml too if +they choose) to contribute their update site URL to the overall +composite site. + +3\. EPP packages should be updated to include by default these URLs: + +` * `` (enabled by default; includes `` inside its list of children sites)` +` * `` (disabled by default; includes `` inside its list of children sites)` + +## Benefits / Impacts + +1 This would allow **BY DEFAULT** that all EPP package users could +discover project updates from /maintenance/, and to be able to +optionally enable /minor/ updates too, if they want those arguably less +stable too. + +2\. By creating these new composite sites in new URLs under +/maintenance/ and /minor/, nothing has to change in the root +/releases/neon/ site in terms of how it's built & published. + +3\. By creating a place for maintenance updates, we can let projects +provide bugfixes at a faster cadence than the quarterly simrel releases, +balancing stability with continuous integration. + +4\. By creating a place for minor updates, we can let projects move at a +faster cadence than the quarterly simrel releases, for those users who +want more frequent change (eg., early adopters, companies working +closely with / contributing to upstream Eclipse projects for their own +products). + +\-- + +\[1\] - JBoss Tools uses a maven mojo that scrubs external refs when +creating an update site. You can also use an Ant script with XSLT: + + - + - + +\-- + +As an alternative naming scheme to folder names */maintenance/* and +*/minor/*, we could go with */stable/* and */development/*. \ No newline at end of file diff --git a/wiki/Planning_Council/January_07_2015.md b/wiki/Planning_Council/January_07_2015.md new file mode 100644 index 0000000..bde04f1 --- /dev/null +++ b/wiki/Planning_Council/January_07_2015.md @@ -0,0 +1,313 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 7, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

R

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

R

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

R

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Thanks goes to Chris for staring the yearly "name that release" + process: + + + + - + + - + + \- Naming Mars+1 (2016 Eclipse Simultaneous Release) + + As Chris said in message to mailing list, **Neptune** was + "winner", currently being vetted by EMO. (With 'Nova' being + second choice, if issues with "Neptune".) + + + + - **Luna SR1 fix proposed, to address JGit security issue.** It has + been proposed (), that we fix the "Simultaneous Release" repo, and + SR1 packages that have JGit in them. See the [thread on "committers + list"](https://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg01023.html) + for more information about the root problem. + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Luna SR2 + + - Any issues? + - Reminder: SR2 RC1 (warm-up RC) is next week (starting 1/16 + concluding 1/23). + - Reminder: "signing certificate" will be changed (renewed) right + after SR2. () (Not expected to have any effect on "Simultaneous + Release", but might on some in eco-system, or perhaps some "testing + systems"). + - Reminder: There is high risk that the "signing of Mac executable" + will not be working for SR2. Perhaps not Mars? Any business impact? + + + + - + + \- Need to update "Mac signing service" + + \- Change location of eclipse.ini (for Max OS X signing) + +## Mars Planning + + - Any issues? + - Remember that "M5" is the "EclipseCon milestone". + - Remember that Feb 13, 2015 is the CQ Submission deadline for Mars. + - Improving categories in Simultaneous Release repo? See + [SimRel/Feature Categories](SimRel/Feature_Categories "wikilink") -- + Wayne? Have a proposal yet? + + + + - + ''Wayne could not make the meeting, but posted [status and + questions](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02331.html) + on mailing list. + +## Progress on Action Items + + - Prune "callisto-dev" group soon . + - Improve "aggregator examples/doc". (dw -- no progress). + +## New Business + + - Who is going to EclipseCon? Want to have (or volunteer to lead?) our + traditional "Sunday 2 to 4" meeting? + + + + - + *It was suggested to have only the "joint meeting", and preferably + "as late as feasible" (just so more could attend the meeting, + without aggressive travel plans.) Perhaps 5ish on Sunday? 7 or 8? + (if no other events/activities).* + +## Next Meeting + + - February 4, 2015 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_08_2014.md b/wiki/Planning_Council/January_08_2014.md new file mode 100644 index 0000000..8322234 --- /dev/null +++ b/wiki/Planning_Council/January_08_2014.md @@ -0,0 +1,323 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 8, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

R

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Chris has started [the "vote" for Luna +1 + name](https://eclipse.org/luna/planning/poll2015.php). + + + + - + + - + Any names objectionable from the start? I think Chris did a good + job of screening them, but one person, in , cautioned against + using 'magellan'. + +## Kepler SR2 + + - "Warm up" build [this + month](Kepler/Simultaneous_Release_Plan#SR2 "wikilink"). + + + + - *We were reminded that CDT, Linux Tools, and EGit (at least) would + be having "new releases" in SR2. PMC reps, please keep tabs on your + projects and make sure they they are transparent in making "minor + upgrades" and keep their PMCs and community informed of what's to + come.* + +## Luna Planning + + - Follow-up: Review Policy Wording and Requirements: + + + + - + + - + I incorporated the wording in the FAQ. See + [SimRel/Simultaneous_Release_Policy_FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink"), + the note that starts "\[added April, 2013, modified November + 2013\]". + We approved + [requirements](SimRel/Simultaneous_Release_Requirements "wikilink") + for Luna? + + + + - + + - + This time I remembered to "send [the + note"](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10094.html) + but wanted to document in these minutes in case it gets "lost in + list". + + + + - Remember to comment in about requiring Java 7 for all EPP packages, + if you haven't yet, and if you have an opinion. (Just as "leaders in + Eclipse" ... not really our Planning Council's decision. Seems to be + trending towards "consistency" ... but ... I think still some + inconsistencies in how "products" handle it, vs. p2 (i.e. with p2, + people could easily "create" a Java 6 version of EPP package). + + + + - *David to send out note soon of who had disabled + contributions/features in M4, which will be removed. And, somehow, + compare notes with Wayne to make sure our lists of "who is in" + match.* + +## Progress on Action Items + + - GSoC project for "Development Channel"? (Wayne) + + + + - + + - + '' While GSoC is over, for a year, Wayne will at least recall + history and open a bug for this.''. + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + - Complete Google Calendar. (dw) + - Compute Luna SR dates. (dw) + +## Next Meeting + + - February 5, 2014 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/January_3_2018.md b/wiki/Planning_Council/January_3_2018.md new file mode 100644 index 0000000..b58ffe6 --- /dev/null +++ b/wiki/Planning_Council/January_3_2018.md @@ -0,0 +1,177 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, January 3, 2018, at 1200 Noon Eastern

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Oxygen & Photon status (by Fred Gurr) + - CBI aggregator + - Future of the SimRel (by Mélanie Bats) + +## Notes + +/\!\\ Very low participation : Kind reminder to everyone, as a Planning +Council Member you should participate to the call and to the mailing +list, when you are not available for the call you should send a +representative. + +### Attendance + +Aleksandar Kurtakov (Tools Project), Dani Megert (Eclipse Project), +Frederic Gurr (Eclipse Foundation), Mélanie Bats (Obeo) + +### Regrets + +Martin Lippert (Eclipse Cloud Development PMC), Alexander Nyssen (itemis +AG), Mikael Barbero (Eclipse Foundation), Wayne Beaton (Eclipse +Foundation), Nick Boldt (Red Hat; on vacation this week) + +#### Oxygen & Photon status (by Fred Gurr) + +Not a lot to say, Photon M4 & Oxygen.2 were released. Next steps : +Photon M5 Friday, February 02, 2018 and Oxygen.3 Wednesday, March 21, +2018 + +An Oxygen.3a should occur due to the release of Java 10 in March 20, +2018 + +#### CBI aggregator + +Raised by Stephan Herrmann + + +Should we keep CBI aggregator alive or do we switch to a Tycho based +solution? + +Aleksandar points that the code of the CBI aggregator is outdated, +unmaintainable and makes lots of assumptions about P2 that are not +anymore true. No one still knows the code base. In another hand, lots of +people are used to work with Tycho. A year ago Mickael Istria started to +create some patches to got to a Tycho based solution. Fred will have a +look to the remaining patches not yet merged. Aleksandar says that they +will try to push to a Tycho based solution but without any promise. In +any case, Fred will support any moves, and keep the releng running until +a new solution works. + +#### Future of the SimRel + +The Planning Council has decided for the future of the SimRel that : + + - A new release will occur every 12 weeks. + - All the work will be done only on one stream. + - And that only one repository will be used that will be continuously + updated. A stable "latest" url will be used to allow the user to + update continuously. + - Specific urls will be available to reference any release. No + composite repos will be built. + - The opt-in process will evolve, mostly projects would be assumed + "in" and someone will take care of cleaning the outdated projects + from time to time. + - It would be possible to add, update and remove API on any release. + +The Planning Council discussed the following points during the call: + + - A first release cycle planning was discussed: + - M1 Friday Week 2 + - M2 Friday Week 4 + - M3 Friday Week 6 + - M4 Friday Week 8 + - RC1 Friday Week 9 API & Feature freeze + - RC2 Friday Week 10 + - Quiet week Week 11, it is assumed all code is done by the end of + RC2. + - GA Wednesday Week 12 + +We still need to be nail how the legal team can handle the load of CQs +and how we deal with the release reviews, maybe they can be simplified? + +When the EPP packages will be built ? For each milsetones and RCs? How +many manual work it needs? We should take care of that and discuss this +with EPP packages maintainers? + +Between M4 and RC1 accepted changes will be only the ones to adjust what +came with M4 for projects that are higher in the stack. + + - The existence of a nightly SimRel build was also discussed, would it + be an aggregation only build ? or building from the source ? It was + conclude that it would not be necessary if the Gerrit builds run + enough. \ No newline at end of file diff --git a/wiki/Planning_Council/July_07_2010.md b/wiki/Planning_Council/July_07_2010.md new file mode 100644 index 0000000..84d6e20 --- /dev/null +++ b/wiki/Planning_Council/July_07_2010.md @@ -0,0 +1,231 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, July 07, 2010, at [1700 UTC / 1300 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=07&day=7&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne (Kim Moir representing)

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

Doug Gaff ???

Dsdp (PMC)

Anthony Hunter

Tools (PMC)

Oisin Hurley

Stp (PMC)

Ed Merks

Modeling (PMC)

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + +

Wayne Beaton (and Janet Campbell)

Eclipse Foundation (appointed)

Y

+


+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.

+ + + +## Should we move meeting time to 1 PM (Eastern) permanently? + + - some expressed desire to move later ... but not enough on call to + decide (especially from European time zones) + + + + - + + - + ACTION: dw to send note to mailing list, with 3 options, noon, 1 + pm, 2 pm + +## Announcements + + - Oliver announced TPTP is not planning to be part of Indigo. Will + participate in Helios Service Releases but then have a termination + review. + +## Helios SR1 + +Switch for b3 aggregator format files? + +### Maintenance Schedule + +SR1 Fourth Friday of September 9/24/2010 + +SR2 Fourth Friday of February 2/25/2011 + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Helios Retrospective + +Please review [Galileo +Retrospective](Galileo_postmortem.md) prior to +Helios Retrospective meeting + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +## Indigo Plan and Schedule + +TBD + +## Other business + + - ? + +## ToDo Items + + - ? + +## Next Meeting + +August 4. 12 noon? Or permanently move to 1 PM Eastern? + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/July_10_2018.md b/wiki/Planning_Council/July_10_2018.md new file mode 100644 index 0000000..0fe8bd4 --- /dev/null +++ b/wiki/Planning_Council/July_10_2018.md @@ -0,0 +1,166 @@ +## Logistics + +**Pay attention time has changed, the meeting is one hour earlier than +before** + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Tuesday, July 10, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Need chair for September, October & November meetings + - Photon status : MPC request for respin + - 2018-09 : Status & SimRel URLs + - Need to update this document / appoint new owner (last update 2016, + David Williams) : + + +## Attendance + +Frederic Gurr, Mikaël Barbero, Nick Boldt, Mélanie Bats + +## Regrets + +Dani Megert, Martin Lippert, Alex Kurtakov + +## Notes + +### Chair for September, October & November meetings + +Mélanie Bats will not be available for September, October and November +due to her maternity leave, someone from the community should take the +chair position for this period, in last fallback, Wayne could take the +role but it would be prefered if someone else from the community take +it. Mélanie will send a mail to the mailing list about this topic. + +### Photon status : MPC request for respin + +It was discussed that the process was slow, we had few votes and lots of +undecided votes, so it did not come to a conclusion on the mailing list. +Fred argued that the problem still exist and that we can fix it even if +it is late. Nick propose that we could fix it for M1 of the next release +2018-09. Mélanie proposed that it is no worhty on a repsin but to just +add a note on the web site about the spacing issue on windows. Mélanie +will send a mail on the planning council mailing list to inform everyone +about this decision. + +### 2018-09 : Status + + - SimRel URLs + +Fred has created the URLs 2018-09 according to the same pattern as +before : + See the bugzilla +[\#536420](https://bugs.eclipse.org/bugs/show_bug.cgi?id=536420) + + - Update wiki + +[SimRel Plan +Requirements](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements) +on the wiki must be updated. Mélanie will update it and planning council +members will review it. + + - Build maintenance + +Fred explained that he is working on config optimization on the Jenkins +and the Tycho builder in order to simplify the build job maintenance. +Mikaël added that they are migrating to the new infra to test pipelines. + + - Opt-in process + +The opt-in process is still not clear for everyone. It was written on +the +[FAQ](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ) : +"The period to join the simultaneous release is at the beginning of any +cycle, four times a year. The project needs to declare its intention to +join before the +0 (Friday) of the M1 release week." This means that +projects should opt-in before July13th for the 2018-09 release. We have +discussed by the past that the opt-in would be automatic and just +opt-out was needed. We agreed during the call that the opt-in will occur +once a year after the June release and means that project will be in for +a year. Mélanie will send a mail on the mailing list to get the +approbation of the planning council and then if it is ok will clarify +the situation on the FAQ and on cross-project. + + - Missing deadlines + +Some deadlines are not defined for CQ, IPLog... for 2018-09, Mélanie +will send a mail to EMO in order to get those dates. \ No newline at end of file diff --git a/wiki/Planning_Council/June_01_2011.md b/wiki/Planning_Council/June_01_2011.md new file mode 100644 index 0000000..6f19353 --- /dev/null +++ b/wiki/Planning_Council/June_01_2011.md @@ -0,0 +1,268 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 04, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=06&day=01&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - ? + +## Indigo + +### SR dates + +We discussed, finalized Indigo SR dates, as documented in +[Indigo/Simultaneous_Release_Plan\#Service_Releases](Indigo/Simultaneous_Release_Plan#Service_Releases "wikilink"). + +We were reminded that EclipseCon 2012 may not be at its usual time in +March ... e.g might be in April ... so that might effect later +milestones, once we plan dates for milestones. + +### Non compliant projects for Indigo release ... status/plans? + +many Indigo bundles missing legal files in RC2 repo + +It was stated that things like missing about.html or SUAs are not really +"planning council requirements". They are simply EDP/IP requirements and +must be done, for release. + +several projects not using 4 part version numbers + +Chris committed to E/JGit having 4 part, by release, and thereafter. + +Unsigned jars in Indigo ... + +Any other concerns? + +*None mentioned* + +## Juno Release Planning + +*No specific planning discussion happened at this meeting* + +## Juno Dates + + - + Release: June 27, 2012 (fourth Wednesday) + SR1: September 28, 2012 (fourth Friday) + SR2: February 22, 2013 (fourth Friday) + +TODO: compute milestone dates, similar to previous years. + +## Next Meeting + + - August 3, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + - We'll skip regular meeting, July 6, ... we will still be celebrating + another successful release\! :) + - We will try to start "retrospective" discussions at the August 3 + meeting. + + + + - + + - + TODO send reminder a few weeks in advance. + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](Indigo "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_02_2010.md b/wiki/Planning_Council/June_02_2010.md new file mode 100644 index 0000000..be8f562 --- /dev/null +++ b/wiki/Planning_Council/June_02_2010.md @@ -0,0 +1,306 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, June 02, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=06&day=2&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

N

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

R

Doug Gaff ???

Dsdp (PMC)

Anthony Hunter

Tools (PMC)

Y

Oisin Hurley

Stp (PMC)

N

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

R - travelling

Christian Kurzke

Motorola (Strategic Developer)

N

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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.

+ + + +## Helios + +### Next Year's Name + +Should we do over? (Just kidding) + +[Indigo](Indigo "wikilink") it is + +### Who will lead the Planning Council next year? + +And the winner is ... myself (David Williams) to continue in this role. + +### Helios Release + + - + Post RC4 exception process? + + + + - + + - + Question from John: + +According to our schedule there is one more week of potential builds +after RC4, labeled "Helios Final". I see on the planning wiki that it +says, "only emergency fixes for very serious regressions will be +considered." I can't remember if we discussed this in the past, but what +exactly does that mean? Does it mean the release train exception process +should be used, with changes announced in advance and require approval +from others? Or, will this be left to the discretion of each project? +Unless we've already covered this, we should probably decide on that +soon. Note, the Eclipse TLP doesn't plan on any contributions after RC4 +at the moment, but I just want to know the process in advance in case +something comes up... + +Decided: + + - + Autobuilds turned off + Exceptions, requests for rebuilds can be made to cross-project-dev + list (no need for Planning Council list). + - + if fairly obvious, dw will trigger the rebuild (hm, can/should + security be changed on that hudson job?) + or if doubt, dw will ask for further review/discussion with PC + or PMC + there is a risk, since our setup depends on individual project + repositories, that someone may "break the build", that is + unrelated to original respin request + - + so all projects need to use care, and make sure nothing + changes during this time + + + + - + Let's review compliance: + - + [Top + Level](http://eclipse.org/helios/planning/SimultaneousReleaseGrid.php) + [Flat + view](http://eclipse.org/helios/planning/SimultaneousReleaseGrid.php?showallprojects=true) + + + + - + Any to kick off the train? + Any gold stars to hand out? + - + Andrew Overholt and the Linux Tools Project is a shining example + of joining the train well\! + +### Maintenance Schedule + +Fourth Friday of September? 9/24/2010 + +Fourth Friday of February? 2/25/2011 + +### Next Year's Schedule + +Not ready to discuss details, but the problems with +1, +2, +3 category +(and short times) should be well discussed. + +Similarly, Oliver brought up issue with need for better "warm-up" +rhythm, especially if a prereq project is late. (EMF's "last minute" M6 +delivery added pressure to TPTP's ability to build/test in time). No +specific actions, process or remedies are known, but ... maybe a +reminder to cross-project list that intermediate or warm-up builds are +good (especially if going to be near deadline). + +### Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +Any issues moving to new b3 Aggregator? + +Should be produce hybrid p2/maven repo? + +## Other business + + - Process for exceptions like "breaking API change after M6" + + + + - + + - + projects making the change should announce on cross-project + the team that discovers it, has a responsibility to report is as + a "breaking API change" (don't just swallow it) + - + it might have been an accident or oversight and can be + repaired for others + even if not (even if it really is required) it is a good way + to document the issue so others know about it. + + + + - Should we have a combined/joint "migration guide" for all Helios + projects? A central jump-off point? + +## ToDo Items + +## Next Meeting + +July 7. Have our yearly "feedback" session. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_03_2009.md b/wiki/Planning_Council/June_03_2009.md new file mode 100644 index 0000000..2050469 --- /dev/null +++ b/wiki/Planning_Council/June_03_2009.md @@ -0,0 +1,256 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, June 03, 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=5&day=6&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| ----------- | +| width="30%" | + +| | | +| ------------------------ | - | +| Chris Aniszczyk | | +| Cedric Brun | Y | +| Oliver Cole | | +| Stefan Daume | Y | +| Brian Fitzpatrick | Y | +| Wayne Beaton | | +| Doug Gaff | Y | +| Neil Hauge | | +| Mika Hoikkala | | +| Anthony Hunter | Y | +| Oisin Hurley | Y | +| Markus Knauer | Y | +| Christian Kurzke | | +| Gary Xue | Y | +| Ed Merks | Y | +| Mike Milinkovich | | +| Philippe Mulet | | +| James Saliba | | +| Georg Schmidt | | +| Kaloyan Raev | R | +| Thomas Watson | Y | +| David Williams | Y | +| Andreas Buchen (SAP/MAT) | Y | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Its official: **Helios** is name of our 2010 Simultaneous Release. + + + + - Please be sure you read and execute + [Galileo/Final_Daze](Galileo/Final_Daze "wikilink"). + + + + - PC Decision on Categories in Discovery Site + + + + - + + - + DSDP Category name change: + [bug 277006](https://bugs.eclipse.org/bugs/show_bug.cgi?id=277006) + + + + - + + - + PC didn't like the exact proposal. Will comment in bug, and + await reply. No reply?\! + Doug to follow up with Martin, but we'll look to move "remote + access" to "tools and goodies" category, so this category can be + more meaningfully named. + + + + - + + - + RAP in Webtools? No bug opened? + - + Markus to followup with RAP team (to have them open a + cross-project bug). + (Markus - 20090604: There is a bug open in "Simultaneous + Release": + [bug 278416](https://bugs.eclipse.org/bugs/show_bug.cgi?id=278416)) + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + + + + - + + - + We should take a position on release or no release. + Judging from items not marked, it appears these are the projects + of worst quality (or, worst adopter readiness?): + These should be 'resolved' one way or the other ... fixed, if + fixed, won't fix and document why not. + + + + - + + - + PDT 15 + CDT 12 + MAT 11 + + + + - + + - + Andreas to work on MAT items bookkeeping + David to contact Roy and Doug + + + + - PC review/approval of exceptions + + + + - + commonj.sdo jar not signed "for technical reasons" + [bug 277331](https://bugs.eclipse.org/bugs/show_bug.cgi?id=277331) + capabilities not defined as PC requested + [but 254130](https://bugs.eclipse.org/bugs/show_bug.cgi?id=254130#c9) + + + + - + + - + no objections + + + + - RC3 update + + + + - + + - + Done yet? + + + + - Proposed Helios Plan Dates: + + + + - + + - + These are rough, quick dates, just taken from last year (and + adjust to closest Friday and similar) + Still need to go through calendar, see if adjustments needed for + Holidays, EclipseCon, etc. + PC Reps should start to discuss these dates with their groups, + and see if they will commit to participating from the beginning + ... from M1\! + + + + - + + - + 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 + M6 3/12 - 3/19 + M7 4/30 - 5/7 + + + + - + + - + Release: 6/30/2010 (last Wednesday of June) + + + + - Next Meeting + + + + - + June 17, Wednesday -- last minute issues? Conduct process + "postmortem". + + + + - + July 1, Wednesday -- no meeting. Celebrate/rest after release. Plus, + holiday week in US. + + + + - + August 5, Wednesday -- Helios\! + + + + - + September 2, Wednesday + + + + - + + - + Upcoming topics + - + Frequency and dates of maintenance builds + Dates for next year's project plans + Build schedule for next year (start with M1) + +## Reference + + - from previous meeting: PC Position on off-cycle releases and use of + discovery site (and EPP)? This came up in discussions about a Pulsar + package. + + + + - + + - + Conclusion: we do not want to support off-cycle releases. But + with following compromise: If a project still met all the normal + "release criteria" set forth as must-do's by PC then they could + introduce something new during SR1 or SR2 (that is SR1 and SR2 + can have more than service, if important, and must-do criteria + met). The reason for not supporting things off cycle was a. it + is more work to support it, b. there is no opportunity for + "simultaneous release" testing, c. it would dilute the meaning + of "simultaneous release". + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") +and +[Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_03_2015.md b/wiki/Planning_Council/June_03_2015.md new file mode 100644 index 0000000..7384859 --- /dev/null +++ b/wiki/Planning_Council/June_03_2015.md @@ -0,0 +1,374 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 3, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (occasional)

Cloud (PMC)

R

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel (Sam Davis)

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Max Andersen? (and Nick Boldt)

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Y

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome ... + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Mars Planning + + - Any issues? + +:\* What happened to "WindowBuilder"? + +## Progress on Action Items + + - Improving user experience in finding right function to install. For + latest ideas, see + + + + - + + \- Create a Marketplace for the simultaneous release. + + "The action that \[Wayne thinks\] we should take is to shut down the + Eclipse Project market and close this bug as WONTFIX." + + + + - Continuing Discussion of if and how to change "yearly release"? + +:\* I have started a ["design" wiki +page](SimRel/ChangingProcessAndTiming "wikilink"), to act as a "design +document", to help centralize the main points we have discussed. + +:\* Notes from the last meeting: + +
+ + - Seemed to be rough agreement that to "release more frequently" would + be good ... for projects and perception. + - Was discussion that "6 per year" too many ... "2 per year" not + enough. So settled on "4 per year" as a working assumption. + +:\* Did not really discuss WHEN they would be (which months), but (I +think) general agreement they should be regular, and predictable. + +:\* Did not really discuss what to call them. We want to convey they are +true releases, but, releases with no subsequent service release. + + - "SR" name especially bad for perception, since it is not really just + "service releases" any more. + - But, even if we had 4 releases per year, some might put in "just + service", some might put in new features, so adds some complexity on + what and how to communicate (with each other, and community). + - We would always (still) need "two streams" going ... one for "next + immediate release", ... another stream for "long term work". (Or, + may vary by project?) + +:\* We did NOT discuss how to manage that ... would "long term work" be +merged into "release" stream at certain points? + + - We would (still) want something like a yearly "LTS Release". + - We did say it would take at least 2 months for us to have a concrete + proposal. + +
+ +:\* Notes from this meeting + +
+ +:\* Need to emphasize (at least to ourselves) that one of goals is to +change perceptions. + +::\* Current perception is that Eclipse is slow moving, with "new +things" only coming out yearly. While this is not technically true, it +is the perception. + +:\* Point made that to call them "one major release" and "3 minor +releases" would be more accurate than "4 releases". + +::\* We would expect at most "minor field" only updates (not major, API +breaking, field changes). + +::\* But new features can still be added. + +::\* And new projects can still join. (Need to codify what's required, +especially in terms of "join early"). + +:\* The minor releases should all be upgradeable from previous. + +::\* Implies some constraints even on "non API" methods continuing to +work, if used by others as if API. + +::\* General agreement that "UI can change" (but, hard to know at the +moment, if there are some limits ... such as impacts to translations, +etc.) + +:\* We may want to codify different rules for the different "categories" +of 0, +1, +2, +3. + +::\* Some doubted we could codify that, but could at least mention "good +will" and "cooperation" between the different levels + +:\* Some wanted new requirement to be upgradeable year to year, as well +as from minor to minor. + +::\* Hard to know, at present, if that is possible, or what new work it +would involve? + +::\* But we should at least understand what it would take, and if there +are inhibitors to doing that, see if they can be addressed. + +:\* The point was made that some projects, even now, have their own +milestone schedule and builds, but skip putting things in Sim. Release +train "until the end" which then causes surprise. + +::\* Was wondered if we could improve our automation to 'detect' when no +changes have been made, in Sim. Release, so then at least there would be +a record of it -- something to open bugs about, or to codify that +projects "must" contribute, if they have changes. + +::\* (This didn't come up, in the abstract, but there was a known case, +I believe Sapphire was mentioned.) + +
+ +## New Business + + - + \* ? + +## Next Meeting + + - Possible meetup during EclipseCon France - see + [PlanningCouncilToulouse](PlanningCouncilToulouse "wikilink"). + + + + - August 5, 2015 - Regular First Wednesday Meeting -- We traditionally + skip July, since a) just released b) Holidays and vacations. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_04_2014.md b/wiki/Planning_Council/June_04_2014.md new file mode 100644 index 0000000..ef735dd --- /dev/null +++ b/wiki/Planning_Council/June_04_2014.md @@ -0,0 +1,281 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 4, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

R

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Reminder: [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + - Be sure to get "docs" into "info center" + +## Previous meeting minutes + + - Review [previous meeting + minutes](May_07_2014.md). + +## Luna Planning + + - + Any issues? + + + + - BIRT's back in (whew). + - Seems to be progress on the com.google.guava issue. Note sure if + "solved" or just "lessened". + - We still need a "Final Daze" document. (shorter?, summary?) + + + + - *As far as everyone knew, we were still "on track" for Luna. Wayne + sent note and contacted projects about "missing legal files".* + +## Mars Planning + + - + Any early issues? + +## Progress on Action Items + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + +## New Business + + - ? + +## Next Meeting + + - No meeting in July (both since popular holiday time, and since will + have "just shipped"). + - August 6, 2014 - Regular First Wednesday Meeting (Our first of + "Mars" cycle) \[still popular holiday time, but we'll do what we + can\]. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_06_2012.md b/wiki/Planning_Council/June_06_2012.md new file mode 100644 index 0000000..34b145f --- /dev/null +++ b/wiki/Planning_Council/June_06_2012.md @@ -0,0 +1,286 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, June 06, 2012, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=06&day=06&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

D (to Tom)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

R

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Juno + + - Ready to release? + + + + - any thoughts on "non greedy" publishers? (Where did we go wrong?\! + :) More seriously, Jetty and ECF have made recent changes to be + "non-greedy" which I think is good but **might** cause some churn. + dw to send out note to cross-project list this afternoon. + + + + - On the topic of "non participating project dependencies" + + + + - + + - + + We have discussed and decided this recently: See + [March_07_2012\#What_to_do_about_Papyrus_.28and_non_released_XWT_dependency.29](Planning_Council/March_07_2012#What_to_do_about_Papyrus_.28and_non_released_XWT_dependency.29.md) + and . The conclusion was: + + A project can not be in the Sim. Release, or Released at all, if +they include things that are unreleased from other projects (and this is +true of any release, not just Sim. Release). + +A project can include releases from other Eclipse projects, even if that +other project is itself not part of the Simultaneous Release. This still +requires the "other project's release" meets all the requirements for +Release and Sim. Release ... signed jars, about.html file, etc. This is +conceptually just like including a third party package from Orbit ... +the original authors do not "participate" in the Release, but the +bundles meet all the release requirements. + +*dw to send note clarifying policy. For future reference: here is the +FAQ about our policies: See +[SimRel/Simultaneous_Release_FAQ\#Policy_FAQs](SimRel/Simultaneous_Release_FAQ#Policy_FAQs "wikilink")* + +### Issues or Exceptions + +#### Any issues? Everyone in? Any exceptions known? + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo approved during 1/05 meeting (from rt PMC list, will be in + M6) + BPEL approved on mailing list (as late for M4, but in M5) + Code Recommenders approved on mailing list (as late for M4, but + in M5). + Koneki project approved on mailing list (as late for M5, but + joining in M6). + Papyrus + Others? + +#### Anyone "dropping out" that should be removed from aggregation build? + + - Assuming, for now, all "legal requirements" can be met? \[In future + years, should we have stricter deadline? e.g. RC2?\] + + + + - ? + +### Other Business + + - \[TODO\] dw to follow up with Andrew to get + [Asterisk](Asterisk "wikilink") bridge for planning council calls. + + + + - John mentioned at end of meeting, for awareness, that current plan + from Eclipse Project is that there will be no 3.9 next year, only + 4.3, for Kepler. + +## Next Meeting + + - We will skip July. + + + + - August 1, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + + + + - + + - + Conduct (or begin) our yearly "debrief" on what went well, what + could be better (finish in September if needed, and in September + begin "planning for Kepler"). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_07_2017.md b/wiki/Planning_Council/June_07_2017.md new file mode 100644 index 0000000..18aa7f5 --- /dev/null +++ b/wiki/Planning_Council/June_07_2017.md @@ -0,0 +1,113 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 07, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Attendees + + - Wayne Beaton (EF) + - Stephan Merker (SAP) + - Michael Barbero (EF) + - Sam Davis (Mylyn) + - Carl Anderson (WTP) + - Tom Watson (IBM) + - Dani Megert (Eclipse) + - Gary Xue (BIRT) + - Alex Kurtakov (Tools) + - Melanie Bats (OBEO) + +### Regrets + + - Alexander Nyssen + - Martin Lippert + - Adrian Mos + +## Agenda + +### Oxygen + +Build seems to be in good shape. + +{Bug|517935} Potential issues. Lucene 5 and 6. Not an issue with the +release per se, but could manifest if somebody tries to add features +(third party) that pull in Lucene 5. + +Eclipse PMC discussed adopting new Jetty version very late. Eclipse PMC +decided not to move to the latest. May adopt in point release. +**Recommendation**, please nobody update Jetty in the simultaneous +release. Recommendation has been made to the community via +cross-project-dev-issues. + +Action Item (Wayne, Fred): put the Oxygen.n dates into the calendar +(https://wiki.eclipse.org/Oxygen/Simultaneous_Release_Plan) + +### Java 9 + +Dani: JPMS JSR was voted down. New vote coming up. + +Java 9 GA will likely move to Sept. 21 (Dani figures that date is 80% +likely). If the second vote on JPMS is “no”, then the next delay will be +longer (at least three months). + +Proposal to move Oxygen.1 to match the Java 9 release date. + +Current proposal to have a switch (on by default) to give warning when +an attempt is made to access internal (or otherwise inaccessible) APIs. + +Eclipse JDT is focused on how the documentation is captured. The EG has +filled many of the holes. + +Oxygen.1 is early September (9th?). Should we move the Oxygen.1 release +to match the Java 9 date? + +**Action** (Wayne): Set up a call with stakeholders (including marketing +team) to sort out what we should do? (see options below). + +Can’t just drop in the Java 9 code and go. Could impact the Java 8 +compiler. We need to test. + +Proposal: On September 21. JDT produces a release candidate build that +includes Java 9. Move the Oxygen.1 release to second week of October. + +No answer today, but we need to have an answer on the next call. + + - Option \#1: Move the Oxygen.1 date + - Option \#2: Add an extra release in October + - Option \#3: Roll out Java 9 with Oxygen.2 in December (with + Marketplace-based rollout in the interim) \ No newline at end of file diff --git a/wiki/Planning_Council/June_08_2016.md b/wiki/Planning_Council/June_08_2016.md new file mode 100644 index 0000000..cc1f7ed --- /dev/null +++ b/wiki/Planning_Council/June_08_2016.md @@ -0,0 +1,393 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 8, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

R

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Y

Alexander Nyssen

itemis AG (Strategic Developer)

Y

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

EPP (appointed)

Y

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Marc Khouzam as the Ericsson representative to Planning + Council. + + + + - Any others? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Dates (and RCs) for Neon.1 (etc.) + + + + - + + - + ''Nick provided proposal on 'discussion page'. **ACTION ITEM** + He will "flush out", especially for M4 and M6 too (and M1 and M3 + and M7 :) -- just no "update releases" with those + ''One "new thing" to announce to Cross-Project list, once + formally established, is that "new projects joining the train + must declare their intent and be in the Sim. Release build by + Checkpoint 1". This would be roughly August 1st, for example, + for the September release." + +## Oxygen Planning + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. + +**ACTION ITEM:** Wayne to discuss with Ian on how best to get more data +from our community of users. + +''This is still a "hot topic", but deferred discussion until hear more +from Wayne on if more "input from community of users" can be expected. + +### old (ongoing) stuff + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In M6 we changed to have (nearly) all features to be "root features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **Impossible now, for Neon. Right? (for EPP Packages) Do we + still need "streamless-URL" now?** I am assuming "no". + + + + - + + - + ***ACTION ITEM** from 6/8 meeting. Doug volunteered to "take up" + this item to better specify "what does it mean" and "what will + it take" to update across major releases. \[Doug, it is up to + you, but I suggest you form a small team of like 3 people, such + as Ian and Dani or, others who know some of the technical + issues, to help if they are able and willing.\] The goal being + just a more specific statement of what it means, and what + projects have to do differently for Oxygen. That is, we don't + need to reach Nirvana in one release cycle.* + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + Preferences, views, etc. have to "migrate" (if their ID + changes). + What testing would projects have to do? + May become "defacto requirement" once is implemented. + - + For Neon we will not have a "streamless" URL, since "won't + work" for upgrading to Neon for the EPP packages. + +## New Business + + - *The [newly proposed download + page](http://staging.eclipse.org/downloads/) was raised as a + potential issue. Technically "not our business, but belongs to the + Eclipse Foundation" but am sure they would like to hear our comments + and views. Comment in .* + + + + - ''Wayne could not make the meeting, but posted a [message to our + mailing + list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02606.html) + about concern over some specific projects -- some of which may have + to be "removed" from the train. But, in addition, expressed concern + over "the process". + + + + - + \- ''I agree and commented on a similar issue on [cross-project + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13122.html) + about two projects who "declared intent", but thought they could + join the build at the last minute. '' + \- *I wondered out loud if it was time for more of a Sim. Release + process where projects had to "prove they were ready to be in the + Sim. Release" instead of us just saying what they needed to do, and + then assume they were doing it. We did not discuss at this meeting, + but, for example, I mean like a checklist (web app) that has to be + updated every milestone? Just an idea.* + +## Next Meeting + + - August 3, 2016 - Regular First Wednesday Meeting -- We always skip + July, since we "just shipped", and due to popular holidays. BUT, + remember, business continues on the mailing list\! + +## Reference + + - + Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + + + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_17_2009.md b/wiki/Planning_Council/June_17_2009.md new file mode 100644 index 0000000..1c2a650 --- /dev/null +++ b/wiki/Planning_Council/June_17_2009.md @@ -0,0 +1,142 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, June 03, 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=5&day=6&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| ----------- | +| width="30%" | + +| | | +| ----------------- | - | +| Chris Aniszczyk | | +| Cedric Brun | | +| Oliver Cole | Y | +| Stefan Daume | Y | +| Brian Fitzpatrick | Y | +| Wayne Beaton | Y | +| Doug Gaff | | +| Neil Hauge | Y | +| Mika Hoikkala | | +| Anthony Hunter | Y | +| Oisin Hurley | | +| Markus Knauer | Y | +| Christian Kurzke | | +| Gary Xue | | +| Ed Merks | | +| Mike Milinkovich | | +| Philippe Mulet | | +| James Saliba | | +| Georg Schmidt | | +| Kaloyan Raev | Y | +| Thomas Watson | Y | +| David Williams | Y | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Please be sure you read and execute + [Galileo/Final_Daze](Galileo/Final_Daze "wikilink"). + + + + - Any release issues? + + + + - Galileo postmortem. + +:\* Good things or accomplishments about this year's process and +release? + +:\* Not so good things. Things to improve. Recommendations to make to +EMO? Things we'd like to do differently or better next year? + +See +[Galileo_postmortem](Planning_Council/Galileo_postmortem.md) +for notes from meeting. + + - Proposed Helios Plan Dates: + + + + - + + - + These are rough, quick dates, just taken from last year (and + adjust to closest Friday and similar) + Still need to go through calendar, see if adjustments needed for + Holidays, EclipseCon, etc. + PC Reps should start to discuss these dates with their groups, + and see if they will commit to participating from the beginning + ... from M1\! + + + + - + + - + 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 + M6 3/12 - 3/19 + M7 4/30 - 5/7 + + + + - + + - + Release: 6/30/2010 (last Wednesday of June) + + + + - Next Meeting + + + + - + July 1, Wednesday -- no meeting. Celebrate/rest after release. Plus, + holiday week in US. + + + + - + August 5, Wednesday -- Helios\! + + + + - + September 2, Wednesday + + + + - + + - + Upcoming topics + - + Frequency and dates of maintenance builds + Dates for next year's project plans + Build schedule for next year (start with M1) + +## Reference + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") +and +[Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_5_2013.md b/wiki/Planning_Council/June_5_2013.md new file mode 100644 index 0000000..8215df1 --- /dev/null +++ b/wiki/Planning_Council/June_5_2013.md @@ -0,0 +1,312 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 05, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

N

John Arthorne D: Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (or Bob Brodt?)

SOA (PMC)

N

Ed Merks

Modeling (PMC)

N

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

N

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker (with Kaloyan)

SAP AG (Strategic Developer)

Y

Igor Fedorenko

Sonatype (Strategic Developer)

N

Markus Knauer

Innoopract (Strategic Developer)

N

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

N

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - : ? + +## Kepler + +### RC3, RC4 left + + - Issues? + + + + - Any danger of missing "minimum requirements" for release to common + repo? + + + + - + See [repository + reports](http://build.eclipse.org/simrel/kepler/reporeports/). + - + Especially, + [missing legal + files](http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt). + [unsigned + content](http://build.eclipse.org/simrel/kepler/reporeports/reports/verifydiroutput/unsigned.txt). + + + + - + + - + *Wayne will review and be sure to send reminders.* + + + + - I will "announce" [Kepler/Final_Daze](Kepler/Final_Daze "wikilink") + on cross project list this afternoon. Feel free to give feedback or + make corrections/additions. + + + + - Critical IP/review dates announced. + + + + - + For details, see [this cross-project post from + Wayne](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08897.html). + In brief, + - + June 5/2013 - PMC-approved Review materials submitted to EMO + June 12/2013 - Kepler Uber Release review + June 26/2013 - Kepler release + + + + - + ''Discussion: '' + - + '' Xtend "moved back" to XText (though, didn't seem to be + communicated). '' + '' DLTK, Hudson, PHP are some projects that don't seem to be + responsive to notes/communication'' + '' Wayne reminded us that even if "old" IP issues have existed + for years, and just now being "caught", they still need to be + addressed.'' + '' Wayne believes that, as in past years, we may need to have an + additional "review date" for some projects that are late getting + done (e.g. June 19th?).'' + +## Next Meeting + + - July -- No meeting in July - we will be relaxing after release + - August 7, 2013 - Regular First Wednesday Meeting ... almost time for + SR1\! + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/June_6_2018.md b/wiki/Planning_Council/June_6_2018.md new file mode 100644 index 0000000..9cb9de8 --- /dev/null +++ b/wiki/Planning_Council/June_6_2018.md @@ -0,0 +1,123 @@ +## Logistics + +**Pay attention time has changed, the meeting is one hour earlier than +before** + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 6, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Photon status + - Post Photon SimRel status + +## Attendance + +Dani Megert, Martin Lippert, Tom Watson, Wayne Beaton, Tom Watson, Alex +Kurtakov, Nick Boldt, Mélanie Bats + +## Notes + +### Photon status + +Everything is okay. Problems with Batik that had to be re-downgraded to +1.6 for several modeling projects (Sirius, Papyrus, Birt...) due t +packaging problems in Orbit. Tips from Wim are no longer shown in a +dialog in the EPPs. + +### 2018-09 status + +Everyone is ok wit the proposed planning: + + +The name issue was again discussed. Only Month-Year will be visible in +the dialog, in the splaschscreen & in the about dialog. + +Wayne will work on the opt-in process for July or August. Handfull +projects are the same years after years, not evolving. Question was +asked by Wayne if we should make a policy for that ? + +Architecture council updates the EDP, early days nothing to report yet. + +More and more re-spins occured during the last milestones. It was +discussed how we should avoid that ? RC should contain only bugs fixes. +How could we enforce that ? Should we provide a policy ? Some projects +are not paying attention leading to late contribution. \ No newline at end of file diff --git a/wiki/Planning_Council/Juno_retrospective.md b/wiki/Planning_Council/Juno_retrospective.md new file mode 100644 index 0000000..bcceac2 --- /dev/null +++ b/wiki/Planning_Council/Juno_retrospective.md @@ -0,0 +1,111 @@ +# Juno Planning Council retrospective + +These notes were collected at the end of the Indigo Release, at 8/1/2011 +Planning Council call, specifically just to collect them. And not to +solve issues, or even necessarily to suggest solutions, but just to +capture issues (good and bad) while the release was still fresh on our +minds. Where solutions are suggested below, it is intended to primarily +better capture the issue discussed .. not to dictate a or pre-judge a +solution. Action plans and solutions will be discussed later. + +## History + +Juno is the seventh simultaneous release, following Callisto, Europa, +Ganymede, Galileo, Helios, Indigo. The Planning Council meets regularly +to come up with plans and requirements. Eclipse Foundation projects can +voluntarily join the simultaneous release. For meeting minutes, see +. + +## Comments from PC during 8/1 meeting + +These rough notes were captured from the "brainstorming" session. We +will refine in future meetings. + +### Positive things mentioned + +(Especially things not mentioned in previous retrospective, such as +predictability; we'll assume all those still true unless otherwise +stated). + + - perceived to be smoother. projects improving with experience. The + phrase "well oiled machine" was used to describe it. + +### Things that could have been better + + - The importance (or no) of "non-greediness" requirement seems little + understood. + + + + - The use of non-train projects by train projects seems + confused/confusing. + + + + - + perhaps have an early "freeze" (say M6?) to be sure no "last minute" + (untested) surprises. + + + + - query2 case ... slipped through cracks. + + + + - + perhaps require or suggest "one release" before joining train + + + + - communication: + + + + - + we currently do not track or have an easy way of knowing which + projects have no one subscribed to cross-project list? + +## Comments from PC meeting during 9/5 meeting + + - ''One issue (I brought up) was that every April or May we start to + see a flurry of note/bugs about how p2 isn't good enough, or is + "hard on the Eclipse infrastructure". Is there no way we can be more + proactive? Do we need a "cross project team"? '' + + + + - ''Ian did a good job of summarizing some of the issues runtime + projects have being in "sim. release" and thought it would be an + ongoing discussion as to "what do they want instead, if anything". + Some points made: '' + + + + - + *p2 repo isn't all that interesting ... runtimes want to be in + "maven central" (or maven.eclipse.org, I would assume)*. + + + + - + ''Some issues were "matter of degree", such as often 10 or 15 "tools + related projects" often must be coordinated (such as "web tools") + but for runtime projects its seldom more than a few, if that many. + '' + + + + - + *One fundamental issue (I think, if I heard right) was that many + runtime clients want to stay on OLD version (even if tools advance) + but OLD version is no longer in "current" repository (so, while + doable ... it takes extra work, and is less "coordinated" to those + users). They could (nearly) as easily use current tools repo, and + individual runtime repos when needed*. + +## Reference + +See also [last year's +retrospective](Indigo_retrospective.md) + +[Juno](Category:Juno "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Kepler_retrospective(1).md b/wiki/Planning_Council/Kepler_retrospective(1).md new file mode 100644 index 0000000..b71f9c2 --- /dev/null +++ b/wiki/Planning_Council/Kepler_retrospective(1).md @@ -0,0 +1,69 @@ +# Kepler Planning Council retrospective + +These notes were collected at the end of the Kepler Release, +specifically just to collect them. And not to solve issues, or even +necessarily to suggest solutions, but just to capture issues (good and +bad) while the release was still fresh on our minds. Where solutions are +suggested below, it is intended to primarily better capture the issue +discussed .. not to dictate a or pre-judge a solution. Action plans and +solutions will be discussed later. + +## History + +Kepler is the eigth simultaneous release, following Callisto, Europa, +Ganymede, Galileo, Helios, Indigo, Juno. The Planning Council meets +regularly to come up with plans and requirements. Eclipse Foundation +projects can voluntarily join the simultaneous release. For meeting +minutes, see . + +## Comments from PC meeting + +These rough notes were captured from the "brainstorming" session. We +will refine in future meetings. + +### Positive things mentioned + + - Nothing specific was named, that wasn't named in previous + retrospectives -- that is, all the positive aspects of participating + and producing still apply. + +### Things that could have been better + + - One issue discussed at at number of meetings was that "disabling + everyone in M1" (in at effort to get positive confirmation of + participation) seemed to cause a lot of extra work for everyone. The + action taken was to get projects to send note to "cross-project" + stating their intent ... so projects will not be disabled unless not + heard from until after M3. + + + + - It was felt the strict rule about "releasing one month" before a + service release was too strict (not enough flexibility, especially + for new projects, making rapid changes and "releasing the tip". + Thus, this policy was loosened a little to have released by RC1 + (technically, to have release materials ready by RC1 and be feature + complete). + + + + - one new concern was brought up: That "release engineering" is not a + very "diverse team" (Markus and David) ... and the concern was "what + do we do if they stop doing it". While no one volunteered to help :) + it was taken as a valid point to document. Briefly discussed + "getting help from Eclipse Foundation", but at same time we wanted + it to remain a "community driven" activity in general ... that is, + those that have a vested interest in producing and consuming the + release should be "in charge" ... and not become a "corporate + activity". But, perhaps there could be some help with tools, and + similar from Eclipse Foundation? Should b3 aggregator or EPP build + become part of "CBI project"? At a minimum, need to make sure some + of the process and mechanics are well documented so others could + "take over" when necessary. + +## Reference + +See also [last year's +retrospective](Juno_retrospective.md) + +[Kepler](Category:Kepler "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Mar_04_2009.md b/wiki/Planning_Council/Mar_04_2009.md new file mode 100644 index 0000000..d655334 --- /dev/null +++ b/wiki/Planning_Council/Mar_04_2009.md @@ -0,0 +1,119 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, Mar 04 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=3&day=4&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| ----------- | +| width="30%" | + +| | | +| -------------------- | - | +| Chris Aniszczyk | Y | +| Cedric Brun | Y | +| Oliver Cole | Y | +| Stefan Daume | Y | +| Brian Fitzpatrick | Y | +| Bjorn Freeman-Benson | ? | +| Doug Gaff | Y | +| John Graham | ? | +| Neil Hauge | Y | +| Mika Hoikkala | ? | +| Anthony Hunter | Y | +| Oisin Hurley | Y | +| Markus Knauer | N | +| Christian Kurzke | ? | +| Wenfeng Li | ? | +| Ed Merks | Y | +| Mike Milinkovich | ? | +| Philippe Mulet | ? | +| James Saliba | ? | +| Georg Schmidt | ? | +| Karsten Schmidt | ? | +| Thomas Watson | Y | +| David Williams | Y | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Build update + + + + - + + - + Currently Riena is breaking .. we assume 'build break' + notification is working + We are currently working toward M6 (we missed M5) + Projects need to remember to "stop" contributing once they + deliver milestone to Galileo, until milestone is declared. + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + + + + - + + - + PMC reps to follow-up: + - + ECF - Tom + EMFT - Ed + EPP - Chris (I will update bugzilla until the weekend - and + I don't see any problems so far (Markus)) + VTP - Chris + + + + - Decide on our EclipseCon meeting + + + + - + + - + Sunday, 2-3, tentative + + + + - Name that train + + + + - + + - + Anthony volunteered to talk to Bjorn, perhaps turn the proposed + "contest" into a poster session + + + + - Need to confirm all of Planning Council is invited to StAC meeting, + Sunday 3-5 + + + + - + + - + Confirmed: Yes. All Planning Council members are considered StAC + members. + +## Reference Links + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) \ No newline at end of file diff --git a/wiki/Planning_Council/Mar_22_2009.md b/wiki/Planning_Council/Mar_22_2009.md new file mode 100644 index 0000000..2f50021 --- /dev/null +++ b/wiki/Planning_Council/Mar_22_2009.md @@ -0,0 +1,189 @@ +## Logistics + +| | | +| -------------- | -------------------------------------------- | +| Meeting Title: | **Planning Council EclipseCon face-to-face** | +| Date & Time: | Sunday, Mar 22 2009, at 2:00 Pacific time | +| Location: | Bayshore Room at the Hyatt | +| Dial-in: | \[no dial in planned\] | + +## Attendees + + - + David Williams, Chair (and WTP) + Brian Fitzpatrick DTP + Wenfeng Li - BIRT + Anthony Hunter, Tools + Markus Knauer, EclipseSource + Chris Aniszczyk, Technology + Oliver Cole, TPTP (half of meeting) + Tom Watson, RT, Equinox + Doug Schaefer, CDT, Tools (Ad Hoc), + +#### Regrets + + - + Oisin Hurley, Stp PMC + Neil Hague, Oracle + +#### Did not hear from + + - + Stefan Daume Cloudsmith Inc. Strategic Developer + A. Doug Gaff Dsdp PMC + John Graham Red Hat, Inc. appointed + Mika Hoikkala Nokia Strategic Developer + Christian Kurzke Motorola Strategic Developer + Philippe Mulet Eclipse PMC + James Saliba CA Inc. Strategic Developer + Georg Schmidt brox IT-Solutions GmbH Strategic Developer + Karsten Schmidt SAP AG Strategic Developer + + + + - Action: need to contact (some of the) above to see if still accurate + +## Topics + + - Build update - M6 complete (or completing?) + + + + - - 'All except STP (as indicated in the bug) and Rienna are + installing locally. I can do a full rebuild to get JWT and + Buckminster in a build and try to promote it, but I expect we + won't want to declare an M6 until we get the \[SDKprofile bug, + bug 269468,\] resolved.' + + + + - - Later in week, declared with the working subset and work + continues trying to fix build/others. + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + - - VTP was obvious outlier (having marked nothing). Chris + followed up with them, and later in week communicated they + no longer plan to be part of Galileo. Need to update + "intent" bug. + - Anthony to check with M2M (required for GMF, but he'll help + them get current) and other Modeling Projects. + + - Revisit [branding + naming on the about + dialog](https://bugs.eclipse.org/bugs/show_bug.cgi?id=252813), + we require clear conventions. + + - Spelled out basic rules. ACTION: need to update + bug/communicate to list. Provider name should always start + with "Eclipse ..." followed by project name. It is (still) + up to each PMC to decide how best to describe their project + in a meaningful, balanced fashion (either as one top level + one or as multiple pieces). Avoid special symbols (e.g. ':' + or "-") unless they are part of the project name. Avoid + acronyms (unless in common use in software industry, such as + XML, or PHP). Capitalization should follow "headline-sytyle + capitalization": The only words that are not capitalized are + articles (except as the first word), coordinating + conjunctions (for example, and, but, and or), prepositions + (except as the first or last word), and the to in an + infinitive. ) + - For now, only the branding/primary feature is important to + get right. Long term, all plugins and features should use + the correct "Provider Name", same as that branding + plugin/feature, but we do not encourage a lot of last minute + touching of plugins just to fix the provider name. It can be + phased in when other changes are made to those plugins, if + desired. + + + + - Name that train + + + + - + + - + Anthony volunteered to talk to Bjorn, perhaps turn the proposed + "contest" into a poster session + + + + - - No Poster session. Concluded that we'd make alphabetical list of + remaining moons. ACTION: make such a list to see if any should + be ruled out (such as Io). + + + + - - The question was raised of how future trains interacted with e4. + By show of hands, no other project was currently planning an e4 + specific release. So will be an issue at some point in future, + but not likely to be in 2010. + + + + - Markus + [suggested](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01562.html) + we discuss what platforms to support in EPP packages. + + + + - - PC concluded it was desirable to add Windows 64 bit, but Markus + could not commit. Issues are that people need to be lined up + that have the machines and time to test. Also, not all packages + can be available on all platforms (e.g. CDT). + + + + - Discuss alternatives to uber-site: still desired? feasible? + alternatives for backup plan? tighter integration with epp packages? + + + + - - Did not have time to discuss in detail + + + + - Let's decide Galileo Service Releases - proposed: + - 9/25/09 (last Friday of September) + - 2/26/10 (last Friday of February) + + + + - - Approved these dates: need to announce + + + + - While we are face-to-face, let's get started on next year's release + by discussing the general process. Please come prepared to represent + your PMC or strategic member on things they like about the + simultaneous release process and things they do not like. \[For + those who can not attend this face-to-face, you can send me a short + list and I'll present them\]. + + + + - - Did not have time to discuss in detail + + + + - Next Planning Council Meeting: 4/1 (First Wednesday of every month) + - Next Face-to-face: Eclipse World, October 2009? Eclipse Summit, + October 2009? + + + + - Related activities/meetings + - StAC meeting to follow, Sunday 3-5 (all councils are invited ... + and in fact considered members). + - Architecture Council after that, 5-6 + +## Reference Links + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) \ No newline at end of file diff --git a/wiki/Planning_Council/March_01_2017.md b/wiki/Planning_Council/March_01_2017.md new file mode 100644 index 0000000..4ea1523 --- /dev/null +++ b/wiki/Planning_Council/March_01_2017.md @@ -0,0 +1,220 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Mar 01, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + +### Eclipse Foundation + + - Wayne Beaton, interim chair Y + - Frederic Gurr Y + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) Y + - IBM (Thomas Watson) Y + - itemis AG (Alexander Nyssen) R + - OBEO (Melanie Bats) Y + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) Y + - Robert Bosch GmbH + - SAP SE (Stephan Merker) Y + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) Y + - Eclipse Project PMC (Dani Megert) R + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) Y + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Doug Schaefer) R + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) Y + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - What's missing from Every Detail Matters for Oxygen? + [Bug 505921](https://bugs.eclipse.org/bugs/show_bug.cgi?id=505921) + - Oxygen+1 will be named *Photon* + [Bug 511933](https://bugs.eclipse.org/bugs/show_bug.cgi?id=511933) + - Oxygen Java release: do we really need to release in June and July? + - Confirm dates for Oxygen service releases and Photon + (Oxygen+1). + See + + for the current proposed dates (please disregard the "Oxygen JDK + Update Friday, 08/04" entry). + - Java 9 JDeps: checking for the use of internal APIs + - Java 9 Compatibility statements (will it run?/will it support Java 9 + Features?) + - Marketing potential: Java 9 features + - JUnit 5 not included in Oxygen.0? + [Bug 488566](https://bugs.eclipse.org/bugs/show_bug.cgi?id=488566#c11) + +## Notes + +We're going to ask project teams to make some statements with regard to +their support of Java 9. We'll assume negative responses for those +projects that do not answer. + + - The project code runs on Java 9; the project code makes no use of + Java internals. + - The project code leverages or highlights specific Java 9 features + (e.g. JDT compiles Java 9 code) + +Dani's team has run a tool based on JDeps on the simultaneous release +repository and the results have been generally positive. JDeps is a tool +provided by the Java 9 team to test Java code for the use of internals. +Wayne: as I recall, all of the Eclipse project code was clear, some +problems were found in some third-party libraries. + +Dani will provide more information when he returns from vacation. + +Tom pointed out that in his experience the JDeps tool doesn't identify +the use of reflection to access internals. Don't assume that positive +output from JDeps means that your code is good-to-go on Java 9. Thorough +testing is still required. + +The Eclipse JDT team has decided to pull out support for JUnit 5 because +the official release date for JUnit 5 isn't until November. Wayne asked +whether or not the Eclipse Planning Council agrees philosophically that +our releases can only use released third-party content, and and more +specifically if the Eclipse Planning Council should make a statement +encouraging the Eclipse JDT project to include the content regardless. + +The Eclipse IP Policy does not require that third-party content be +released to be included in a release. There is no process limitation on +including a pre-release version of JUnit 5 with the Oxygen.0 release. + +The danger is that our users will want to use the latest-and-greatest +version of JUnit 5 when it is available, but we have no idea whether or +not that will break our implementation. If we include JUnit 5 support +with Oxygen.0, we'll get another chance to update with Oxygen.1 in +September before the anticipated November release. What if there is +drift between those dates? + +Wayne encouraged the Eclipse Planning Council to think about the end +users. Do end users expect to have JUnit 5 support in the Oxygen.0 +release regardless of the release state? + +Much of the rest of the conversation focused on whether or not it makes +sense to skip the June date and just move Oxygen.0 to coincide with the +official Java 9 release on July 27/2017. + +Wayne again invited the Eclipse Planning Council to think about users. +If we do our usual big marketing push around a June release that does +not include Java 9, we're going to lose some users and likely invite +negative feedback from the community. + +Carl expressed that the Eclipse Web Tools PMC prefers to have the usual +June release on the basis that Java 9 release may introduce instability. +Further, there is some risk that the Java 9 release date will slip. By +pushing out the Oxygen.0 release in June as planned, we will have our +stable release and we can then play with the Java 9 support date as +needed. + +Other thoughts + + - We need to make it easier on consumers + - For Java 8 we "lived with a beta patch for a while" + - The sooner we support Java 9 the better + - We're inviting negativity and risk losing users if we don't make + getting Java 9 super easy. + - Releasing in June because we've always released in June isn't a good + enough reason. + - Does releasing in June and then again in July make us look goofy? + - The extra release will consume resources. Do we really want to + duplicate that effort? + +The status quo was not changed on the call. There is ongoing discussion +on the mailing list. Let's see how it plays out there. + +Open question: why can't we ship Java 9 support with Oxygen.0 in June? +If we can ship beta support for Java 9 from the Eclipse Marketplace, why +can't we include it in packages? Is there a legal limitation? + +Equinox intends to have a patch applied for the Oxygen.0 release which +will make the launcher work without customization on Java 9 (the +--add-modules option needs to be included). Tom explained that the +primary technical limitation is that the option causes most (older) Java +VMs to fail. Short version: OpenJDK Java 8 JVMs can be configured to +ignore options that they don't recognize; IBM JVMs don't have this +ability; and older versions of Java will just fail. + +Fred has proposed some dates for Oxygen update releases and Photon. Fred +has invited feedback on the mailing list, but has not received many +responses. *Please respond by March 8/2017 if you have any concerns.* In +the absense of feedback, we'll assume lazy consensus and make the dates +official. + +On the topic of dates, the CQ deadline for Oxygen has passed. If you +have third-party content that requires review, contact the EMO IP Team +ASAP. \ No newline at end of file diff --git a/wiki/Planning_Council/March_02_2011.md b/wiki/Planning_Council/March_02_2011.md new file mode 100644 index 0000000..1a70b7b --- /dev/null +++ b/wiki/Planning_Council/March_02_2011.md @@ -0,0 +1,365 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, March 02, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=03&day=02&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

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)

Neil Hauge

Oracle (Strategic Developer)

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

R

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - ? + +## Maintenance Schedule + +### Helios SR2 + +Congratulations\! + +\- eclipse.ini missing after Helios SR2 upgrade; fails to launch + +*Please comment in bug, soon, if thoughts on which option. Leaning +towards Option 2 (hand edit) as being the least risky* + +*No definitive explanation, yet, as to what happened to cause this +change in case.* + +Retrospective? + + - + Too many typos\! + +## Indigo Status + + - M6 (and EclipseCon\!) coming up ... any issues? + + + + - any exceptions to discuss? + + + + - + RTP (see [Chris's + request](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01872.html)) + (approved via mailing list, no discussion at meeting) + Libra: (see [Kaloyan's + request](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01885.html)) + (approved, Markus and Chris supporting explicitly, after brief + overview by Kaloyan). + +## Indigo Plan and Schedule + + - ongoing reminder to aggregate project tracking, IP logs, docuware, + etc., and [update project + meta-data](Development_Resources/HOWTO/Project_Meta-Data "wikilink") + as Wayne requested in [cross-project + note](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05063.html). + + + + - recently [announced EMO dates for Indigo + release](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01860.html): + (I have added these to our [Planning + Calendar](https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&ctz=America/New_York&gsessionid=OK) + for convenience). + +`February 11, 2011 - Last day to enter CQs for Indigo projects` +`May 18, 2011 - Please submit your IP Logs` +`June 1, 2011 - Review documentation submitted to EMO for release review` +`June 1-8, 2011 - Review period.` + +## Other business + + - Name that release. Indigo+1. + + + + - + + - + Progress? (Pascal) + +*Pascal not at meeting. About time to have online vote?* + +## ToDo Items + + - How is the RoadMap coming along? (Wayne) + + + + - + + - + *Progress, but slow. Wayne still working with individual + projects that have not provided one (and maybe didn't even know + they needed one ... so, sounds like some PMC/mentoring guidance + needed?).* + + + + - + + - + *Wayne would like to "extend" the meaning and use of some fields + in project meta-data so there projects could summarize their + release, etc., instead of sending email or making part of + docuware*. More could be automated then. Overall summaries + provided, etc. Wayne will (likely) send note to cross-project + soon with this request.'' + + + + - New [project release tools](http://www.eclipse.org/projects/tools/). + Some ready. Some near ready? (Wayne) + + + + - + + - + ''Sounds like Wayne's made some excellent tools to ease and + improve the quality of the process. He'll be posting more notes + soon (approximately Friday). '' + + + + - Please encourage your projects to add links to "central" Indigo wiki + for [New and Noteworthy](Indigo/New_and_Noteworthy "wikilink") and + [Migration Guides](Indigo/Migration_Guides "wikilink"). + + + + - + + - + TODO: Platform needs to have their own central page, like WTP + does ... or, update this wiki every milestone. It currently + points to M4 N\&N. + + + + - TODO (from previous meeting): dw to add/create add a FAQ item around + "what to handle 3.7 vs. 4.1". Will draw from previous [working + notes](Indigo/HowToAddress37And41Platform "wikilink"). + +## Next Meeting + + - EclipseCon Meetings: Sunday, March 20, At Hyatt, Napa Room. + + + + - + + - + 3-4 (Pacific Time) [Planning Council face-to-face + meeting](March_20_2011.md) + 4-5 (Pacific Time) Joint Councils Meeting (See [Donald's note to + list](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01858.html)). + + + + - April 6, 2011 (regular "first Wednesday" meeting). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](indigo "wikilink") + + + + - + [Helios_retrospective](Planning_Council/Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_02_2016.md b/wiki/Planning_Council/March_02_2016.md new file mode 100644 index 0000000..887d7af --- /dev/null +++ b/wiki/Planning_Council/March_02_2016.md @@ -0,0 +1,552 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, February 3, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Alexander Nyssen

Itemis

Y

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Martin Lippert as new Planning Council member representing + Cloud PMC + + + + - Don't forget about EclipseCon face-to-face on Thursday, March 10. + Time? + + + + - + Wayne to arrange "google talk" connection? + - + *It was thought to be at 10:30 on Thursday. "After keynote".* + *Look for note from Wayne if there will be a "Google Hangout" + opened.* + + + + - Any others? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Mars Planning + + - Mars.2 issues? + - Tracking participation in minor releases + +## Mars "left over" topics + + - Requirement to use "latest Orbit" (or other pre-reqs) even in + Maintenance releases + + + + - + + - + Turns out, some projects "do not rebuild, ever, for + "maintenance" so they do not use the latest Orbit. + Is it too much to \*require\* that they rebuild to "pick up" new + prereqs? See bug for why this is important. (Ideally, "new + builds" with "new prereqs" would be easy to do. But, guess not + always, if not used to branches, I assume.) + + + + - + + - + *Alex promoted the proposal he wrote about on cross-project + list. I will need to re-read that, and respond there. We + discussed a fair amount with no resolution so will track as an + on-going item.* + + + + - The composite .../releases/mars contains "contradictory" information + with respect to some platform filters. See . That is, each + repository is internally consistent, but not when "combined". As far + as I know, this particular case would never impact end-users. + Assuming that is true, I see no reason to do more to that Sim Rel + repository. + + + + - + + - + But, would have been nice to detect earlier. The b3 aggregator + might help for the general case, but do not think it would have + in this case. That "noenv" filter is a Tycho or e(fx)clipse + specific "trick". + *This specific issue is turning out to be a smaller issue than I + original thought. But, in future, should emphasize that "test + early, test often" also means to \*build against\* the latest + deliverables from projects.* + +## Neon Planning (and beyond) + +### new business + + - Discuss and vote on CFT being in Neon "late" (See [mailing list + post](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02573.html)). + + + + - + + - + *This request was approved as an exception for M6. If the + project is not in aggregation build for M6, they will need to + request an exception (again) for M7. Forgot to mention in the + meeting, but the project should still create a release record + and announce on cross-project list.* + + + + - I also expected "emf-facets" to request an exception -- but have not + seen it yet. They "announced early" (before M4) but have not yet + been in a build. In some bugs and email I requested they "follow the + Exception process". + + + + - EPP will create M6 with most features being root features. Deserves + some good testing. (But I am not sure of the best way to do that). + + + + - I have proposed and in the process of, moving "Sim Release Tests" to + CBI -- the main goal being to encourage individual projects to do + more of that same testing during their own builds. + + + + - I have proposed and in the process of, moving "b3 aggregator" to + CBI. Here the goal is mostly to improve its long-term support. + +### old (ongoing) stuff + + - Should we change "maintenance" staging name now? for Mars.2? See . + + + + - + \- \[See also for unreleated additional URL.\] + + + + - + + - + \- Still "todo" item. (i.e. not done yet, apologies for delay) + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + One proposal: have all features in EPP packages be "root features" + and establish a procedure of adding new code to the Sim. Release + repository "at any time" (or, say, once per month?) -- say for "hot + fixes" only ... say after review/approval by Planning Council? + AND, to avoid "contamination" of update site lists (without the user + being in charge of it) change p2 install/update to not allow the + addition of reference repositories during feature installs. But, it + has been stated, adopters still want that ability ... so, not sure + how "we" could ever know the difference. + - + Perhaps could solve with a "product preference" so EPP could + "set" the preference one way, and adopters creating products + could set it another way? Or, direct users to do so? + - + Easy for me to say "change p2" :) but ... who would do the + work? + Perhaps solve simply with a "policy" of "do not add reference + repositories" (with feature installs)? + - + But without some way to enforce it, I think some projects + still would. + This "reference repositories issue" was a discussed as a concern + at Architecture Council + - + Apparently there have been cases of users getting "mixed" + installs because reference repositories are sometimes very + broad. \[I hope I've captured the issue correctly, I was not + there, so please correct if I read it wrong.\] + Does Oomph solve this problem at all? Does it have a possible + solution? + - + From [Ed's note to ide-dev + list](https://dev.eclipse.org/mhonarc/lists/ide-dev/msg01043.html), + it sounds like it solves the issue of updating non-root features + (as long as they are "in the repository"?). + + + + - + *We had a constructive discussion about this issue, even if not + complete agreement. We, at least, have some items to investigate.* + - + \- *Markus will propose to EPP packages that they (or, he) begin + building EPP packages with their "main features" in EPP products + as "root features". Thus, if we updated the Sim. Release repo, + users would get a "fix" via "check for update". Note: I believe + projects would have to come out with a new "release" of the + features -- that is "patch features" would not automatically be + found -- I THINK. Another implication is that "check for + updates" would take longer, I believe, since more features to + "fetch" to see if they have changed.* + \- *With the above root features in place, it would be easier to + do an off-schedule re-build of the Sim. Release repository -- + with just the "changed features" being used as input. We would + not rebuild the packages, just the repository. This should + minimize the amount of work required from other projects.* + \- *The issue for which there was still disagreement is how to + manage these off-schedule changes. I think there are basically + three proposals, and we agreed that by next meeting we would + list "pros and cons" of each:* + - + \* *A. Status quo: even if not a recommended practice, + projects can add "reference repositories" when their feature + is installed, so their users can get easy updates when ever + and what ever the project desires. No Planning Council + involvement.* + \* *B. Provide a "built-in" URL, disabled by default, that + would point to a composite repo named something like + "hotfixes" or simply "fixes" or perhaps even "extras" -- + depending on the policy that was adopted. The argument being + that then at least "what projects do there" is a little more + visible. Minimal Planning Council involvement.* + \* *C. Provide a process, and make it easier, for projects + to contribute off-schedule "service" and re-spin the Sim. + Release repository. This would likely be a special + repository, where only the "changed bits" would be included, + and the rest point to the previous, unchanged repository (a + "trusted repository" in b3 aggregator terminology). The + Planning Council would briefly review these "requests for + off-schedule builds" primarily to make sure they were + "blocking" or "critical" bugs, and perhaps to briefly assess + if there was any chance of impacting other projects. i.e. a + change in a "leaf" project or a "leaf" function would be + pretty easy to "approve", but if someone wanted to make a + big change to the way "jobs" worked, then it would take more + review and/or testing (if allowed at all).* + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + What testing would projects have to do? + May become "defacto requirement" once is implemented. + + + + - + *Seemed to be no objection to "trying it" and with Neon we will "try + it" by having the "streamless-URL" proposed in . For Neon, we will + not use that URL automatically anywhere but users can add it if they + would like. Will be interesting to see if many bug reports occur + from people trying that "update to next main release" (that is, from + Mars to Neon).* + +## Oxygen Planning + + - ? + +## EclipseCon Face-to-face + + - Joint meeting with Arch. Council. + - Participate on + [EclipseCon2016/Councils_Face-to-Face](EclipseCon2016/Councils_Face-to-Face "wikilink"). + - ~~Suggest times on [doodle + poll](http://doodle.com/poll/7xphrzbeis678d5n).~~ Thursday, March 10 + +## New Business + + - Nick suggested moving b3 editor to Gerrit to facilitate + contributions and evolution of b3 + + + + - + David vetoed that change as being "not worth it (at this point in + time)" according to him. + + + + - Great Fixes for Neon + + + + - + *Wayne outlined his proposal for "great fixes" for Neon. It is + desired the winners (3 or so per milestone) be announced + concurrently with M6 and M7. He believes he can automate, via Git, + the task of finding non-committers who have made a lot of + contributions to one or more projects at Eclipse, for Neon. He would + like to identify about 10 candidates, and then have Architecture and + Planning Council members vote on who had the "most impact". There + was no disagreement with this approach, and the PC members thought + they would have time to participate. Details remain to be worked + out.* + +## Next Meeting + + - EclispeCon face-to-face + - April 6, 2016 - Regular First Wednesday Meeting + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_03_2010.md b/wiki/Planning_Council/March_03_2010.md new file mode 100644 index 0000000..4e976b5 --- /dev/null +++ b/wiki/Planning_Council/March_03_2010.md @@ -0,0 +1,478 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, March 03, 2010, at [1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=03&day=3&hour=17&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

R

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

Y

Doug Gaff ???

Dsdp (PMC)


+

Anthony Hunter

Tools (PMC)

Y

Oisin Hurley

Stp (PMC)

R

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

 

+

Appointed

+ + + + + + + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

 

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 + +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 + + + + - + 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 ...//repository//\[SRn | + datetimestamp\]/ + ... naming in feature URL would be (only) + ...//repository// + - + 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). + + + + - 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](Cross_Project_Teams/Aggregation.md) + +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 . + +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 + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + +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 +Simultaneous +Release, 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 +requirements +for the Simultaneous Release. Questions on how to complete the form +can be asked on the +cross-project +list. Suggestions for improving the form or process (or +cross-project bugs) can be opened on the +cross-project +bugs component. Bugs on this form itself can be opened on the +Foundation +Portal component. + +## ToDo Items + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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](April_07_2010.md), + Noon Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_04_2015.md b/wiki/Planning_Council/March_04_2015.md new file mode 100644 index 0000000..4e76baa --- /dev/null +++ b/wiki/Planning_Council/March_04_2015.md @@ -0,0 +1,347 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, March 4, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

R

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

R

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - \- Naming Mars+1 (2016 Eclipse Simultaneous Release) + + - 'Neptune' and 'Nova' and 'Neo' are dead in the water due to + trademarks; Took a new poll of remaining "N-words". + + + + - + *Decision was made to "start over", on accelerated cycle, expanding + "letters" to "O and P" in addition to "N", and then having voting at + "EclipseCon".* + + + + - + ''We would try to "vet" the names a little better ourselves ... at + least a web-search to see if the name of any other "software + product". + + + + - + *Will also including asking community about using "numbers". Seemed + the consensus of Planning Council was to use "Year" such as "16" for + "2016 June Release" (as a "backup plan") but wasn't that clear on + what to do with "Service Releases" ... especially since they are not + strictly "Service Releases" as they used to be. One alternative was + to use "year and month", such as 16.6, 16.9, but that would make the + second "service release" be 17.2 (which, sounds confusing, since + sounded like a "major release") so, presumably, if we go the + "numbered route", we'd stick with "16" (for 16.0) and then 16.1, + 16.2, etc.* + + + + - + *The notion of using "years of Eclipse" or "years of Simultaneous + Release" (especially the former) was thought to be confusing since + could be confused with "year", such as 2016 will be release "15" of + Eclipse (which started in 2001).* + + + + - + *There was concern expressed (by me :) for full disclosure) about + continuing 'the naming process' as we do, since by definition it + gravitates towards "popular names" which are the ones most likely to + lead to "legal issues". (So, IMHO, we need to be prepared to change + the process? Or, use a numbering system?)* + + + + - + *Was also suggested to get more guidance from "lawyers", but in the + end, does not seem they could give that much guidance, at least in + an economical way.* + + + + - + *An interesting observation was made that going "the numbered route" + sounded more "product-like" than the clever "code names" which + sounds more "open source community like" ... but, admittedly, that's + not necessarily a bad thing.* + + + + - EclipseCon Breakfast: Please RSVP to Wayne. (See his [message on + Planning Council + List](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02362.html)). + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Luna SR2 + + - Congratulations\! + - Any thing to document in retrospect? + +## Mars Planning + + - Any issues? + - Improving categories in Simultaneous Release repo? See + [SimRel/Feature Categories](SimRel/Feature_Categories "wikilink") -- + Wayne? Have a proposal yet? + + + + - + *Wayne reports that focus will likely change on an improved + presentation of "Eclipse Projects" in the "Market Place Client".* + + + + - Moving "Sim Release Aggregation" to "HIPP Instance". (I hope in time + for M6) (dw) + + + + - + \- Besides being "HIPP" jobs will be restructured to have a + "validation-only job", a "build with cache" job, and (still) a + "clean build") job. + +## Progress on Action Items + + - Improve "aggregator examples/doc". (dw -- in progress). + +## New Business + + - ''Wayne reminded us of the ["greatfix + competition"](https://www.eclipse.org/projects/greatfix/) and asked + for help "spreading the word". + +## Next Meeting + + - April 1, 2015 - No Fooling\! Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_05_2014.md b/wiki/Planning_Council/March_05_2014.md new file mode 100644 index 0000000..8b2eaad --- /dev/null +++ b/wiki/Planning_Council/March_05_2014.md @@ -0,0 +1,299 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, March 5, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

R

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

D (Gunnar Wagenknecht)

Brian Payton

Datatools (PMC)

R

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

R

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Reminder: [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + +## Kepler SR2 + + - Any issues? + + + + - + There is one known, mysterious p2-update issue (discovered after + 'release'): + - + I am surprised not hearing more complaints from users? (but, + does seem "intermittent", somehow). + I am surprised not many projects, apparently, tested "update" on + Windows? + Anyone hearing things questions/answers on newsgroups, etc.? Is + that how "work around" is known? + +## Luna Planning + + - M6 is soon\! + - Plan for EclipseCon meeting (to be chaired by Ian)? + +## Progress on Action Items + + - Luna+1 name: 'Mars' came back as "ok". + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + +## New Business + + - Not "direct" Planning Council business, but Wayne asked us, as + Eclipse Leaders, to look at two bugs: + +:\* Eclipse flagged as malware in Chrome + +:: Can anyone reproduce? See similar things? + +:\* No easy access to Eclipse version number/release name for bug +tracker + + - + + - + In general, Wayne's concern was that it's "too hard" for users + to report bugs ... to pick from the scores of projects and + hundreds of components, and feared some get "ignored" if in + wrong place. One member pointed out its even hard for committers + to know where to route\! One suggestion was made that as a best + practice, if a project gets a bug that "they don't know where it + goes" that they move it to cross-project component, asking if + anyone knows where it should go. The idea being that many (but + not all) projects have people subscribed to cross-project + component in-box. + +## Next Meeting + + - EclipseCon "face-to-face" on Sunday (thanks Ian\!) and "joint + meeting" (Wayne did say he'd chair that one). + - April 2, 2014 - Regular First Wednesday Meeting + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_06_2013.md b/wiki/Planning_Council/March_06_2013.md new file mode 100644 index 0000000..9aed7da --- /dev/null +++ b/wiki/Planning_Council/March_06_2013.md @@ -0,0 +1,353 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, March 06, 2013, at 1300 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Achim Loerke (Markus Tiede)

BREDEX (Strategic Developer)

D

[no name]

Google (Strategic Developer)

X

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Juno SR2 + + - Any post-release feedback? (Or, too early yet?) + + + + - Our current policy statement on "new releases" joining a SR + maintenance release is in our [Policy + FAQs](SimRel/Simultaneous_Release_FAQ#Policy_FAQs "wikilink"). + Eventually that's the part we'll want to "tighten up". Must balance + flexibility (agility) with stability. Perhaps something similar to + "The new release must be in RC1 builds for the SR, must have + released one month prior to that RC1, and must be willing/able to + test and provide a quick maintenance release if last minute problems + found." + + + + - + *We didn't want to make a decision at this meeting, since wanted to + be sure we were considering the "big picture" and not reacting to + one case, but came up with the following items:* + + + + - + + - + *Seemed reasonable to everyone that, if we keep our current + policy, "minor updates must be in fully in by RC1" or else too + late to join.* + *Should we even allow minor updates at all? What do adopters + expect/want from SR releases? Pure maintenance, or new features + too?* + *We don't say so, but "no major changes allowed" seems + reasonable. That is, no API breaking changes. Sometime, "version + ranges", even minor, in theory could be a "breaking change" + (though, not exactly API).* + *Should whether or not in EPP packages be part of one of the + factors? Seems that's where most stability is + important/expected, since those users don't have a "choice" to + move up to a particular version, they get it automatically.* + *As an aside, even Mylyn no longer does minor updates in SRs ... + they've stabilized enough not to need it, and recognize they are + a core piece of several EPP packages, so more important to be + stable.* + +## Kepler + +### M6 + + - Issues? + + + + - + *None stated.* + + + + - Are people "building against" the Platform's Maven/Tycho builds? + + + + - + *No one said "yes". Should send reminder (near time to put warm up + in staging).* + +## EclipseCon face-to-face + + - + Sunday, 2 to 4, following by "joint meeting" with Arch. Council, + from 4 to 5. + + + + - Agenda topics? (Please list ideas, so we know ahead of time what's + desired). + + + + - + *Several good ideas were mentioned.* + - + *Decide SR Policy.* + *Should Rt have their own "repo"? Their own Sim Rel Rules? How + can the value to them be increased?* + *What relationship is there (should there be) between OSGi/p2 + common repo and Maven/Maven Repos?* + + + + - Who is planning to attend? (Please fill in with "yes" (Y), "no" (N), + "indefinite" (I), the later being you haven't decided yet, or + depends on tight plane schedule being on time, etc.). + + + +| | | +| ------------------------- | ---------------------------------------------------------------- | +| Representative (Delegate) | Y/N/I | +| Chris Aniszczyk | | +| John Arthorne | Yes | +| Steffen Pingel | No (not attending EclipseCon and Mik is not available on Sunday) | +| Brian Payton | | +| Doug Schaefer | | +| Adrian Mos | No (flight schedule) | +| Ed Merks | | +| Ian Bull | Yes | +| David Williams | | +| Gary Xue | | +| Wayne Beaton | Yes | +| Cedric Brun | I | +| Neil Hauge | Y | +| Kaloyan Raev | No (not attending EclipseCon) | +| Igor Fedorenko | | +| Markus Knauer | Y | +| Achim Loerke | Y | +| \[Google\] | | +| \[CA Inc.\] | | + +## Next Meeting + + - March 24, 2013 - EclipseCon face-face, Sunday 2 to 4 PM (local time) + - April 3, 2013 + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_07_2012.md b/wiki/Planning_Council/March_07_2012.md new file mode 100644 index 0000000..a149c4e --- /dev/null +++ b/wiki/Planning_Council/March_07_2012.md @@ -0,0 +1,646 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, March 07, 2012, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=03&day=07&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Mik Kersten

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Igor Fedorenko as new Sonatype Strategic Developer + Representative. + - Any others? + +## Indigo SR2 + + - Success? Feedback? + + + + - + *None discussed (but, send note to mailing list, etc., if anything + occurs to you later*. + + + + - Issue to discuss and decide if we need a plan of action: p2 content + metadata at SR2 is 3 times what it is at SR0. + + + + - + + - + Should our common "release repo" contain only the latest code? + And "move" older stuff to different site? The different site + would be named something like .../releases/juno/complete or or + something, and be simply a different composite (no duplication + of actual artifacts). This site would not be "built in" to any + update repo lists, but could be used by builds or others that + needed "the old stuff". I think if someone updated, and then + wanted to revert or rollback the change, they might also have to + manually add the ".../releases/juno/complete" URL to their list + of sites (assuming p2 GC had cleaned off the old stuff. Please + read the [msg chain on p2-dev + list](http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04680.html). + There is a trade off of function and performance and want to be + sure everyone is aware of it and if anyone has any opinions on + if we currently have the right choice. + + + + - + + - + Another solution might be to aggregate new stuff, with old, + which would have added advantage of making sure all was + compatible ... but, a) not sure it would be much smaller and b) + requires all projects to do an "expert job" of versioning. + + + + - + + - + *No strong view to change, so normally status quo would rule. + But, we did discuss it is a little hard for us to know magnitude + of problem, and if it'd be worth trading off the current + function, so, a bug might be worth opening, and see if some + "world wide" data was worth collecting. To us, at meeting, + there's a big difference if its 90 seconds for most people and + the would improve to 30 seconds. Versus 15 minutes for most of + world, thus reducing to 5 minutes. Concern was also expressed + that it may be an inherent problem/limitation with p2 and this + "fix" would be sort of "temporary" ... that if future repos grew + to three times current size, we'd be in the same "poor + performance" category, unless p2 was improved or some other + solution found.* + + + + - + + - + *ACTION: dw to open cross-project bug to discuss further and + provide minor "test case". May clear with webmasters first, + since would hate for people to start doing "hundreds of tests" + swamping the server even further ... maybe they know of a few + key locations they could get to cooperate in a test?* + + + + - No bug yet, but I've gotten some email one might be open to "remove + categories" from Indigo SR0 and SR1 repositories, to "complete" the + fix for the problem caused by linuxtools changing feature IDs in SR2 + (See ). As is, 6 features show up in "Linux tools" category, but 3 + are for SR1 and 3 are for SR2 and they can not be all installed (all + at once, that is, as most users would "pick them all" if they wanted + Linux tools). While not exactly a blocking bug ... is it something + that will last for years to come ... not to mention, I wonder if we + should always only have one categorization for common repo? + (discussed some in . + + + + - + + - + Any issues/thoughts on this? Allowable? Desirable? Not? + + + + - + + - + *Will leave as "for awareness" until/unless bug open. John did + say, "he didn't know about magnitude of the bug, but that he + thought is could be done safely, since its just used in UI" ... + not a fundamental IU used in builds or installs, or anything. I + guess anyone who had made "internal mirrors" might need to + redo?* + +## Juno + +Ready for M6? + + - Sounds like fair progress towards moving to "non greedy" publishers. + +### Issues or Exceptions + +#### Any issues? Everyone in? Any exceptions known? + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo approved during 1/05 meeting (from rt PMC list, will be in + M6) + BPEL approved on mailing list (as late for M4, but in M5) + Code Recommenders approved on mailing list (as late for M4, but + in M5). + Koneki project approved on mailing list (as late for M5, but + joining in M6). + Others? + +#### Anyone "dropping out" that should be removed from aggregation build? + + - + + - + removed following b3aggrcon files, for M6: + + + + - + + - + dsdp-mjt + emf-teneo + emf-mint + m2t-jet + tools-sequoyah + stp + +#### What to do about Papyrus (and non released XWT dependency) + + - + Both in general (), and specific for this case. + In general, can I say the Planning Council agrees with my summary + conclusion in the ? + - + *Consensus was "yes"* + Specifically, does the Planning Council agree this means Papyrus can + not be in Sim Release? In fact, could not release at all, until this + XWT issue is resolved. + - + They perhaps could use an "old" version of XWT? But, my guess is + that very old release (which happened sort of erroneously) does + not have about.html files, etc. + XWT could graduate/move to its own project and release from + there ... but not much time left, and seems unlikely? + They could also release/join during SR1, etc., if things work + out by then. + Keep in mind, one bad aspect of this is that Papyrus and some + "unreleased" XWT bundles were in Indigo. We should have "caught + the error" back then. + + + + - + *Agreement they can't release (much less be apart of train) with + unreleased dependencies. Wayne said there could maybe be exceptions, + but it would have to be a very special case, under just the right + conditions. Also, it was said, that given that "it was done wrong + last year" speaks to the magnitude of their problem ... that is, + that it is still not fixed/released by now, is even more reason to + not allow it to happen again.* + + + + - + *ACTION: dw to send note to papyrus and modeling pmc saying "no", + and remove them from aggregation build, unless they know something + we don't (e.g. I'm pretty sure XWT is central to their function, but + for all I know maybe they could just leave it out, and haven't said + so yet.* + + + + - + Does anyone suspect any other, similar cases? + + + + - + *None mentioned.* + +### Plans + + - anything to look at? In particular, plans specifying "planned + support for 3.8 workbench"? + + + + - + *no consolidated report yet* + + + + - Is there a controversy brewing over what is released in EPP and how + to decide? See [chain of msgs on cbi-dev + list](http://dev.eclipse.org/mhonarc/lists/cbi-dev/msg00133.html). + +::\* The proposal (to summarize, assuming no communication problems) was +for the "bits" in Eclipse Classic, and the Juno repository to be +provided by the Eclipse releng team. + + - + + - + But, that the bits used in EPP (for the platform/SDK bundles) + come from the CBI builds, and the rest come from common + repository. + - Issue one: this means there would be two versions of + platform bundles "in the wild" for the Juno release. + + - + Either with same version and qualifiers, but (probably + slightly different content), or different qualifiers but + maybe same content ... either case leading to chaos (IMHO). + I think "updates" and "what would adopter's customer's end + up with" are huge problems for Eclipse, in these cases. + + - Issue two, while is is true, Eclipse is open source, and + "people can do with it what they want", I think it is + entirely up to the EPP project what they do and how they do + it (not "CBI") and such a large technical/process change + should get plenty of discussion with EPP Project (and, + probably their PMC ... is this something they think is a + good idea?) + - Issue three, it seems all this is happening "last minute" + instead of the proven "Eclipse way" of producing milestones, + making steady, incremental progress towards a release. + - Issue four, would projects still want to be in EPP, if they + knew bits would be different than if they "built their own"? + - Issue five, I think the Planning Council is in charge of + "the release plan" (since, it effects all top-level projects + and PMCs and Strategic Members) so I think we are obligated + to make a statement on this issue. + +::\* If not obvious, I think we all want to be supportive of CBI and the +LTS efforts, but ... even if bundles are planned/considered to be +identical, then why have two versions of them? Part of the answer is to +make very rapid progress in CBI and LTS. Again ... I think we all +support that rapid progress, but I'd prefer a plan that had same bits, +all around. Perhaps SR1? + +::\* Any thoughts? Suggestions for what our Planning Council statement +should be? Can we make a concrete statement or recommendation? + + - + + - + *Thanks to Andrew Ross for joining the call as a"special guest" + to answer questions and hear concerns and learn more about + bundles and our normal way of ordinating a release.* + + + + - + + - + *Agreement that having "two versions" of bundles for one release + is not tenable (for maintenance, predictable builds, updates, + etc.) and would tarnish Eclipse's reputation for producing + reliable, predictable releases. In some ways, it was speculated, + that maybe the proposal made on cbi-dev list was just a case of + partial mis-communication or terminology issues of not + understanding the nuances of repositories, installs, updates, + adopter scenarios, as well as the Eclipse dev. process and the + project decision processes.* + + + + - + + - + *Markus did say he might be willing to try using CBI output in + some "test builds" for evaluation, if anyone thought that would + be useful, but would not want to "release" those, if the + platform released something different in the common repository. + The EPP packages all come from the "common repository" which he + does not want to change -- that is a key part of the + "coordinated" and "update" story at Eclipse. And, it is up to + each project to decide what goes into that common repository + (that is, they decide what they contribute), since it is their + responsibility. And, the Platform team has decided that they + will contribute the bits from the PDE build for SR0 in June ... + but they are willing to consider changing build systems after + June, if CBI proves ready by then, or even after SR1 (for SR2 + release) if CBI not ready by September or not enough time to + evaluate it by September.* + + + + - + + - + *The Planning Council agreed it would be a better plan to work + "bottom up", to first prove the CBI can build the same thing as + the platform build, and to then move the platform to a CBI + build, and then end up with one set of bundles per release. It + was felt that this might be feasible by SR1. Even that would be + aggressive, and have some risk of "making it on time" (without + sacrificing quality of the builds produced) but would feasibly + allow at least some time to iterate and investigate and prove + that it was adequate if not identical, before committing bundles + "out in to the wild". Perhaps for Juno, "LTS" could "start with" + SR2 ... though long term, Andrew told us, LTS members do want to + be able to have their own builds/fixes/streams even immediately + after SR0, if they so desired.* + + + + - + + - + *So, our recommendation is for CBI and LTS interests to come up + with a plan to get the platform to move to CBI build by SR1 or + SR2, and not plan to release two sets of bundles, as well as + work with the EPP project to make sure the project (and the + package maintainers and committers) agree with any proposals + made to change the way things are done with EPP builds or + packages.* + + + + - + + - + *Planning Council members (or, members of their teams) can + support the CBI and LTS efforts by at least opening bugs/feature + requests on what's needed for CBI to "work for them" (in cbi + bugzilla product), be explicit about acceptance criteria, as + well as contribute man power to try the builds, test the + results, etc., if not actually provide tools for CBI (the Common + Build Infrastructure).* + + + + - + + - + *ACTION: dw will post "recommendation" to CBI dev list for + proper visibility*. + +### Other Business + + - I added some info about p2.mirrorsURL and p2.index to + [Provide_optimized_p2_repository + section](SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29 "wikilink"). + I did this to help educate everyone, but, if anyone thinks I've + added too much, please let me know. + + + + - + *no complaints* + + + + - Project Priorities: Please review and be prepared to discuss this + proposed "policy document" about [project + priorities](SimRel/Priorities "wikilink"). + + + + - + One issue: should we mention LTS? Technically ... it is not in our + mission or scope. + Are we in agreement these can be published a "priorities from + Planning Council's point of view" to begin "socializing" the idea? + + + + - + ''Good discussion. Suggestion to add point about security issues + getting high priority (though, not typically not even part of + "simultaneious release" priorities, per se). Agreement to still + mention LTS priorities but to move it so it does not appear Planning + Council is trying to govern LTS. '' + + + + - + ''ACTION: dw to send note to cross project list to begin socializing + the ideas of documenting priorities ... but, emphasize, no change in + procedures or requirements, just trying to better document what we + do. + + + + - Will Java pack200 issue in equinox need action? Is a fix possible? + It will not literally be a problem if everyone published both + jar.pack.gz files and jars, but would be inefficient (ending up with + "failures" with pack.gz files, and then downloading jars if using + Java 7). Keep in mind, we have decided in the past that we should + always publish both \*.jar and \*.jar.pack.gz files ... so, no + change in policy for Sim. Release. + + + + - + *Jesse did not know, had not come up on rt-pmc call ... but, I'm + sure we'll hear about it, if change to procedures about nested jars + become recommended.* + + + + - Anything else? + + + + - + *Nothing mentioned ... but ... did run out of time ... so feel free + to mention issues on mailing list or bring to EclipseCon meeting in + a few weeks.* + +## Next Meeting + + - EclipseCon face-to-face meeting: Sunday, March 24, 2 - 4 local time + (Eastern). Joint meeting with Arch. Council 4 - 5. + + + + - + Agenda will be developed soon, but good time to discuss Kepler and + other "big picture" items. + + + + - April 4, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_16_2014.md b/wiki/Planning_Council/March_16_2014.md new file mode 100644 index 0000000..2b34513 --- /dev/null +++ b/wiki/Planning_Council/March_16_2014.md @@ -0,0 +1,272 @@ +## Logistics + +EclipseCon Face2Face Sunday March 16th, 2-4pm, Bayside + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

D: John Arthorne

Steffen Pingel

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y (Ian and Tom Watson)

Chuck Bridgham

WTP (PMC)

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Y

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

(PMC rep)

IBM (Strategic Developer)

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Reviewed important dates + + - Reminder: [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + +## Kepler / Luna issue + + - Reviewed important p2 bug + - This is a serious problem for Luna, Tycho creates a new EXE each + time, and EPP Uses tycho. + - Why is this not a problem for the platform build? (could be the + way EPP Does branding) + - We don't really have a solution here. It's not clear this has + ever worked, but maybe we have just been lucky. This doesn't + appear to be a problem for SR2, having said that, some people + (Namely David) have seen it. Not much we can do now for Kepler + anyways. + +## Maven Discussion + + - Should we / can we push all our stuff to maven + - How do we push dependencies + - Can we use stuff from Maven, why not? (Legally) + - We should be doing this. If someone really wants to push on + this, get in touch with Wayne and start putting together a + proposal + +## Luna Planning + + - Nothing really to discuss + +## Progress on Action Items + + - Improved "aggregator examples/doc". (dw -- no progress). + - Orbit plan + - Wayne says that Maven is the answer going forward, no real + update at this time. + +## Rolling Release + + - Should we have several streams + - Should we remove the notion of 'service releases'? + - We call Sept and Feb releases SR releases. But in reality they + are Eclipse Platform SR releases, with some other components + that may be or may not be more stable than the previous version. + - Marcel (Actually, this was mentioned in the AC meeting, but I'll + add it here) wanted to put Code Recommenders 2.0 in SR2 but + didn't because he wasn't really allowed. However, others have + done this type of thing. Are we fooling ourselves? Are we + fooling our users? Can we have 3 releases points a year and the + projects can contribute whatever they want (as long as the + aggregator doesn't object)? Again, if anyone really wants to do + this, we need to start with a concrete proposal. + + + + - Should we stop the release and go with 'Mars forever'\! + - If we did this, what would we call it? + - Does it still make sense to have a single name for the Year + (Mars, Mars 1 and Mars 2) + - John mentioned that Ubuntu has a good version number XX.MM, so + for us that would be Eclipse 14.6 (June 2014), Eclipse 14.9 + (Sept 2014), Eclipse 15.2 + - Remember these are the 'Marketing Versions' not the semantic + versions, or bundle versions. These say nothing about + compatibility + - What about two streams, one for unstable and one for stable + - Cedric mentioned the challenges with trying to get new stuff in + users hands. + + + + - Orion wants to move to release every two weeks + - Will this be a problem? Do we need to rethink the concept of a + 'release'. + - Other (non release train projects, Vert.x for example) want to + do this too. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_20_2011.md b/wiki/Planning_Council/March_20_2011.md new file mode 100644 index 0000000..bb73200 --- /dev/null +++ b/wiki/Planning_Council/March_20_2011.md @@ -0,0 +1,451 @@ +## Introduction and Introductions + +This is our annual, traditional EclipseCon Face-Face Meetings, Sunday, +March 20, At Hyatt, Napa Room. + + - + + - + 3-4 (Pacific Time) PC face-to-face meeting, followed by + 4-5 (Pacific Time) Joint Councils Meeting (See [Donald's note to + list](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01858.html)). + +## Logistics + +| | | +| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council EclipseCon face-to-face meeting** | +| Date & Time: | Wednesday, March 20, 2011, at [3:00 PMC Pacific time. Napa Room](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=03&day=20&hour=19&min=0&sec=0&p1=179) | +| ~~Dial-in:~~ No dial in. | ~~For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page.~~ | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

?

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

?

Brian Payton

Datatools (PMC)

?

Anthony Hunter

Tools (PMC)

R

Adrian Mos

SOA (PMC)

?

Ed Merks

Modeling (PMC)

?

Thomas Watson

Rt (PMC)

?

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

?

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

?

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

?

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + -  ? + +## Indigo Status + + - M6a repo and packages? See and + +## Name Indigo +1 + + - Name that release; Indigo+1. And [the winner + is](http://www.eclipse.org/indigo/planning/poll2012name.php) ... + *Juno. Pending EMO Review.* + +We'll examine process, votes, be sure there is a clear winner, and that +the winner is not objectionable in some way we didn't think of before. +Remember, once we decide the name, it will still have to be "vetted" by +Ian/Mike/Janet to make sure there would be no trademark infringement, +etc. Is is very unlikely ("no chance") this vetting will be done +before/during EclipseCon ... so we can "announce" our choice, but with +the caveat "pending final EMO reviews". + +(Greatest thanks, Pascal\!) + +## CVS and GIT + + - Status, plans, and urgency of moving from CVS to GIT. Why it is + required, again? (Denis, Wayne?) + +*Wayne presented the current plan. After Indigo, begin to more actively +move projects to GIT. Assuming, EGit 1.0, released with Indigo, will be +"good enough" to support Eclipse Committers. By Fall 2012 (after Juno) +"turn off" CVS. Primary reason is that CVS is no longer actively +supported; no new releases planned. That is partially because it is so +stable, but it also means if an important bug or security vulnerability +was desired to be fixed, we'd be "on our own" ... have to patch and +rebuild ourselves. \[Wayne says Denis can point us at some bugs of +concern\]. Less tangible reasons involve simply moving to what people +want, what's modern, easier to use, especially for "new comers". While +there's some concern about having just one "solution" that everyone has +to use, there's some benefit to using just one repo at Eclipse, since +then if users learn how to use one project at Eclipse, provide patch, +etc., then they could more easily do so for another project, if same +repo used by the projects. \[There is so proposal to "turn off" SVN, +but, not widely used.\] It was also mentioned that one goal is to "save +IT effort" but a) not clear how much effort CVS takes, and b) its not +clear CVS can literally be turned off, or even made "read only" (since +many projects need ability to do patch builds, etc., on old system with +old code). It is a different impact if literally turned off, done away +with, since then some long established projects would have to figure out +how to replicate old builds with new repository. Unclear how much effort +that would take. (Or, an alternative is that companies/committers that +need to do a patch build, can simply do on their own systems, +duplicating the cvs repos, etc., but that has obvious disadvantages +too.)* + +*Some issues with GIT were briefly mentioned: a) it is still not clear +what the right granularity is for a repo (that is, no one even knows +what to recommend as a best practice). b) some delay in using Gerrit at +Eclipse, c) some confusion about if contributors can supply a patch to +bugzilla, or simply supply a reference link to a another repo that has +the updated code committed to it (Wayne said he thought he'd sent a not +clarifying that, perhaps only to Architecture list?)* + +*Would moving to GIT after Indigo mean some projects are doing Indigo +maintenance from CVS? And Juno from GIT? Or, would Indigo maintenance be +moved to GIT as well? If CVS and GIT, it would be lots more work for +committers to keep streams in sync ... is there anything that could be +done to improve this?* + +## Misc. References + + - Any discussion of these documents ... + +:\*\[| V6 of the +Eclipse Road Map\] ... mostly here for reference. Any feedback should +have already been given ... board review is next day. + +:\*\[| +Themes and Priorities\]. (Again, here for reference, may be discussed at +joint meeting.) + +*These specific documents were not discussed, but the general issue of +"inadequate plans" was mentioned ... that is, some projects have no +plans, essentially ... so some attention, changes or improvement in +process may be needed in future. It was mentioned (in following, joint +meeting, that plans would always be required, that they were an +essential part of being "open", and "transparent". Also from joint +meeting, if bylaws changed as expected, and no longer a req. council, +then in addition to "plans" projects may be expected to name their own +themes and priorities.* + +## Eclipse 4.2 vs. 3.8 + +Next year, what's primary, what's secondary? Do we buy-in to the +[Eclipse Project's (implied) +proposal](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05597.html)? + +How important is it to your project or to your strategic member company, +that you represent, to use Eclipse 3.8 or Eclipse 4.2 as primary? Think +of it on a 10 point scale (for discussion): 1 is very important to stay +on 3.8 as primary, 5 is don't care, happy to go along with what others +want/need, and 10 is very important to use 4.2 as the primary? + +*There was a general sense that if 4.x was ever going to be "real", we +needed to make it primary. One project (besides Platform) was looking +forward to it, and has (loose, informal) plans to exploit it, once +primary. One member expressed concerned that since they depend on +bundles/tools/add-ins that are not part of Eclipse (and not part of +their company) that they have no control over ... so they might need to +be on 3.x for that reason, and they wondered if we could have "both +streams be primary". This wasn't thought to be realistic, since means +"double the work" for everyone (to test both, if nothing else) but it +was acknowledged that 3.x would remain to be very important. This called +for a definition of "primary": a) EPP packages are built with it; b) +projects build and test with it. It was mentioned that 4.x may not be +getting much use by general population of Eclipse IDE users since most +simply download EPP Packages.* + +*While no final decision was made, my impression (or proposal) is that +the plan should be to have 4.x be primary, and go down that path for +Juno, unless or until some substantial reason is found not to. This +would still allow 3.x to get as much or as little attention as desired, +but we would not build EPP packages with it. It was asked, +hypothetically, why couldn't we have both streams for EPP packages ... +but, general fear was this would be confusing to community/users and +more work for committers to "fully" support both, etc.).* + +*It was also asked, "when would compatibility layer be removed, or no +longer supported", and the answer was "never, it will always be there, +always supported". That is, there is no expectation that Projects move +to "native" 4.x APIs.* + +*It was mentioned, that some thought the "message" needs work ... that +the details in [cross project +note](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05597.html) +sounded "scary"?* + +## Long Term Planning discussion + +*Note to self ... next year allow for two hour meeting :). We did not +have time to chat about any of these longer term issues ... and will +address them at our regular monthly meetings*. + +EclipseCon face-to-face is good time to discuss high level or long term +issues. The following items are potential items to discuss ... please +add any of your own. They can range from a thought or question, to a +specific proposal. The purpose of this part of the meeting is not +necessarily to decide or resolve any specific issues (there likely would +not be time) but to make sure we are all, as a council, in agreement on +our general course, what are most important issues to address, etc. + + - Review our + [Mission](Planning_Council#Planning_Council_Mission "wikilink") and + recent + [retrospectives](Helios_retrospective.md). + In addition to the formal, documented mission, several other + motivations tend to influence our efforts: + +:\* improve quality and consistency of Eclipse as a whole, + +:\* make things as easy as possible for committers (while meeting other +goals), + +:\* improve "value" of Eclipse, by improving what adopters can adopt and +providing what strategic members need. + +:\* Others ...? + + - How are we doing? Beside 'being on time' are we achieving the right + quality? By helping projects focus on "minimum set" of items that + are important for Eclipse as a whole? + + + + - Should we have "must do" items at all? Or, are they just + recommendations? + + + + - Are the requirements about right? Too many? Too few? + + + + - Should we have requirement related to bug fix rate? Backlog + reduction? unit test coverage? + + + + - How's the aggregation process? Would it be fair to ask for zipped p2 + repositories for aggregation input? + + + + - Is the release tracking checklist on Portal worthwhile? Should we do + away with it? Should we make it better? (Such as, there could be + more "auto fill-in" ... such as from other portal data, more + "testing" results would provide the main data for forms while + projects would provide the documentation for deviations or + exceptions). + + + + - Who is the audience(s)? (Projects, PMCs, Planning Council, + Adopters). + + + + - Is yearly release (with two service releases) the right interval? + Should maintenance be quarterly? Should releases be every other + year? Or, perhaps, every other year be a LTS releases with "off" + year having less maintenance emphasis? + + + + - Is there too much "pressure" or emphasis that everyone should be + part of Simultaneous Release? Or, should it be one of our goals, + that every project should be part of the Simultaneous Release? How + would we describe or define who should, or who shouldn't? + + + + - Terminology improvements: + +:\* "Tracker" --\> "Checklist"? + +:\* "Exceptions" --\> "Deviations"? + +## Next Meeting + + - April 6, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](Indigo "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_21_2010.md b/wiki/Planning_Council/March_21_2010.md new file mode 100644 index 0000000..71336ef --- /dev/null +++ b/wiki/Planning_Council/March_21_2010.md @@ -0,0 +1,335 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call - EclispeCon F2F** | +| Date & Time: | Sunday, March 21, 2010, at [UTC 2100 / 2:00 PM local time (Pacific, this time)](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=03&day=21&hour=21&min=0&sec=0) | +| Location: | Bayshore room of the Hyatt Santa Clara. | +| Dial-in: | ~~For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page.~~ No dial-in for this meeting. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Oliver Cole

Tptp (PMC)

R

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)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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.

+ + + +## Helios + + - We require a repository, and we require an optimized repository, but + turns out "what is a repository" is not agreed to by everyone. See + and its predecessor . + + + + - + Do we (Planning Council) agree on what a repository is? + + + + - + Is it fair to dictate/clarify that definition (now), for projects + that want to participate in Simultaneous Release? + + + + - + has anyone investigated using unpack from a (pre-release) Java 7? + Anyone willing to? See + + + + - + Should we make (all) jars files available from common repository? + (we currently remove some, when they have a pack.gz file, to save + space). + + + + - + + - + From meeting, it was agreed this was reasonable to expect both + original jars and pack.gz files, with P2 compliant metadata, + since that has been the expectation all along. While changes + might be possible in the future (e.g. next year) its something + that has to be worked through, and wide spread agreement + achieved. + + + + - + + - + To correct a statement I made at the meeting, there actually is + a specification: [Network Transfer Format + JSR 200](http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html) + though that wouldn't change to overall issue, it at least can + shed some light. + +### Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +A new Aggregator is (nearly) ready for testing. I hope to run the new +one in parallel with old one. Currently, I'd be reluctant to change the +"official" one, this late in the cycle, unless there's really good, +important reasons to. + +#### Tracking progress and compliance + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + +How is your tracking going? + +PMC Representatives: please be prepared to give brief (verbal) summary +of the state of your projects. (such as, how many participating, anyone +"late" on required or optional things like Accessibility checklists, +which were due by end of M6?) + +What should "summaries" show? + +### Process and seed list for Helios +1 + +See Last year's bug + +Rules and procedure for Helios +1 : + +Must be Greater than "H" (not too much greater, to leave room for later +alphabetized names) but no strict rule that is has to be literally "I" +or "J". + +Preference given to names that fit the "moon", "gods", or "scientists" +themes we've had so far but no strict rule. + +We will have cross-project bugzilla open to solicit names until April 8. +Then a series of doodle polls to pick top choice. We will have multiple +doodle polls, vote until majority achieved (anyone know of a voting site +that allows first, second, third choice? with "built in" runoff votes?) + +TODO: open bug this evening, so can be discussed at EclipseCon + +Planning council will remove any they deem "unsuitable" (as always). + +Final choice made by May 7 (Helios M7). + +Planning Council seed list: + + - ~~Janus~~ + - ~~Iccuris~~ + - Issac + - Ion + - Isis + - Iris + +### Anything to discuss for next year's release? + +Things to add/change/remove? + +How to handle "3.7 stream" vs. "e4 stream"? + +#### IDE and Runtime-only items + + - + IDE Only items "installed" in EPP packages + + + + - + need to figure out better story for pre-packaged runtimes + + + + - + Tom and Chris agreed to handle. (will come up with some + instructions/examples). + +## ToDo Items + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (Wayne (re) volunteered) + + + + - provide concrete instructions for (new) license-consistency + requirement ... before M6? (John Arthorne). + +## 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 + + - + [April 7, Wednesday](April_07_2010.md), + Noon Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_24_2013.md b/wiki/Planning_Council/March_24_2013.md new file mode 100644 index 0000000..1ee4ff2 --- /dev/null +++ b/wiki/Planning_Council/March_24_2013.md @@ -0,0 +1,324 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Meeting

Date & Time:

Sunday, March 24, 2013, at 1400 Eastern

Face-to-Face. No Dial-in.

Room: South End, on the Plaza Level (top floor) of the World Trade Center.
+Note: MeetGreen will be at the venue setting up registration in case you need anything.

+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

No

John Arthorne

Eclipse (PMC)

Yes

Steffen Pingel

Mylyn (ALM) PMC

No (not attending EclipseCon and Mik is not available on Sunday)

Brian Payton

Datatools (PMC)

No (not attending EclipseCon)

Doug Schaefer

Tools (PMC)

Yes

Adrian Mos

SOA (PMC)

No (flight schedule)

Ed Merks

Modeling (PMC)

No

Ian Bull

Rt (PMC)

Yes

David Williams

WTP (PMC) (appointed Chair)

No.

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Yes

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

No

Neil Hauge

Oracle (Strategic Developer)

Yes

Kaloyan Raev

SAP AG (Strategic Developer)

No (not attending EclipseCon)

Markus Knauer

Innoopract (Strategic Developer)

Yes

Achim Loerke (Markus Tiede)

BREDEX (Strategic Developer)

Yes

Shawn Pearce

Google (Strategic Developer)

Yes

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +## Minutes + +### Policy on new releases joining SR + + - We agreed on David's proposed policy from previous call: "The new + release must be in RC1 builds for the SR, must have released one + month prior to that RC1, and must be willing/able to test and + provide a quick maintenance release if last minute problems found." + +### Build reproducibility + +We had a lengthy discussion about the issue of reproducibility of the +aggregation build. Ideally aggregator should be idempotent: multiple +runs of the aggregator on the same aggregation input files should +produce the same result. In practice, this does not work. One problem is +that people contribute a composite repository URL, and then just update +the children any time they want without updating their contribution +file. There are a number of drawbacks to this: + + - It is very difficult to do a careful respin of only one component to + address a critical bug, such as the case with EGit in Juno SR2. You + can't be certain that nothing else will creep in. + - You can't diff two states of the aggregator and see exactly what + projects have changed. + - After the release is over it can never be reproduced again + - Projects end up accidentally contributing the wrong thing to the + aggregator + +There was general agreement that we should strive to make the aggregator +idempotent. One step in this direction is not allowing composite +repositories to be used as input. There is a perception that b3 files +are brittle and projects are afraid of breaking things, it is very hard +to know if you made your changes correctly. If there was a simple way to +update the repository for each aggregation build there would be less +incentive to "cheat" with composite repositories. + +A common convention on p2 repository addresses could help. Some parts of +the manual updating could be automated if all projects had a normalized +repository path like /milestones/kepler/m5 for example. + +Another possible solution is that the aggregation mirror \*all\* the +data as a first step. Then that mirroring could be turned off for +emergency rebuilds. This also handles the fact that projects might not +have durable p2 repositories and after the release may delete that +repository and make their aggregator input invalid. Or we just capture +and save the metadata such as bundle version numbers and we can validate +that nothing has changed except what we expect to change. This could +also be used as a way to control/enforce that projects are providing +consistent/durable inputs. + +### Release train rules + +There is a general perception that there are "too many rules" for +joining the release train. Some projects are declining participation +because they see it as unnecessary process overhead. In reality the +non-negotiable rules are few, and there is a long list of "should do" +items that make the overall rules document look daunting. The suggestion +was made to split this into two distinct documents such as "release +train rules", and "release train guidelines". We should also strive to +make the rules less wordy. Keep the rules very short, with links as +appropriate to other documents for more details. Someone should be able +to sit down and read through all the rules without being overwhelmed. + +### Release train rhythm + +We had a very general discussion about the current "one plus two" rhythm +of the release train. The original intent is that there was one annual +release with new features, and two service releases with only bug fixes. +This evolved over time and now some projects just treat it as three +release windows into which they can put whatever new release they want. +The problem is that having new features only once a year isn't fast +enough for some communities. It is fine for stable projects but not for +new projects or projects working in areas with rapid innovation. + +The idea was floated of having more than three release windows, and it +would be up to individual projects whether they take advantage of that +or just continue with three per year. For example moving to quarterly +releases would not be a big shift. The problem is that the current +pattern is very engrained and our consumer community makes expectations +of release periods far in advance. If we consider changing this we would +need to give a lot of advance notice. + +Another idea is that we already have a mechanism for doing releases +every six weeks: the milestones. We could promote the milestones as the +path for getting cutting edge new functionality on a faster rhythm. We +could include the aggregate milestone repository URL starting with M1 so +users can upgrade from milestone to milestone very easily. This is +similar to what browsers do where they use the "beta channel" as the +forum to get early testing and give early access to new function more +quickly for those willing to live with a bit more instability. While +this approach gives a channel to consume projects that release more +frequently, the trade-off is that it also includes a lot of pre-release +software that is not well validated. What people want is all the latest +releases on a more frequent schedule... every month give me the latest +version available of each project. In many cases it will be the same as +last month but this is fine. + +### The release train and RT + +We had a long general discussion about EclipseRT and its relationship to +the release train. It is not well served by the current release train. +They often release on a more frequent schedule so three releases a year +isn't enough. They don't necessarily care about the aggregate repository +because their users install their software in other ways (except for +provisioning a target platform in their IDE). Many of the release train +guidelines are not applicable to some of these projects (accessibility, +translation, etc). They often have very little need to integrate with +other Eclipse projects so releasing at the same time isn't necessarily +as important. Maybe this is fine and the answer is that they just don't +participate. This does mean they lose out on the marketing opportunity +and focus that comes with being in the June release. + +Could there be a completely separate EclipseRT release train. What would +that look like? More frequent schedule, perhaps coordinated push of +artifacts to maven central rather than p2. + +### Orbit + +There was some discussion of the future of Orbit. We all agreed Wayne +should take it over, but then Wayne arrived to the meeting and that plan +was scrapped. The "bundle recipes" approach sounds promising. We could +store only our custom metadata (Manifest.mf, etc) in the Orbit git +repository. We would also need a persistent store of the original +upstream binaries in case those upstream projects disappear (especially +for LTS). However there would be no need for these upstream binaries to +be in any version control system. + +## Next Meeting + + - April 3, 2013, "First Wednesday" Meeting + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_25_2012.md b/wiki/Planning_Council/March_25_2012.md new file mode 100644 index 0000000..c8643ad --- /dev/null +++ b/wiki/Planning_Council/March_25_2012.md @@ -0,0 +1,333 @@ +## Logistics + +| | | +| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, March 25, 2012, at [1400 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=03&day=25&hour=14&min=0&sec=0&p1=179) | +| Face-to-Face. No Dial-in. | Room: Fairfax B. Second floor of Hyatt. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Mik Kersten (Benjamin?)

Mylyn (ALM) PMC

D

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Y

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Any? + +## Juno + + - How did we do for M6? + +### Issues or Exceptions + +#### Any issues? Everyone in? Any exceptions known? + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo approved during 1/05 meeting (from rt PMC list, will be in + M6) + BPEL approved on mailing list (as late for M4, but in M5) + Code Recommenders approved on mailing list (as late for M4, but + in M5). + Koneki project approved on mailing list (as late for M5, but + joining in M6). + Others? + + + + - + Any discussion of [Papyrus and XWT + situation](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg07494.html)? + +### Plans + + - anything to look at? In particular, plans specifying "planned + support for 3.8 workbench"? + + + + - + *must be a "report" by now?* (Wayne?) + +## Kepler + + - Issues and direction: + +## Long Term Planning discussion + + - Interesting to read minutes from last [year's + meeting.](March_20_2011.md) How far have we + come? + +EclipseCon face-to-face is good time to discuss high level or long term +issues. The following items are potential items to discuss ... please +add any of your own. They can range from a thought or question, to a +specific proposal. The purpose of this part of the meeting is not +necessarily to decide or resolve any specific issues (there likely would +not be time) but to make sure we are all, as a council, in agreement on +our general course, what are most important issues to address, etc. + + - Review our + [Mission](Planning_Council#Planning_Council_Mission "wikilink") and + recent + [retrospectives](Indigo_retrospective.md). + In addition to the formal, documented mission, several other + motivations tend to influence our efforts: + +:\* improve quality and consistency of Eclipse as a whole, + +:\* make things as easy as possible for committers (while meeting other +goals), + +:\* improve "value" of Eclipse, by improving what adopters can adopt and +providing what strategic members need. + +:\* Others ...? + + - How are we doing? Beside 'being on time' are we achieving the right + quality? By helping projects focus on "minimum set" of items that + are important for Eclipse as a whole? + + + + - Should we have "must do" items at all? Or, are they just + recommendations? + + + + - Are the requirements about right? Too many? Too few? + + + + - Should we have requirement related to bug fix rate? Backlog + reduction? unit test coverage? + + + + - How's the aggregation process? Would it be fair to ask for zipped p2 + repositories for aggregation input? + + + + - Is the release tracking checklist on Portal worthwhile? + + + + - + + - + How's the "new portal" coming? (Wayne) + + + + - Who is the audience(s)? (Projects, PMCs, Planning Council, + Adopters). + + + + - Is yearly release (with two service releases) the right interval? + Should maintenance be quarterly? Should releases be every other + year? Or, perhaps, every other year be a LTS releases with "off" + year having less maintenance emphasis? + + + + - Is there too much "pressure" or emphasis that everyone should be + part of Simultaneous Release? Or, should it be one of our goals, + that every project should be part of the Simultaneous Release? How + would we describe or define who should, or who shouldn't? + + + + - What is relationship of Planning Council/Yearly Release and LTS? + Conceptually? Governance? Bylaws? + +## Other Business + + - ? + +## Next Meeting + + - April 4, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/March_7_2018.md b/wiki/Planning_Council/March_7_2018.md new file mode 100644 index 0000000..83b5a96 --- /dev/null +++ b/wiki/Planning_Council/March_7_2018.md @@ -0,0 +1,195 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, March 7, 2018, at 1200 Noon Eastern

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Photon & Oxygen status + - Oxygen 3.a for Java 10 support status + - Post Photon SimRel status : Please before the call **read and + comment** the proposed + [FAQ](https://docs.google.com/document/d/1IVA59E5bxv1l1W1ZTSZMUUH7IKIO-mRLEGn1bVO-dFs/edit?usp=sharing) + +## Attendance + +Aleksandar Kurtakov (Tools Project), Ed Merks (Eclipse Modeling +Project), Frederic Gurr (Eclipse Foundation), Martin Lippert (Eclipse +Cloud Development), Mickael Barbero (Eclipse Foundation), Mélanie Bats +(Obeo), Nick Boldt (Red Hat), Thomas Watson (IBM), Wayne Beaton (Eclipse +Foundation) + +Regrets : Dani Megert (Eclipse Project), Sam Davis (Mylyn) + +## Notes + +### Photon & Oxygen status + +Everything is okay. Oxygen.3 RC4 EPP Package for tomorrow, should be the +Oxygen.3 released on March 21st Oxygen.3a for April 11, Java 10 support +seems to be ready. + +### Post Photon SimRel status + +The planning council has decided on the mailing list that the cadence +will be 13 weeks starting from the June 25 2018. + +After the review of the +[FAQ](https://docs.google.com/document/d/1IVA59E5bxv1l1W1ZTSZMUUH7IKIO-mRLEGn1bVO-dFs/edit?usp=sharing), +some points were discussed during the call : + +#### Tracking + +Wayne asked how we would track people that would be in or out? It is +difficult to track the activity on the projects, as some projects being +mature are very stable and are still participating to the release train. +The idea was to just declare once that a project is in and then we would +never ask again until there is nor more activity. This does not seem to +be feasible. It was discussed also to rely on the aggregation files to +see whose in, but there are some projects that could be part of the +SimRel but who do not contribute to the P2 repositories (example of +Orion & Che). This discussion will be continued on the mailing list. + +#### Milestones vs Checkpoints + +Fred detailed on the mailing list that the new cadence will generate +fewer tests as it will reduce the number of EPP packages build. He +proposed to replace the checkpoint 2 C2 by a milestone to increase the +number of tests as during last year we had many different respins. In +the end it was proposed to just have miletones no more checkpoint, and +clarify that a milestone just means that we are building EPP package and +wait for feedback from the community to test it. There will be no respin +for miletsone we will rebuild EPP just for the next milestone. So in the +end the proposed planning for the cycle would be : + + - M1 Friday Week 3 : Milestone 1 - all the projects are expected to + contribute their latest working version for a 1st alignment, + is built, EPP packages are + released for tests + - M2 Friday Week 6: Milestone 2 - all the projects are expected to + contribute their latest working version for a 2nd alignment, API + breakages are in, is built, + EPP packages are released for tests + - M3 Friday Week 9 : Milestone 3 - all the projects are expected to + contribute their latest working version for a 3rd alignment, + is built, EPP packages are + released for tests + - RC1 Friday Week 10 : API & Feature freeze + is built, EPP packages are + released for tests + - RC2 Friday Week 11 : Only fixes it is assumed all code is done by + the end of RC2, is built, EPP + packages are released for tests. + - GA Wednesday Week 13 : is + released and EPP packages, + is updated to point to + the new release. + +See the [proposed +schedule](https://docs.google.com/spreadsheets/d/1BZywK-gKbK-fmcEkxv550OHmw01xEN07RK9LMPSE40g/edit?usp=sharing) +updated for the next 3 years and the update [FAQ +draft](https://docs.google.com/document/d/1IVA59E5bxv1l1W1ZTSZMUUH7IKIO-mRLEGn1bVO-dFs/edit?usp=sharing). + +#### Naming + +Mélanie proposed on the mailing list the name following the pattern +year.month: Eclipse YYYY.MM. This does not seem to fit what the Eclipse +Foundation expect, we should avoid confusion with the Eclipse brand by +adding a qualifier between Eclipse and the year month pattern: Eclipse +XXX YYYY.MM Many different propositions were done : + + - Eclipse Simultaneous Release + - Eclipse SimRel + - Eclipse Simrel + - Eclipse Train + - Eclipse Q... and continue to change every year in june as we do + today + - Eclipse in Concert + - Eclipse Collective + - Eclipse United + +As it seems quite difficult to get a clear decision on that point, +Mélanie will open a bugzilla to let every one participate and +contribute. Ed will broad this topic to the Board as Eclipse branding is +also discussed there. + +Mélanie will announce this week our intention to switch to a rolling +release after Photon on cross-project. \ No newline at end of file diff --git a/wiki/Planning_Council/May_02_2012.md b/wiki/Planning_Council/May_02_2012.md new file mode 100644 index 0000000..360fd1e --- /dev/null +++ b/wiki/Planning_Council/May_02_2012.md @@ -0,0 +1,248 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 02, 2012, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2012&month=05&day=02&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Mik Kersten (Stephen)

Mylyn (ALM) PMC

D

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Juno + +Ready for M7? + + - moved to "non greedy" publishers? + +### Issues or Exceptions + +#### Any issues? Everyone in? Any exceptions known? + + - + Exceptions for projects not in M4, that still will to join Juno: + - + Virgo approved during 1/05 meeting (from rt PMC list, will be in + M6) + BPEL approved on mailing list (as late for M4, but in M5) + Code Recommenders approved on mailing list (as late for M4, but + in M5). + Koneki project approved on mailing list (as late for M5, but + joining in M6). + Papyrus + Others? + +#### Anyone "dropping out" that should be removed from aggregation build? + +What's up with TCF? Impact to others? Will (some) version of it be in +Juno? (effects Linux Tools, they might have to "reship" the Indigo +version?) + +*No issue with Linux tools shipping Indigo released version, while they +wait/work with TCF toward their 1.0 version. (but, can not "ship" +unreleased code).* + +### Other Business + + - dw to follow up with Andrew to get [Asterisk](Asterisk "wikilink") + bridge for planning council calls. + + + + - Wayne to follow up with ind. projects that haven't provided version + numbers yet. + +## Next Meeting + + - + + + - June 6, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + + + + - + + - + Final meeting before release\! (?) + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_03_2017.md b/wiki/Planning_Council/May_03_2017.md new file mode 100644 index 0000000..4a130a4 --- /dev/null +++ b/wiki/Planning_Council/May_03_2017.md @@ -0,0 +1,130 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 03, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + +### Eclipse Foundation + + - Wayne Beaton, interim chair + - Frederic Gurr + - Mickael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - OBEO (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + +### New Representative + + - Aleksandar Kurtakov will replace Doug Schaefer as the Tools PMC + representative. + +### "Java 9 Release" + + - Finalize our plans with regard to a July *Java 9 Release* + - Should we deliver initial Java 9 support in a separate repository as + suggested in the last meeting? + +### Neon.3 update problem + + - Status report + +### Oxygen M7 + + - Are we on track for the next milestone? + - Any outstanding issues related to the HttpClient problem that also + affected Neon.3? + - Which Guava version is intended for Oxygen? Ed Willink summoned to + use 21.0.0 + (http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14350.html), + while Orbit for Oxygen M6 still contains 15.0.0 only. + +## Notes \ No newline at end of file diff --git a/wiki/Planning_Council/May_04_2011.md b/wiki/Planning_Council/May_04_2011.md new file mode 100644 index 0000000..003f920 --- /dev/null +++ b/wiki/Planning_Council/May_04_2011.md @@ -0,0 +1,316 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 04, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=05&day=04&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

R (can't make it, on airplane)

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

R

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

R

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - ? + +## Indigo Status + + - On track for M7? and beyond? + + + + - + *No issues raised* + +## Name Indigo +1 + + - FWIW, "Juno" has passed EMO sanity check and review, so its + official. + +## Juno Release Planning + +(See also [notes from previous +meeting](April_06_2011.md).) + +I've moved "working plan" to +[Juno/Initial_Working_Plan](Juno/Initial_Working_Plan "wikilink") for +more public readings. + + - + *Good discussion with good feedback (positive and constructive), + though still not much known in terms of concrete plans of (sub) + projects, so would be good to get that, if possible, by June. But, + others were quick to point out, probably won't know much about Juno + plans for months to come, not by next month.* + + + + - + *Concern was mentioned the proposed plan still reads with a little + too much emphasis on 3.8, as though 4.2 wasn't ready yet.* + + + + - + ''Perhaps wording could be improved ... perhaps to change emphasis + to "state concrete plans for 3.8 early", supported or not, tested or + not, respond to bugs or not, same function or not in both streams, + etc., so adopters and downstream projects know what to expect? And + to include better wording as to the purpose ... "The Planning + Council encourages, as good Eclipse citizens, we should support + adopters that can not make the transition completely to 4.x stream + yet". Or similar (that is, explicitly, it is not because 4.2 is not + ready). '' + + + + - + *It was mentioned, that some projects, such as the Platform's JDT, + might end up "splitting streams", not even necessarily because of + the split workbench, but they might tie down 3.8 as a + maintenance-only stream, and put new feature/functions in 4.x only. + They haven't decided that yet, just mentioned it as a possibility. + \[And, if anyone is wondering, the 3.x stream would contain the Java + 7 support, since that's largely done already in 3.x stream.\] It was + pointed out this might have big impact on downstream projects, such + as Web Tools ... unclear if downstream projects would have to split + streams in such cases, or double-up on testing two version of JDT, + as one example, and those downstream projects might have to pick one + or the other to focus on (and it might not be 4.x). Put another way, + if there is a potential split stream for every project, then the + complexity would grow quite large. Maybe too large and complex to + cover in our Simultaneous Release Plan? At some point, we might have + to say, we as the Planning Council are only concerned with one + stream, and only those that want to participate on that stream, ... + and any other configuration is outside the scope of Planning + Council's yearly release. Just a possibility.* + + + + - + *It was also mentioned that early testing, of Indigo stream and "a + large IBM adopter product" has gone well on 4.x stream so the + Platform team has high confidence in compatibility layer.* + + + + - + *There was, still, a general feeling that "4.2 as primary platform" + would be a fine to great plan. More a question of what to do/say + about 3.8. The council was reminded that 3.8 was deemed important by + some members, not even necessarily for their own stuff, but + sometimes there are dependencies or add-on tools that are outside + Eclipse and outside members control that they still want to support + or work with. I'm not sure we'll ever know concretely the degree of + that? And, it is even unclear if that's a theoretical concern, or if + there are already specific, known cases?* + +## Juno Dates + + - + Release: June 27, 2012 (fourth Wednesday) + SR1: September 28, 2012 (fourth Friday) + SR2: February 22, 2013 (fourth Friday) + +TODO: compute milestone dates, similar to previous years. + +## Next Meeting + + - June 1, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Indigo Wiki page](Indigo "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_04_2016.md b/wiki/Planning_Council/May_04_2016.md new file mode 100644 index 0000000..a91bd1f --- /dev/null +++ b/wiki/Planning_Council/May_04_2016.md @@ -0,0 +1,486 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 4, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Alexander Nyssen

Itemis

Y

Nick Boldt (and Max)

Redhat (Strategic Developer)

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

EPP (appointed)

Y

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Wayne remind projects of Neon's critical dates and "new and + Noteworthy". To quote + + + + May 26/2016 - IP Log submission deadline + June 2/2016 - Review materials due + + If you want your project featured in the aggregated new and noteworthy document [1], you need to set the New & Noteworthy URL field in the Review section of your project's Neon release record [2]. + + When it comes to marketing the release, it's really all about the end user IDE features. If you have any killer new features, please let me know ASAP. + + Thanks, + + Wayne + + [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=485299 + [2] https://projects.eclipse.org/releases/neon + + - Any others? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon Planning (and beyond) + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. + + + + - + \- Wasn't adding "build id" meant to do that? + \- IMHO, classic case of stating a solution, instead of the problem. + - + \- (Doug) IMHO, no. Let's not make sure this isn't a classic + case of not listening to the community ;). We've talked in the + past about giving up the names and using numbers, years or + otherwise. A number of people in the community are letting their + opinions be known, senior members of the community included. For + more information, check Tracy Miranda's blog and the ide-dev + list where much support was shown for her concerns including a + well thought out discussion of the alternatives. + - + \- To be explicit, I meant it is always better to state the + problem to be solved, rather than a solution, and then + everyone have their own interpretation of what problem it + solves. In [Tracy's + Blog](https://kichwacoders.com/2016/04/28/why-its-time-to-kill-the-eclipse-release-namesneon-oxygen-etc/) + and the [the one it + mentions](https://opensource.com/business/16/3/kill-off-extra-brand-names) + and the ide-dev mailing list thread, I have heard the + following problems mentioned: + + + + - + + - + \* Users do not know how old their install is + \* Users do not know there is are more recent release + - + \- They expect "update" would find it if there was a more + recent one + \* Users are confused by too many choices of packages ("which + one is for Java") + \* There are too many "brand names" (often in the form of + acronyms -- and more in the form of "release code names" -- and + now it has been proposed we add (not replace) even more + information in the form of dates) + + + + - + + - + \* So, my question remains, which problem(s) are we trying to + solve by adding dates? Does it do that without replacing "code + name" as originally suggested? + + + + - + + - + \* Also, is this for "EPP Only", as this [EPP Version + proposal](EPP/Version_Proposal "wikilink") implies? If so, then + the Planning Council does not need to be directly involved. It + is EPP's decision (though I know there is overlap and there is + no harm is us having a recommendation). + + + + - + + - + \* Also, which location of code names are we talking about? Or + where to add dates? We currently use "code names" in several + places: + + + + - + + - + \- Splash screen + \- About box + \- URLs (downloads, repositories, help) + \- Many web pages + \- Zip and tar filenames + \- Marketing materials and press releases + \- Plans and schedules + + + + - + + - + \* \[Do not read anything extra into me asking these questions + -- I like several of the ideas I've heard -- I am merely trying + to be explicit and set proper expectations of how much we can + solve.\] + + + + - + + - + \* There is not much documented in past notes, but from quick + search I found we discuss this topic about the same time of + every year: + - + \- + [March_16_2014](Planning_Council/March_16_2014.md) + \- + [March_04_2015](Planning_Council/March_04_2015.md) + + + + - *Had a long and winding discussion on this topic, but seemed to not + be consensus on a solution. There was agreement there was a problem, + but we were uncertain how large or widespread it was and how it + would trade-off with a "complete change". For example, would "code + name plus date" be sufficient, and provide an incremental change? Or + do we need to eliminate the code name completely from external + communications. The "original problem", some described, was new + users not even knowing that the "release code names" were + release/version code names, and somehow thought they were products + or packages in and of themselves.* + - ''The conclusion, for now, was to ask Wayne to drive getting more + "feedback from the community". Perhaps at Java One, perhaps a "quick + poll" on download page. He will discuss with Ian the appropriate + way. '' + +ACTION ITEM: Wayne to discuss with Ian on how best to get more data from +community of users. + +### old (ongoing) stuff + + - Should we change "maintenance" staging name now? for Mars.2? See . + + + + - + \- \[See also for unreleated additional URL.\] + + + + - + + - + \- Still "todo" item. (i.e. not done yet, apologies for delay) + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In M6 we changed to have (nearly) all features to be "root features. + Now what? + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **Impossible now, for Neon. Right? (for EPP Packages) Do we + still need "streamless-URL" now?** + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + Preferences, views, etc. have to "migrate" (if their ID + changes). + What testing would projects have to do? + May become "defacto requirement" once is implemented. + + + + - + *Seemed to be no objection to "trying it" and with Neon we will "try + it" by having the "streamless-URL" proposed in . For Neon, we will + not use that URL automatically anywhere but users can add it if they + would like. Will be interesting to see if many bug reports occur + from people trying that "update to next main release" (that is, from + Mars to Neon).* + +## Oxygen Planning + + - ? + +## New Business + + - Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + +## Next Meeting + + - On 5/31 decided to postpone the June 1 meeting by one week to June + 8th. + - June 8, 2016 - Regular First Wednesday Meeting -- last meeting + before release\! (Unless we find a need for another.) + +## Reference + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_05_2010(1).md b/wiki/Planning_Council/May_05_2010(1).md new file mode 100644 index 0000000..6faeb4c --- /dev/null +++ b/wiki/Planning_Council/May_05_2010(1).md @@ -0,0 +1,296 @@ +## Logistics + +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 05, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=05&day=5&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

Doug Gaff ???

Dsdp (PMC)

Anthony Hunter

Tools (PMC)

Oisin Hurley

Stp (PMC)

Y

Ed Merks

Modeling (PMC)

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

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)

+


+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.

+ + + +## Helios + +### Next Year's Name + +Should we do over? + + - + evidence of ballot stuffing invalidates what we thought we knew + we don't literally know extent of the problem, but it is likely to + be, at least, "in the hundreds" + cons: delay, toil, and trouble + +Concretely, I propose following. Any counter proposals? + + - Do over, start with original list, requiring log in (same as + bugzilla log in). + - But do quickly, 1 week for first pass, to 5/12. 1 week for second + pass, if needed, to 5/19. + - Please review (and give a test vote at) [sample test + page](http://www.eclipse.org/webtools/development/test/testpoll.php) + - Present to community as follows, on original bug, and committers + mailing list (please review and give comments at meeting. Does it + have right tone?) + +
+ +Help name the 2011 Eclipse Simultaneous Release -- again\! + +As previously stated, the Eclipse Planning Council is trying to come up +with a name for next year's Simultaneous Release and is asking for input +from the Eclipse Community. Accordingly, we collected suggestions for +names, and then set up a quick poll to get some quantifiable data about +preferred names. + +But, it has come to our attention that some people voted more than once. +More specifically, many many many times, as if from a script. While our +polling service was known not to be secure, we naively assumed people +would participate in the spirit of a friendly close-knit community. +Unfortunately, we do not know the full extent or pattern of the "ballot +stuffing" since the polling service was not set up to track such detail. +Nor could it, without a unique log in. So, we have enhanced the polling +service to require a log in ... same as bugzilla account ... and would +like to try again to collect some meaningful data about what name the +community prefers. We do care about the community's opinion and felt it +would be a disservice to not re-do the polling in a more accurate way. +The end result might be similar to the polling we just went through ... +or, might reveal a completely different preference, when everyone just +votes once. Since we are already late in the development cycle, we will +allow only one week for voting, to May 12th for the first phase, and +then until May 19th, if a runoff vote is required. + +You can read more about it and vote at this URL: + + +And read the back ground, and pros and cons of the candidate names at + + +Thanks, + +
+ +Reference: + +Reference: [proposed, culled naming +list](April_07_2010/Proposed_Naming.md) for +voting. + +### Any exceptions to note, or discuss? + + - + ? + +### Maintenance Schedule + +Fourth Friday of September? 9/24/2010 + +Fourth Friday of February? 2/25/2011 + +### Next Year's Schedule + +Not ready to discuss details, but the problems with +1, +2, +3 category +(and short times) should be well discussed. + +Similarly, Oliver brought up issue with need for better "warm-up" +rhythm, especially if a prereq project is late. (EMF's "last minute" M6 +delivery added pressure to TPTP's ability to build/test in time). No +specific actions, process or remedies are known, but ... maybe a +reminder to cross-project list that intermediate or warm-up builds are +good (especially if going to be near deadline). + +### Cross-Project Teams + +#### Aggregation + +[Planning Council/Cross Project +Teams/Aggregation](Cross_Project_Teams/Aggregation.md) + +#### Tracking progress and compliance + + - + Work on [Summary + page(s)](http://eclipse.org/helios/planning/SimultaneousRleaseOverview.php) + has started. + + + + - + [Planning Council/Cross Project + Teams/Tracking](Cross_Project_Teams/Tracking.md) + +## Other business + + - +## ToDo Items + +## Next Meeting + + - + [June 2, Wednesday](June_02_2010.md), Noon + Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_06_2009.md b/wiki/Planning_Council/May_06_2009.md new file mode 100644 index 0000000..b9c361a --- /dev/null +++ b/wiki/Planning_Council/May_06_2009.md @@ -0,0 +1,168 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 06 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=5&day=6&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| ----------- | +| width="30%" | + +| | | +| -------------------- | --------------------------------- | +| Chris Aniszczyk | | +| Cedric Brun | Y | +| Oliver Cole | | +| Stefan Daume | Y | +| Brian Fitzpatrick | | +| Bjorn Freeman-Benson | | +| Doug Gaff | | +| Neil Hauge | | +| Mika Hoikkala | | +| Anthony Hunter | Cannot attend today (on vacation) | +| Oisin Hurley | | +| Markus Knauer | | +| Christian Kurzke | | +| Gary | | +| Ed Merks | | +| Mike Milinkovich | | +| Philippe Mulet | | +| James Saliba | | +| Georg Schmidt | | +| Karsten Schmidt | | +| Thomas Watson | | +| David Williams | | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Status of Naming next year's release (Thanks Oliver). + + + + - + + - + See the [doodle poll](http://www.doodle.com/fqkqrc6nqzfby7ni) + Vote to conclude on May 15. + Let's discuss before final decision? (at meeting on 20th?) + + + + - Build update + + + + - + + - + Transitioned to "BuckyBuilder" (Thanks Thomas) + Is now (partially) a composite site (implies more + responsibility/coordination from 'Eclipse Platform'). + "New" requirement to use Java 5 for running pack200? + + + + - Do we need a sign-off page? + + + + - + + - + Or just expect people to post exceptions or delays? + + + + - See + [Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") + and + [Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + + + + - + + - + Are you happy with "must do" compliance? + Happy with what's building? + - + Swordfish should be in today. + Some haven't been installable (from update site, such as + PHP). + + + + - Previous Meeting Notes + + + + - - Accessibility + + + + - + + - + Karsten (re) raised concern about the accessibility issue, and + that so many of that "should do" items had no comment or status. + ACTION: I offered to send reminder to cross-project list. (done) + + + + - - Babel's deadlines + + + + - + + - + Tom asked about Babel's expectations and deadlines. + ACTION: Since none of us knew, Tom will ask on Babel's + newsgroup, and get back to Planning Council. + Any news? + + + + - - Weekly build meetings? + + + + - + + - + When, How, Who to have bi-weekly "build team" meetings? + Oisin may follow-up with note to cross-project list with a a + proposal. + Any news? need? + + + + - Next Meeting + + + + - + + - + Regularly scheduled one on first wed. of June + Do we need one before, say May 20th? + +## Reference Links + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) \ No newline at end of file diff --git a/wiki/Planning_Council/May_06_2015.md b/wiki/Planning_Council/May_06_2015.md new file mode 100644 index 0000000..4a70c02 --- /dev/null +++ b/wiki/Planning_Council/May_06_2015.md @@ -0,0 +1,532 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 6, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (Acting)

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel (Sam Davis)

Mylyn (ALM) PMC

D

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Y

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Neon is Mars+1 name\! + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Mars Planning + + - Any issues? + +## Progress on Action Items + + - Improving user experience in finding right function to install. For + latest ideas, see + + + + - + + \- Create a Marketplace for the simultaneous release. + + *Overall, would be "driven" by Eclipse Foundation, but they would + need help from top level projects, and the Planning Council.* + + For the latest ideas, see [Wayne's recent note to mailing + list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02416.html). + +## New Business + +### Do we need to improve wording in [Policy of new projects joining in SR's](SimRel/Simultaneous_Release_Policy_FAQ "wikilink") + + - + \- Its original intent was to say "Yes, new projects and features + can join SRs" -- without requiring Planning Council exception, if + they meet the requirements set out in that policy. + + + + - + \- But, as we clarified some wording/sections, especially the one + about "no major releases", intended to avoid breaking API changes + (for train, and adopters), that seems to be oriented towards only + "new features", but, in a way, rules out "new projects" (since, by + technical definition, would be a "major" version change from + "nothing" to "1.0.0"?) But, I do not believe was the intent. After + all, if it is completely new API, it would hardly have the ability + to break anyone (at least, at API level ... "fitting in" and not + breaking anyone, was the purpose of "getting into SR early". + + + + - + \- Is this confusing? Should wording be clarified? + +*No wording changes at this time ... especially given subsequent topic.* + +*Also said I wanted to add "features" explicitly to "must sign plugins", +and there was no disagreement. (They are never checked at runtime, since +they are not Java code, but are checked during installation -- best to +confirm that empirically).* + +### Continuing Discussion of if or how to change "yearly release"? + +#### History + + - + \- Review of original motivations and problems solved by current + process and schedule. + - + \-- Contrasting "styles" of "releases": Our yearly release was + intended to be rock-solid release, that commercial adopters + could count on being released on a predictable time, with a + predictable level of quality -- so that their own money-making + support processes would be predictable, and long term. + \-- Another style: Some OS Projects like to have a "release" + very frequently, typically at semi-random times, and often very + frequently (from "weekly") to "several months"). Notice the + parallel to our "I-builds" and "Milestone (Stable) builds). + - + \--- These releases are typically done when either + "significant bugs in previous release had been fixed" or + \--- There had been "enough new features added" that "things + were ready"). + \-- An interesting (casual) observation: when these "frequent + release" OS Projects were largely driven by a "service" + organization, there is often one "release" (perhaps a year old, + or so) that is the one (and only) one that they offered service + contracts for ... which parallels our own yearly releases. (In + other words, they use the word "release" to have more than one + meaning.) + + + + - \- Given the above, our "solution" was to provide a (voluntary) + Simultaneous Release train once per year, while at the same time, + emphasizing that individual projects could still release whenever + they wanted. + + + + - \- Short review of "pre-Callisto" days, to avoid repeating past + mistakes; (Names and examples are a fictional melding of several + cases). Platform released in June. TPTP and CDT a month or two + later, WTP a month or two later. Only at that time, was a bug + discovered in the Platform (by WTP nearing release) such that they + could not release until SR1. Platform releases SR1 in September, WTP + can now release. Only then was it observed that some regression was + introduced that prevented CDT from working with the Platform SR1. + So, CDT might hurry up with their SR1, or adopters would all have to + patch a mix and match of components to make their product schedule. + In the end, adopters could come up with a product, but it was pretty + unlikely users could install other things from Eclipse into it, + since there was no "standard" release to build on top of. Similar + problem for other plugin providers, inside and outside Eclipse ... + it was hard to find a stable, consistent set of things that "worked + together", and even when they could, imagine the instructions to the + end users on how many update sites to go to, getting precise + versions of things (might be most recent, but might be down level) + all to "make something work" ... and then no confidence that other + things would work with that collection. So, it was thought "same + schedule" and "one update site" was a good start at solving these + early problems. + + + + - \- Much has changed since those pre-Callisto days (such as rate of + change has slowed) but ... that the principle is the same and is + still valid. + + + + - \- One reason, originally, that we had "integration over many + milestones" as \*the\* key requirement (it was the only requirement, + nearly, in Callisto) was A. to find bugs in OTHERS code (for + example, some change in the Platform might not be reproducible if + using only the Platform, but it would easily prevent WTP from + working correctly, and if discovered "late", then there would be no + time to fix it before the planned release date. B. Many of the bugs + found in this situation are subtle, due to the many "interacting + components" (even though only 20 or so, during Callisto). No one + could possibly find them during any sort of quick smoke test, or + even a few weeks of "testing one component"; but only when used in + "real life" use-cases and workloads ... and we are gratefully to our + community of early-adopter users, for trying to do just that, and + providing that valuable feedback over a period of many months. + + + + - \- The other, "checklist" requirements have been added to or changed + over the years for some items. These typically fall into categories + of "minimum" to-do items, to work in one repository, without making + us look silly (or, security related) and then also into a category + of things that allow better adoption by other projects and + commercial adopters. + +#### The Future + +##### Statement of Problem + + - There is some (ongoing) concern that "we" (the Eclipse Foundation) + need ability to "release more often" or "with very short cycle". + Some have mentioned "once every 6 months". Some, in the past, have + said "once a year is too frequent, and should be once every two + years" (as LTS was originally proposed to support \[current policy + is a little less formal, mostly "any SR2" and sometimes even SR1, as + I understand it\]). And, some projects want (or, do) release every + month or two (especially new projects). How can we be "all things, + to all people"? (Or, at least, get much closer than we are now). + + + + - Our [Policy of new projects joining in + SR's](SimRel/Simultaneous_Release_Policy_FAQ "wikilink") was + intended to be one step in that direction. (And, at first, many said + that was enough ... that satisfied needs, that I could even take the + on-going discussion off of the agenda \[reference\] ... but now ... + + + + - + + - + \-- Some have mentioned "the timing" is still not right, and + need something between SR1 and SR2. + \-- Some have mentioned that "SR" (Service Release) is the wrong + name, if it is going to contain new projects and new features. + (And, not sure if it is that incorrect 'SR' naming, but it does + seem it is a widely misunderstood policy -- by even Planning + Council members. + - + \--- We discussed naming in previous meeting \[find + reference\]. + + \- The EPP packages have been so successful, that some now believe + that a project "releasing when ever it wants to" does not mean + anything (or, much) ... it only means something if EPP can release + when ever it wants to. + + - + \-- Similarly, it is hard for a project to "update" just their + one component in an EPP package, for part technical, and part + policy reasons. + + + + - The EPP packages have been so successful, that "everyone" wants to + be in an EPP package -- so much so, they are nearly a marketing + tool. + + + + - + + - + \-- Off topic, maybe, but this is oddly parallel to early days, + when "everyone wanted to be in the Platform" since that was the + "main thing" at Eclipse, that everyone installed. Are we now + seeing the same thing happen to EPP packages? Are non-EPP + components second class citizens? That was never the intent. The + EPP packages were meant to merely provide a better "out of the + box" usability experience, oriented to certain audiences, but it + was expected that users could and should still "customize" that + by adding what ever other function they'd like. + \-- The "Simultaneous Release" repository was intended (in part) + to make it "easier to discover things" that were available, + instead of having to "look all over the place". + - + \--- Probably several reasons why that's not working too + well? + \--- And now we also have "The Market Place" -- yet another + place to look? Or, satisfying needs of a certain class of + user? (I think the latter). + \-- Should we avoid having too much in EPP packages? Or, put in + as much as we can? \[Without usage statistics, it is impossible + to know.\] + \-- The "capabilities" mechanism in the Platform was also + supposed to help make things easy to progressively discover, but + it never caught on. + + + + - Leaf versus Core: we currently do not have a good separation of + "leaf" vs "core" component -- and perhaps this is not possible. It + could be argued it is easier for a "pure leaf" component to + update/release more frequently, than "core" components, since they + would have less chance of breaking others in release train. But, + they could, still break adopters (and in theory still break core + components functionality, due to the nature of "plugins and OSGi". + There are often "tangled" relationships making the distinction + between "leaf" and "core" multi-faceted instead of a clear binary or + hierarchical distinction. + +##### Possible solutions + + - See Doug's [mailing list + post](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02418.html) + for one approach. + +##### Constraints + + - Developers work load + - IP work load (and work flow) + - Marketing + +##### What is required for (any) solution? + + - Improved automation + + + + - More "self service" + + + + - More automated testing + +### high level outline of discussion + + - Seemed to be rough agreement that to "release more frequently" would + be good ... for projects and perception. + - Was discussion that "6 per year" too many ... "2 per year" not + enough. So settled on "4 per year" as a working assumption. + +:\* Did not really discuss WHEN they would be (which months), but (I +think) general agreement they should be regular, and predictable. + +:\* Did not really discuss what to call them. We want to convey they are +true releases, but, releases with no subsequent service release. + + - "SR" name especially bad for perception, since it is not really just + "service releases" any more. + - But, even if we had 4 releases per year, some might put in "just + service", some might put in new features, so adds some complexity on + what and how to communicate (with each other, and community). + - We would always (still) need "two streams" going ... one for "next + immediate release", ... another stream for "long term work". (Or, + may vary by project?) + +:\* We did NOT discuss how to manage that ... would "long term work" be +merged into "release" stream at certain points? + + - We would (still) want something like a yearly "LTS Release". + - We did say it would take at least 2 months for us to have a concrete + proposal. + +## Next Meeting + + - June 10, 2015 - Regular First Wednesday Meeting -- last meeting + before release\! + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_07_2014.md b/wiki/Planning_Council/May_07_2014.md new file mode 100644 index 0000000..cc80ab1 --- /dev/null +++ b/wiki/Planning_Council/May_07_2014.md @@ -0,0 +1,366 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 7, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Reminder: [deadlines and + dates](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10265.html) + for Luna CQs, Reviews, etc. + +## Previous meeting minutes + + - + + - + Let's discuss "EclipseCon meeting" -- as final topic today -- + any "actions" for Planning Council to track? + + [EclipseCon face-to-face](March_16_2014.md) + + [Previous "first Wednesday" + meeting](April_02_2014.md) + + + + - + *- Briefly discussed "patched packages" effort, if anyone had any + sense if used/appreciated by community (i.e. was it a success?). + Markus noted there was approximately 20K downloads, which is small + compared to "main release" ... but ... such numbers are hard to + interpret (i.e. the 20K might be a very important group of Eclipse + community ... hard to know ... but, no doubt at least many people + appreciated having them).* + + + + - + *- I mis-reported the number of "java8patch" downloads, directly + from Eclipse Project repository. As of today, there has been roughly + 13000, not the "1000" I mis-reported during meeting.* + +## Luna Planning + + - + Any issues with M7? RCs? + + + + - + *None known other than BIRT* + +## Mars Planning + + - + Any early issues? + + + + - + + - + *Briefly discussed if we are meeting diverse needs of community. + Some indication that some adopters (still) want **pure** service + releases ... while others (especially individual users) want + "latest and greatest", even if contains some regressions or new + bugs.* + + + + - + + - + *No in depth discussion, but some did note issues of how/if IP + Process would have to change (say, to have monthly "releases"), + some noted that "pure service releases" are important to some + adopters "internal processes" of producing products (i.e. they + may have one process for "bug fixes only" another process for + "new features"). Some also wondered if "new feature releases" + are that common, since often to accomplish that, it depends on + multiple projects cooperating ... say, for hypothetical example, + perhaps the Platform needs to change/add an API, for someone + else to implement a new feature and it's (relatively) rare that + project's goals/objectives all line up (on a frequent, such as + monthly, basis). Though, it is obvious that "new projects" such + as EGit, etc., can often add new features independent of what + others do.* + + + + - + + - + *I believe to make any progress on "doing things differently" we + need to better define what "continuous release" means, for a + large collection of Open Source projects ... Its very different + from how a corporation might define it (where they can strictly + define processes that everyone must follow) and different than + how one Open Source project might define it (such as some, make + a distinction between a "release" that has no maintenance (other + than the next release), and only occasionally define one of + those as a "long term support" release, which would get + maintenance (only) -- and similar statements about "API" ... + perhaps no solid API in "short lived" releases, but strict API + in long term releases. So ... discussion to continue. Any + volunteers to draft a straw-man definition of terminology for + Eclipse releases?* + + + + - + + - + ''Very briefly discussed - Consider banning contribution of + mutable repositories. I think everyone was sympathetic to the + issue, but some weren't sure if it was "that big of a deal" for + milestones, etc., which I think have since been answered in bug. + I expressed my own reservations about "caches" and "locks" (but + not my concerns about use of words such as "ban" -- tools not + rules) ... but am happy that others are finally having some + similar concerns that I've long had -- which we discuss at least + every year -- and so far much resistance to "doing extra work", + but sounds like some are willing to invest in tools to make it + easier. I'll comment in bug soon (but ... I think I should do + one of my action items below first. :) '' + +## Progress on Action Items + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (dw -- no formal progress)\] + +## New Business + + - ? + +## Next Meeting + + - June 4, 2014 - Regular First Wednesday Meeting (Our last meeting of + "Luna" cycle) + - \[Proposed} No meeting in July? + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_20_2009.md b/wiki/Planning_Council/May_20_2009.md new file mode 100644 index 0000000..07590d9 --- /dev/null +++ b/wiki/Planning_Council/May_20_2009.md @@ -0,0 +1,205 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, May 20 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=5&day=6&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + +| | +| ----------- | +| width="30%" | + +| | | +| ----------------- | - | +| Chris Aniszczyk | | +| Cedric Brun | Y | +| Oliver Cole | Y | +| Stefan Daume | Y | +| Brian Fitzpatrick | Y | +| Wayne Beaton | Y | +| Doug Gaff | R | +| Neil Hauge | Y | +| Mika Hoikkala | | +| Anthony Hunter | Y | +| Oisin Hurley | Y | +| Markus Knauer | Y | +| Christian Kurzke | | +| Gary Xue | Y | +| Ed Merks | | +| Mike Milinkovich | | +| Philippe Mulet | | +| James Saliba | | +| Georg Schmidt | | +| Karsten Schmidt | Y | +| Kaloyan Raev | Y | +| Thomas Watson | Y | +| David Williams | Y | + +Note: feel free to correct any errors/omissions in above +attendance record. + +## Topics + + - Conclude Naming next year's release (Thanks Oliver). + + + + - + + - + See the [doodle poll](http://www.doodle.com/fqkqrc6nqzfby7ni) + And especially last few comments in + [bug 271054](https://bugs.eclipse.org/bugs/show_bug.cgi?id=271054) + + + + - + + - + Helios. The runner up was Halley. (in case EMO Legal review + finds issue with Helios). + + + + - PC Decision on Categories in Discovery Site + + + + - + + - + Business Intelligence: See + [bug 275392](https://bugs.eclipse.org/bugs/show_bug.cgi?id=275392) + + + + - + + - + PC decide B I R C was ok (best we could do, this year, but + subject to change next year, as they all are). + + + + - + + - + DSDP Category name change: + [bug 277006](https://bugs.eclipse.org/bugs/show_bug.cgi?id=277006) + + + + - + + - + PC didn't like the exact proposal. Will comment in bug, and + await reply. + + + + - + + - + Good, brief discussion on this topic in general, for next year. + May want to be more creative and consider multilevel categories, + wizards that could help narrow interests (and "include source" + checkbox choice), should also better represent _the_ packages + that are available from EPP (e.g. "RCP Developer"). + + + + - PC Position on off-cycle releases and use of discovery site (and + EPP)? This came up in discussions about a Pulsar package. + + + + - + + - + Conclusion: we do not want to support off-cycle releases. But + with following compromise: If a project still met all the normal + "release criteria" set forth as must-do's by PC then they could + introduce something new during SR1 or SR2 (that is SR1 and SR2 + can have more than service, if important, and must-do criteria + met). The reason for not supporting things off cycle was a. it + is more work to support it, b. there is no opportunity for + "simultaneous release" testing, c. it would dilute the meaning + of "simultaneous release". + + + + - Review [project + status](http://www.eclipse.org/projects/galileo_status.php) and + determine actions to take. + + + + - + + - + Are we happy with "must do" compliance? + Judging from items not marked, it appears these are the projects + of worst quality (or, worst adopter readiness?): + + + + - + + - + EMFT 20 + PDT 15 + CDT 14 + MAT 13 + MDT 10 + + + + - RC1 update + + + + - + + - + Done yet? + + + + - Next Meeting + + + + - + + - + Regularly scheduled one on first Wednesday of Month: June 3, 12 + Noon Eastern + + + + - + + - + Upcoming topics + - + Frequency and dates of maintenance builds + Dates for next year's project plans + - + Wayne volunteer to check how done in past, and if Board + or EMOD had any critera (and the answer was "no", up to + PC). + Build schedule for next year (start with M1) + +## Reference Links + +[Galileo Simultaneous Release](Galileo_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") +and +[Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/May_2_2018.md b/wiki/Planning_Council/May_2_2018.md new file mode 100644 index 0000000..928926b --- /dev/null +++ b/wiki/Planning_Council/May_2_2018.md @@ -0,0 +1,218 @@ +## Logistics + +**Pay attention time has changed, the meeting is one hour earlier than +before** + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 2, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Photon & Oxygen status + - Post Photon SimRel status + +## Attendance + +Aleksandar Kurtakov, Dani Megert, Mikael Barbero, Sam Davis, Ed Merks, +Thomas Watson, Nick Boldt, Wayne Beaton, Martin Lippert + +Regrets : Frederic Gurr + +## Notes + +Everyone aggreed with the fact that the monthly Planning Council call +will occur now every month the first wednesday at 11:00 EDT. + +### Photon status + +Amalgam on cross project proposes today to contribute a 1.8.0 instead of +2.0.0, Wayne will answer and update the Photon page accordingly. + +Fred could not attend the call so there is no much status, but Mikaël +will check tomorrow with him & report back to the mailing list. +Everything seems to be in good shape. + +### Post photon status + +During last call,discussing the bugzilla \#532220 the Planning Council +concluded that the naming must be inclusive enough. It was decided to +use the following pattern for the name : Eclipse YYYY-MM. Wayne +explained that this decision violates the trademark usage guidelines. It +is impossible to just use names like "Eclipse YYYY-MM". "Eclipse" needs +to be used as an adjective to conform to the guidelines. + +Discussing the name leads us to discuss the role of the Palnning Council +in the future and the existence of only one Simultaneous Release. It +already exists 3 differents simultaenaous release today : + + - The classical SimRel + - The Science woring group SimRel + - The Polarsys SimRel + +The Science and Polarsys ones are not as visible today as the classical +one which leads most of people thinking that it exist only one. + +In private previously to the call Wayne & Mélanie discussed the fact +that they would like to revitalize the Planning Council. Wayne explained +during the call that he will launch an initiative to integrate new +members & generalize the Simultaneous Release Process. These new members +would be from different parts of the Eclipse community : Science, IoT, +JakartaEE... Wayne explained that there is some notion of SimRel +(software repos, regular milestones, RCS, communication...) that other +could be interested in, and today we know how to do it. The purpose +would be to generalize some aspects of the simultaneous release by +creating something like an "Eclipse Simutlaneous Release Process". +Eclipse SimRel docs exists for years, needs to be reviewed as some part +are very specific relative to p2 but it is a good starting point. + +Tom noted that the role of the planning council would be a mentoring +role for the different committees. + +Wayne answered that we need to figure out what that looks like : + + - The planning council meets as whole less frequently (quarterly) with + the role to lead the process & supervise the different committees? + - Separate committees which meet more frequently (monthly) to organize + their SimRels (schedule, reject/remove projects, participate on + communication on cross-project...)? + +A subset of actual Planning Council members would participate in the +different instances. + +After this clarification about the future of the SimRel, the discussion +about the naming started : + Ed asked where +this name appears? Where is it relevant ? + + - In all communication + - Plans + - URLs + - Splash screen (it should not a date would be enough + +In the end it exists few places where this name should appear and +propose to call it SimRel. + +Dani answered that it feels as SimRel is a stupid name and that we +should just keep the date without Eclipse, it would be inclusive or +exclude everybody. SimRel is a notion used internally for work +coordination but not a end-user notion. It should appear in no UI, nor +spalschscreens, just on wikipage and emails, just use the date on splash +screens. + +Ed noted that the name would be used for the wikipage and so just a date +would not be sufficient and so that we need a label. + +As the Simrel would become X SimRel we should find a more descriptive +name which describe for each what they are. + +IDE or Developper tools, IDE SimRel were proposed. But the reality of +the community is that it exists 4 different IDEs : the original one, +Che, Orion, Theia... We should find a new name for the classical IDE +part : Desktop (some other IDEs are also desktop ones), Eclipse S... + +In the end, as it is impossible to find a good descriptive name for the +actual SimRel, it was decided to call it : Eclipse SimRel YYYY-MM. This +will not appear anywhere, just used for work collaboration and so pages +on the wiki the pages would be under SimRel/. Everyone were okay with +this name and the fact that this would be rediscussed in the future when +the different committees & SimRels would be created. + +Mélanie started to put the dates for the September release in the Google +Calendar, the Planning Council will validate those dates. The proposed +schedule is : **Eclipse 2018.09** + +| | | | | | | | +| -------------- | ------------ | ------------ | ------------ | ---------- | --------- | -------------- | +| | \+0 Frid. | \+1 Mon. | \+2 Tues. | \+3 Wed. | EPP Thur. | Available Fri. | +| M1 | 13/07 | 16/07 | 17/07 | 18/07 | 19/07 | 20/07 | +| M2 | 03/08 | 06/08 | 07/08 | 08/08 | 09/08 | 10/08 | +| M3 | 24/08 | 27/08 | 28/08 | 29/08 | 30/08 | 31/8 | +| RC1 | 31/08 | 03/09 | 04/09 | 05/09 | 06/09 | 07/09 | +| RC2 | 07/09 | 10/09 | 11/09 | 12/09 | 13/09 | 14/09 | +| 2018.09 (“GA”) | quiet: 14/09 | quiet: 17/09 | quiet: 18/09 | GA : 19/09 | \- | \- | + +\- - + +Wayne will work on getting a better engagement from other part of the +community by bringing fresh blood from new Strategic members and PMCs. +He will also add a comment on the Photon N\&N bugzilla to communicate +the cadence change after Photon. He will create a new one to get the +actual implication of this change for the community. \ No newline at end of file diff --git a/wiki/Planning_Council/May_8_2013.md b/wiki/Planning_Council/May_8_2013.md new file mode 100644 index 0000000..c9df3ad --- /dev/null +++ b/wiki/Planning_Council/May_8_2013.md @@ -0,0 +1,353 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, May 08, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

N

John Arthorne

Eclipse (PMC)

N

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

N

Doug Schaefer

Tools (PMC)

N

Bob Brodt substituting for Adrian Mos

SOA (PMC)

Y

Ed Merks

Modeling (PMC)

N

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

N

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker (with Kaloyan)

SAP AG (Strategic Developer)

Y

Igor Fedorenko

Sonatype (Strategic Developer)

N

Markus Knauer

Innoopract (Strategic Developer)

R

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

N

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 members: + + + + - + Rajeev Dayal, Google (Strategic Member rep) + Stephan Merker, SAP AG (Strategic Member rep) + Chuck Bridgham: WTP PMC (PMC rep) + +*Welcomed new members, and Stephan and Chuck introduced themselves. Many +thank to Kaloyan for his years of service on the Council.* + + - Critical IP/review dates announced. + + + + - + For details, see [this cross-project post from + Wayne](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08897.html). + In brief, + - + May 24/2013 - Deadline to submit IP Logs for Kepler releases + June 5/2013 - PMC-approved Review materials submitted to EMO + June 12/2013 - Kepler Uber Release review + June 26/2013 - Kepler release + Make sure the projects you represent [subscribe to cross-project + list](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08898.html). + - + If you need a "how to" reminder, see [the general Eclipse.org + mailing list page](https://dev.eclipse.org/mailman/listinfo) or + [the specific cross-project + page](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev). + +*Wayne added other reminders, that there will be renewed vigor in making +sure projects have project plans, valid websites, operate in an +open-transparent way ... and in some cases this means Wayne will involve +the PMCs more (who, after all, are responsible for their projects) so +... Planning Council reps, do what you can to remind/monitor the +projects you represent.* + +*From Wayne's observations, there are two projects that participate in +Sim. Rel., but don't subscribe to cross-project list: DLTK, and Eclipse +Runtime Project (both Technology Projects).* + +## Kepler + +### M7 and "end game" + + - Issues? + + + + - Be aware that EGit is moving to "3.0" in M7. + +''Build currently broken . Some "compatibility issues" being ironed out. +(Forgot to mention during meeting, but Markus communicated with me +before the meeting, that EPP builds are "looking better" ... so, maybe I +can sleep again :) '' + +## EclipseCon face-to-face follow-through action items + +For original meeting notes, see +[March_24_2013](Planning_Council/March_24_2013.md) +and for discussion leading to action items, see +[April_10_2013](Planning_Council/April_10_2013.md). + +#### Policy on new releases joining SR + + - + dw to update current policy on new releases joining SR in Policy + FAQ. Done. See [Policy + FAQ](SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F "wikilink"). + +#### Build reproducibility + +dw to come up with "perfect example". Add to wiki, send to Wayne and +Than, and see if some way "CBI" maven task could produce, from template, +as part of build output. + +dw better educate. Give perfect example on wiki. Emphasize non-changing +repos. Give "acceptable" example on wiki. Give "unacceptable" examples +on wiki. + +dw create "report of changes" from one build to another, one repo to +another, so a) individual projects could see if things changed when they +should not have; b) PMCs, Team Leads, Planning council could better +observe "big picture" of how much change there was, especially related +to changes in build input files. + +dw start to tag build file project, each build (so we could diff build +files). + +wayne to add item to release review that "there must be a retention +policy" (it should cover how long repos stay around, such as milestone +repos, and also via ?education? emphasis that it must be +"non-changing".) And then Planning Council can add extra rules for sim. +release, if necessary. + +#### Release train rules documentation + +John and Neil volunteered to improve. The idea is to provide briefer +version, but still (probably via hyperlinks?) allow readers to find out +"reasons" for a rule. This would be for Luna (due in Fall, after Kepler +release). + +#### Release train rhythm + +Wayne volunteered to add suggestion/idea to GSOC database to make some +user friendly way that users could say "I want to follow beta releases" +... this would add the "current" development stream URL to update sites, +so they'd get updates from milestones, without having to know about it, +and manually add it. + +### Orbit + +The Orbit Project Lead (dw) agreed to a plan for a plan ... a plan will +be created after Kepler release, by end of August (since July often a +"slow" month) ... and implemented in the months after that. + +## Next Meeting + + - June 5, 2013 - Regular First Wednesday Meeting - our last before + release + - July -- No meeting in July - we will be relaxing after release + - August 7, 2013 - Regular First Wednesday Meeting ... almost time for + SR1\! + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Meeting_Archives.md b/wiki/Planning_Council/Meeting_Archives.md new file mode 100644 index 0000000..944bee0 --- /dev/null +++ b/wiki/Planning_Council/Meeting_Archives.md @@ -0,0 +1,156 @@ +## Planning Council Meeting Notes Archives + + - [December 6, 2017](December_6_2017.md) + - [November 2, 2017](November_2_2017.md) + - [October 4, 2017](October_4_2017.md) + - [September 6, 2017](September_6_2017.md) + - [August 2, 2017](August_2_2017.md) + - [June 7, 2017](June_07_2017.md) + - [May 3, 2017](May_03_2017.md) + - [April 5, 2017](April_05_2017.md) + - [March 1, 2017](March_01_2017.md) + - [February 1, 2017](February_01_2017.md) + - [January 4, 2017](January_04_2017.md) + + + + - [December 7, 2016](December_07_2016.md) + - [November 2, 2016](November_02_2016.md) + - [October 5, 2016](October_05_2016.md) + - [September 7, 2016](September_07_2016.md) + - [August 3, 2016](August_03_2016.md) + - July 6, 2016 -- no meetings in July, since just released, and + holidays + - [June 8, 2016](June_08_2016.md) + - [May 4, 2016](May_04_2016.md) + - [April 6, 2016](April_06_2016.md) + - [March 2, 2016](March_02_2016.md) + - [February 3, 2016](February_03_2016.md) + + + + - [January 6, 2016](January_06_2016.md) + - [December 2, 2015](December_02_2015.md) + - [October 7, 2015](October_07_2015.md) + - [September 2, 2015](September_02_2015.md) + - [August 5, 2015](August_05_2015.md) + - July 1, 2015 -- no meeting, since just released, and holidays + - [June 3, 2015](June_03_2015.md) + - [May 6, 2015](May_06_2015.md) + - [April 1, 2015](April_01_2015.md) + - [March 4, 2015](March_04_2015.md) + - [February 4, 2015](February_04_2015.md) + - [January 7, 2015](January_07_2015.md) + + + + - [December 3, 2014](December_03_2014.md) + - [November 5, 2014](November_05_2014.md) + - October 1, 2014 - no meeting, since no agenda + - [September 3, 2014](September_03_2014.md) + - [August 6, 2014](August_06_2014.md) + - July 2, 2014 - no meeting + - [June 4, 2014](June_04_2014.md) + - [May 7, 2014](May_07_2014.md) + - [April 2, 2014](April_02_2014.md) + - [March 16 2014](March_16_2014.md) -- Sunday + 2-4, EclipseCon Meeting + - [March 05, 2014](March_05_2014.md) + - [February 05, 2014](February_05_2014.md) + - [January 08, 2014](January_08_2014.md) + + + + - [December 11, 2013](December_11_2013.md) + - [November 6, 2013](November_6_2013.md) + - [October 2, 2013](October_2_2013.md) + - [September 4, 2013](September_4_2013.md) + - [August 7, 2013](August_7_2013.md) + - July 3, 2013 - no meeting + - [June 5, 2013](June_5_2013.md) + - [May 8, 2013](May_8_2013.md) + - [April 10, 2013](April_10_2013.md) + - [March 24, 2013](March_24_2013.md) - Sunday + 2-4, EclipseCon Meeting + - [March 06, 2013](March_06_2013.md) + - [February 22, 2013](February_22_2013.md) + - [February 06, 2013](February_06_2013.md) + - January 2, 2013 - no meeting + + + + - [December 05, 2012](December_05_2012.md) + - [November 07, 2012](November_07_2012.md) + - [September 05, 2012](September_05_2012.md) + - [August 01, 2012](August_01_2012.md) + - [June 06, 2012](June_06_2012.md) + - [May 02, 2012](May_02_2012.md) + - April 4, 2012 - no meeting + - [March 25, 2012](March_25_2012.md) - Sunday + 2-4, EclipseCon meeting + - [March 07, 2012](March_07_2012.md) + - [February 01, 2012](February_01_2012.md) + - [January 04, 2012](January_04_2012.md) + + + + - [December 07, 2011](December_07_2011.md) + - [November 23, 2011](November_23_2011.md) + - [November 09, 2011](November_09_2011.md) + - [October 05, 2011](October_05_2011.md) + - [September 07, 2011](September_07_2011.md) + - [August 03, 2011](August_03_2011.md) + - [June 01, 2011](June_01_2011.md) + - [May 04, 2011](May_04_2011.md) + - [April 06, 2011](April_06_2011.md) + - [March 20, 2011](March_20_2011.md) + EclipseCon Meeting + - [March 02, 2011](March_02_2011.md) + - [February 02, 2011](February_02_2011.md) + - [January 05, 2011](January_05_2011.md) + + + + - [December 01, 2010](December_01_2010.md) + - [November 10, 2010](November_10_2010.md) + - [October 6, 2010](October_6_2010.md) + - [September 15, 2010](September_15_2010.md) + - [August 18, 2010](August_18_2010.md) + - [August 04, 2010](August_04_2010.md) + - [July 07, 2010](July_07_2010.md) + - [June 02, 2010](June_02_2010.md) + - [May 05, 2010](May_05_2010.md) + - [April 07, 2010](April_07_2010.md) + - [March 21, 2010](March_21_2010.md) + - [March 03, 2010](March_03_2010.md) + - [February 03, 2010](February_03_2010.md) + - [January 06, 2010](January_06_2010.md) + + + + - [December 02, 2009](December_02_2009.md) + - [November 04, 2009](November_04_2009.md) + - [October 07, 2009](October_07_2009.md) + - [September 02, 2009](September_02_2009.md) + - [August 05, 2009](August_05_2009.md) + - No meetings in July + - [June 17, 2009](June_17_2009.md) + - [June 03, 2009](June_03_2009.md) + - [May 20, 2009](May_20_2009.md) + - [May 06, 2009](May_06_2009.md) + - [April 01, 2009](Apr_01_2009.md) + - [March 22, 2009](Mar_22_2009.md) + (EclipseCon) + - [March 04, 2009](Mar_04_2009.md) + - [February 04, 2009](Feb_04_2009.md) + - [January 07, 2009](Jan_07_2009.md) + + + + - [December 03, 2008](Dec_03_2008.md) + - [November 05, 2008](Nov_05_2008.md) + - [October 27, 2008](Oct_27_2008.md) + (EclipseWorld) + - [October 01, 2008](Oct_01_2008.md) + - [September 03, 2008](Sept_03_2008.md) + - [August 06, 2008](August_06_2008.md) \ No newline at end of file diff --git a/wiki/Planning_Council/Nov_05_2008.md b/wiki/Planning_Council/Nov_05_2008.md new file mode 100644 index 0000000..b7d5cbf --- /dev/null +++ b/wiki/Planning_Council/Nov_05_2008.md @@ -0,0 +1,46 @@ +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Nov 05, 2008](Nov_05,_2008 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2008&month=11&day=5&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Markus Knauer + - Oliver Cole + - Doug Gaff + - Ed Merks + - Oisin Hurley + - Thomas Watson + - Karsten Schmidt + +### Regrets + + - Brian Fitzpatrick (sorry, car appt.) + +## Topics + + - Review items from [in-person + meeting](Oct_27_2008.md), particularly + train participation requirement bugzillas + - We quickly reviewed the outcome of our last in-person meeting + +### Reminders + + - December 10-11, 2008 - plenary session with Board + +## Additional Topics + + - None + +## Action Items + + - Send out a note to mailing list when Galileo plan.xml is visible + (Rich) + - Send out a note with instructions on how to update build + contribution files (Rich) + +**Carry over items** + + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/November_02_2016.md b/wiki/Planning_Council/November_02_2016.md new file mode 100644 index 0000000..4ae2c3b --- /dev/null +++ b/wiki/Planning_Council/November_02_2016.md @@ -0,0 +1,605 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Nov 02, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

Y

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Y

Alexander Nyssen

itemis AG (Strategic Developer)

Y

Nick Boldt

Red Hat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

EPP (appointed)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X-R(2)

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Are we done with these Neon.1 issues? + +:\* Was "Neon.1 help" ever deployed? See . + +::- *ACTION_ITEM: David to discuss with Fred to determine state and +make sure "what we know" is deployed.* + + - + + - + \- ACTION is "done": updated bug, sent email. We'll see. + +::- Then focus needs to be on to make things easier for all future +releases. + +:\* \[Wayne?\] Create New and Noteworthy for Neon.1 () + + - + + - + \- I assume we can "declare victory" but are "we" (Wayne?) + prepared to do this for all future update releases (and primary + releases)? Do we "need a documented process"? + \- *ACTION_ITEM: Wayne to "close out" the current bug and + document there (or, link to a wiki page) on what the process is + moving forward. I bet it will involve PMI. :)* + + + + - Any issues for Neon.2? Any new projects joining? I assume some will + have new features? (But I do not know what they are. Does anyone?) + + + + - + + - + \- *no issues known for Neon.2* + \- *ACTION_ITEM: Wayne to tweak PMI so that projects can + document their new features for update releases. The + "documentation" is primarily to improve communication to the + community on "why they should care" about a particular release + but there could be other consumers such as translators or + tutorial writers may need react. (This is required, since + "update releases" are no longer "maintenance releases".)* + +## Oxygen Planning + +### Java 9 Coordination \[Dani\] + + - After discussing what to do about Java 9 date changing, at a + previous meeting, we also discussed the need for "Java 9 + coordination". Dani volunteered to be the "Java 9 Coordinator". + Dani, is the following a fair summary of that work item: + + + + - + + - + 1\) Find out which other projects plan to participate in a + likely "July Java 9 update" (that is who is plans to "support + Java 9 during development time"?) + 2\) Educate projects on how and WHEN to test their code + **'running**' on Java 9. Ideally, as projects test on Java 9 + there will be a synergy where projects will educate each other + on what was discovered and what others should look for (perhaps + on a wiki, somewhere). + + + + - + \- *Dani's statement during meeting was consistent with the above, + but he may be more specific once he "begins the work" (anticipated + after Neon.2).* + \- ''I have updated our Oxygen Plan document to now include a "[July + Update + Release](https://wiki.eclipse.org/Oxygen/Simultaneous_Release_Plan#Java_9_update_release_in_July)". + +### Stop using Release Name? + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. See . + + + + - + \- Further discussion in a previous meeting lead to the idea that + one thing that is missing is what DO we call the **thing** we are + releasing. "Eclipse Neon" seems too vague and definitely sounds like + a different thing than "Eclipse Mars" (even if you add "release". + Some quick suggestions were "Eclipse IDE - Neon Version" or similar + (with dates, probably). + - + \- What's wrong with "Package"? \[dw: suggestion during 11/2 + meeting was"IDE" as a suffix of package name, or "IDE's" when + needed generically, would be a good choice, which I think all + agreed with.\] + + - \- Main ACTION ITEM is that we owe the community some official + response on bug 493490 about what our official PC plan or + response is. Is there agreement the following is our official + position? If so, I will comment in . + + + + - + + - + *Much discussion again\! One of the best points I heard (from + Alexander) was that "keeping the code name" allows projects to + easily associate their version of with the yearly Simultaneous + Release (or update release). But, as agreed, the name **by + itself** does not have any meaning. While not strong agreement + from everyone, it seemed to me the tendency was to favor adding + "date" to code name to those places where end-users might be + reading it and be confused (or, if not confused simply "get + nothing from it") -- such as splash screen, about box, and the + www.eclipse.org/downloads related pages. I asked for members to + open bugs for specific cases, but in the meantime have tweaked + our PC statement below:* + + + + - + + - + Summary of our position: decided that we can not "solve" this + issue for Oxygen, but we can make incremental improvement. After + that incremental improvement, we may have a better idea of the + (or another) core problem to fix. As things are now, there is + little chance of getting agreement on what the problem is or how + to fix it. Currently, it is sort of like saying that "the + problem is that things are confusing" -- too broad to fix all at + once. We do not want to abandon the "code name" (at least for + now) based on what we know. But there is agreement that \*by + itself\* the codename has no meaning for casual users and is + confusing because it is used in contexts that make it appear to + have meaning. + + + + - + + - + Therefore, it is recommended where specific areas are confusing + or meaningless that bugs be opened with a suggestion on how to + improve by adding more information (typically the "releases + date"). This includes web pages, splash screens, tutorials, + instructions, announcements, press releases, urls, and anything + else where "version" and "code name" and "contents of + deliverable" are confusing or meaningless. While typically the + date of the release should be added to the code name (such as + "Neon.2 \[December, 2016\]") in some contexts it might be more + appropriate to use the project version or build id. Also, + improvements to "check for updates" should be made that give + some indication that a "whole new stream" is available -- as the + Installer currently does (and as other "products" do, such as + Ubuntu, though there it is a user preference). But this will + require someone to implement a solution in p2 UI. Also, instead + of calling the delivered pre-packaged collections "packages" + they should probably be called "IDEs". + +### New levels of IP + + - + \- Do we, as Planning Council, want to stipulate a participating + project must be of "type B"? Or, do we not care? It may depend on + "how labeled"? How do users or companies know? What do they expect? + \- Wayne has opened bug for comments. + - In a previous meeting we decided our initial position should be + "status quo" -- that is, to say it is required that each project + in the Sim. release repository (and EPP packages) be of Type B. + A few reasons given: + + - + \- Adopters or users may be surprised to get a different legal + process than what they are used to. This not only concerns + adopters which build standalone commercial product, but some + build features which prereq certain EPP packages are installed, + so they direct their customers to install those packages first, + and then install their features. Plus, while is it commonly + believed "users don't care", many of those users work for + corporations or government agencies which do care. For example, + the corporation may have a policy that "it is ok to download and + install things from Eclipse where all the code has been + "reviewed as Type B". But those corporations might also tell + their developers: "it is not ok to download open source in + general and not even from Eclipse for Type A". It is unlikely to + get corporations to state what their internal policies are since + they would consider that confidential, so it just seems safest + to go with "status quo" -- until we learn otherwise or have good + reason to change. + \- Some projects that want to use this new Type A policy, such + as Orion, have always been "part of the Simultaneous Release", + but not part of the Sim. Release repository. It is only the + repository that we are saying it is required for, not the + Release, per se. + \- "How labeled" may make a difference. For example, as far as + we know, it is still required that any EPP package that contains + "incubating projects" label the whole EPP package as + "incubating". Could there be something similar for "Type A" or + "Type B" projects? And, the methods must be meaningfully named + to be usable (by users); not just "Type A" and "Type B". + + - **New for Nov 2 meeting:** Nick Boldt has some new information + and questions and a proposal that he posted to [PC mailing list + message](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02666.html). + Let's discuss\! + :\* \[*Notes from Nick Boldt with slight editing from dw*\] + ::- release records will be updated to include which level of due + diligence (Type A or B). + ::- Type A / Type B applies to third party libraries ONLY, not to + the project's code itself. + ::- Wayne \[EMO\] explicitly do NOT want Type A to be considered bad + or stigmatized. \[dw: He made the point that "Type A is more than + other foundations or open source groups do".\] + ::- if a hypothetical company wants to invest resources to move a + project from Type A back to B, they could do so \[dw: I do not think + this is true, it is essentially Eclipse Foundation's resources that + are "spent" on Type B checks of third party software\]; they could + also do the additional provenance checking and never report back to + the Foundation or the project. + ::- **To be resolved:** where should license check style be placed + in release records? As a new section on [release + record](https://projects.eclipse.org/projects/tools.thym/releases/2.0.0) + or a new blurb in the [release + doc](https://projects.eclipse.org/projects/tools.thym/reviews/2.0.0-release-review) + itself? + ::- **To be resolved:** should projects use [plugins' + about.html](https://github.com/eclipse/thym/blob/master/plugins/org.eclipse.thym.core/about.html), + [features' + license.html](https://github.com/eclipse/thym/blob/master/features/org.eclipse.thym.feature/license.html), + or a [LICENSE + file](https://github.com/eclipse/thym/blob/master/LICENSE) to + identify the license check style? + :\* \[Notes from David Williams -- overlap with Nick's, but since we + were entering in parallel decide to enter both sets\] + - + + - + *Given the new information provided by Nick, and some by + Wayne, it was decided "anyone can be in the Simultaneious + Release repository regardless of IP method choosen". But, + this was conditional on users and adopters being able to + easily know which method applies -- in case it does matter + to them. Suggestions were made to provide meaningful names + (other than "Type A and Type B") and to provide the + information in something like the about.html file. We all + agreed with Wayne that it should not be part of a package + name or bundle id, etc. Just something more "self + documenting" than the "release record" (Wayne's currently + planning on providing that).* + + + + - + + - + *Wayne did ask for "specifics" on "who needs to know?". For + examples, "which adopters would do their own extra IP review for + Type A bundles or who would "not be allowed to use it". I + pointed out it is very unlikely that a bank or major + coroporation would share that openly since they might consider + such "internal product decisions" confidential and/or a + competetive edge. I do think Stephan Merker implied that SAP + needs this in a previous meeting (but they were not represented + a today's meeting on 11/2). So, Stephan, feel free to bring the + topic up in December's meeting or comment in if you can.* + +### Potential new requirement + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **ACTION ITEM** from 6/8 meeting. Doug volunteered to "take up" + this item to better specify "what does it mean" and "what will + it take" to update across major releases. After last meeting, + Doug, mentioned he thinks this is a UI issue and he would take + it up with the UI task force. I do not think it is only a UI + issue, but from our point of view, more a matter of what we + expect projects to do differently. As I have listed before: + + + + - + + - + What would this take? Such as, + - + features can never be removed but can be replaced with some + form of transition. See and . + Preferences, views, etc. have to "migrate" (if their ID + changes)? + What testing would projects have to do? + What is the effect on commercial products? That is, will + their customers get sufficient information that they "... + can not upgrade without voiding their warranty", so to + speak? + Have we ever had a case where year-to-year updates worked? + (For everything.) + - + For Neon, it was the change in package layouts. (Hence + we backed-off having a "streamless URL".) + For Luna? it was the change in MacOS layouts + For Mars? it was the Window executable could not be + updated. (Now it can be, as long as it is named exactly + 'eclipse.exe'). + Eventually, I assume we would want a built-in stream-less + URL. I am assuming for Oxygen we do want to have a + stream-less URL available, but not built in, to enable + testing the update from Neon to Oxygen. (See ) + + + + - + \-*After a brief discusion, it was decided this should not be a + **requirement** though we should encourage projects to test that + scenerio and keep track of issues.* + \-*Doug surprised us all saying current "root features" do not work + as expected. That items can to be removed or added? Doug, please + clarify in what issues you are seeing.* + +### Release Policy vs. Release mechanics + + - For details, see . + + + + - + In Neon M6 we changed to have (nearly) all features to be "root + features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + Can we make an official policy on "off scheduled fixes" (as we are + considering for MPC)? + + + + - + + - + \- *Did not discuss at 11/2 meeting* + +## New Business + + - ? + +## Next Meeting + + - December 7, 2016 - Regular First Wednesday Meeting + +## Reference + + - + Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + + + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_04_2009.md b/wiki/Planning_Council/November_04_2009.md new file mode 100644 index 0000000..0eb8a4d --- /dev/null +++ b/wiki/Planning_Council/November_04_2009.md @@ -0,0 +1,360 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, October 07, 2009, at [1700 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=11&day=4&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) 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](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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](http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php). + +(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](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 +[Cross_Project_Teams/Accessibility](Planning_Council/Cross_Project_Teams/Accessibility.md) + +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](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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](November_04_2009.md), Noon + Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_05_2014.md b/wiki/Planning_Council/November_05_2014.md new file mode 100644 index 0000000..e695a97 --- /dev/null +++ b/wiki/Planning_Council/November_05_2014.md @@ -0,0 +1,313 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, November 5, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

R

Steffen Pingel

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

R

Markus Knauer

Innoopract (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + + + + - ''No announcements, per se, but did remind everyone M3 is "next + week" (and reminded myself to check for "disabled contributions"). + '' + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. + +## Luna SR2 + + - Any issues? + +## Mars Planning + + - + Please Review [the plan](Mars/Simultaneous_Release_Plan "wikilink") + and the [the + requirements](SimRel/Simultaneous_Release_Requirements "wikilink"). + - + Ready to consider these final? + *There were no comments, suggestions, or objections, but with + just "half the group" on the call, will consider these + tentatively approved, and ask for others to weigh-in on mailing + list, so by our next meeting in December will be officially + official.* + +## Progress on Action Items + + - Changed "test" project to allow easier "contributions as bundles" + \[Thanks to Dennis Hübner for the suggestions, and some + improvements\] -- nearing progress to "build the tests" for wider + spread use. + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (Gunnar has proposed a solution he's willing to be + responsible for, and is working on a "proof of concept". See + + + + - + + - + No observable progress? + +## New Business + + - *Wayne mentioned he and a group of "vested parties" are working on a + "3 year vision" of Eclipse. He said he'll publish a draft soon ... + or blog about the effort, but the idea is to increase focus on "user + experience" and make sure Eclipse "stays cool" to use. He did not + think it would effect Planning Council directly, but wanted to let + us all know it was coming.* + + + + - *I asked if anyone wanted to re-visit the "continuous release" (or + "hot-fix roll-out" methodology) and from group on the call, the + answer was basically "no", for the following reasons: the type of + issue that caused so much recent discussion on cross-project mailing + list is very rare, so even if "could be done better" no need for + large changes in process or methods for rare events \[might be + different if it was a critical fix that did effect everyone, such as + a security issue?\]; most groups, such as WTP, has "designed" JEE + package so they can roll-out off-cycle releases that are picked up + with "check for updates" (and there, there is pretty direct + connection with "providers" and "consumers" ... it's not like + everyone gets the fix, whether they need it or not); and, most + important "CDT was happy with current SR approach". :) I'm sure this + will come up again, from time to time, and no doubt improvements + could be made, but no "obvious solution" currently exists (that does + not require a lot more work).* + + + + - *I mentioned I should prune "callisto-dev" group soon, as is + (normally) routine practice (but, this is first time, since being on + Git). .* + +## Next Meeting + + - December 3, 2014 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_07_2012.md b/wiki/Planning_Council/November_07_2012.md new file mode 100644 index 0000000..2ae3e51 --- /dev/null +++ b/wiki/Planning_Council/November_07_2012.md @@ -0,0 +1,310 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, November 07, 2012, at 1200 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Reminder M3 due next week. + +## Juno + + - SR2 to get active in January + +## Kepler + +### Kepler Requirements Planning + + - [SimRel/Simultaneous_Release_Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") + + + + - + Discuss requirements. Changes or clarifications needed? Or, approve + "as is", unchanged from Juno? + +::\**We will formally "approve for Kepler" at our December meeting, +though we believe the document is pretty much ok as-is.* + +::\*''One question that came up was "What does the API requirement mean, +exactly?" (where projects must document their API policy and their use +of non-API from other projects). The brief answer was "we leave it up to +each project, we don't police it". But that the purpose is so that +adopters can better understand what is considered API ... that they +might want to use ... and/or if a project is "API clean" with respect to +its use of code from other Eclipse projects. This in turn led to a brief +discussion of "if we don't enforce it, is it really a requirement", but +that applies to all the items in the "Required for good adoption" +section of the document. I think still valuable to have that section +since it means it would be a legitimate bug if an adopter asked a +project "what is your API policy" or pointed out in a bug "you use +non-API from project B which prevents us from doing X". If/when/how the +project "fixes" those bugs is still up to them, but they would valid +bugs and it would be incorrect for a "Simultaneous Release Project" to +say "Invalid bug, we don't care about that". +TODO: Ian will see if wording can be clarified/improved or if current +wording suffices. '' + +::\**Another comment came up on the "greediness" requirement. It is +thought the Sim. Rel. requirement is correct as written, but that the +community (and ourselves) need more education on why it is important ... +that is, why use "greedy=false" for runtime optional bundles. I think +that one reason is that users (and adopters) may not want to include +those things that are installed simply as function of what repository +they point p2 at, but, maybe more important, that if such as "optional +but greedy" requirement pulled in an additional bundle (or bundles) that +it would be impossible for an adopter to provide a "feature patch" for +those optional bundles ... if those optional bundles just so happened +cause some critical issue in their product for a customer. This should +all be confirmed and if confirmed some encouraging, educational +reminders be given to the participating projects. But, at the moment, it +is not thought the wording in requirements document needs changing (i.e. +if a project refuses to go along, they would not be denied +participation).* + +::\**The document could be "polished" and some of the "removed" +requirements (which are currently in strike-out font) be literally +removed ... while "changes" are interesting going from one year to the +next, we don't need to maintain that "history" forever.* + +## Other Business + + - Any discussion about - Include workswith in simultaneous release? + + + + - + I closed as "won't fix", but glad to hear any further discussion or + opinions. + - + *No discussion and Steffen confirmed all is well and the + clarification appreciated.* + + + + - *There was a problem for one member getting in through the "North + America" number for Asterisk service. Just kept getting busy signal + for 10 or 12 minutes.* + +## Next Meeting + + - December 5, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_09_2011.md b/wiki/Planning_Council/November_09_2011.md new file mode 100644 index 0000000..efc5a82 --- /dev/null +++ b/wiki/Planning_Council/November_09_2011.md @@ -0,0 +1,404 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, November 09, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=11&day=09&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

??

?TPTP? (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo)

SOA (PMC)

Y

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - Any? + +*Congratulations on a great EclipseCon Europe\!* + +## Indigo SR2 + + - Anything? + +*Nothing* + +## Juno Plan and Requirements + +### M3 + + - Any issues? + +*none* + +### Requirements + +Review +[Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") for +substance and wording. In particular: + +*An overall suggestion was to add summary at top with links to "new this +year" items* + +#### The three new major headings. + +Do they make it clear some are A. "normal" requirements (just needed +earlier), B. some are required items to be in common repo, and C. some +are essentially optional, though considered required for good adoption. + +''Suggestions: '' + + - + ''In first one, "...but early" sounds vague, can it be reworded? + More concrete? '' + - + *May be hard, since two of the 4 are LOTS earlier (M4), and two + of them are 2 to 4 weeks earlier than usual* + *Maybe just say "... but earlier than usual" ... plus add + deadlines to headings.* + + + + - + *In third one, "... (but optional)" sounds too optional (like, don't + even read this section). Will leave out of heading and clarify in + first paragraph* + +#### . 4 new items, all marked (currently) with "\[added 10/18/2011\]" + +A. Source build. (this turned out to be wordier than I'd like ... +suggestions welcome ... is it worth having?) + +*This seemed redundant to most, especially if we have the "make source +easy to get from repository" item. I removed the item and closed as +wontfix.* + +B. Target Environments (Platforms and Java Levels). I tried to add some +general advice, to especially help new projects, but no substantial "new +work" ... just to encourage teams to think through and document what +they support. + +*General agreement that most projects don't specify anything in this +part of "standard plan", but should, but exactly what they specify is up +to them and their community of users and adopters (which I think is +fairly clear in current write-up, but will clarify).* + +*Some parts of it are a little wordy, such as doesn't need to be a +tutorial on effects of changing Java levels. Will shorten/simplify it. +(Some concern the document as a whole is getting too long ... both looks +like a lot, and takes a long time to read.* + +C. Getting source from repositories. I'd like to make it "required" to +use Eclipse-SourceReference, but there was some discussion on +cross-project list that not everyone liked that idea. So, tried to word +so that "its a good idea, and if you don't use Eclipse-SourceReference, +you should provide some other easy way". + +*Needs work. Need to clarify purpose. Is it to improve workflow, so +contributors can easily provide patches? Is it so adopters IP staff can +get a copy of all source used in a build? Or, both? Larger question is +if it is implementable. Currently there are no commonly used tools to +created team project sets (though, there are ant scripts around that do +it, such as Orbit). Currently, an Eclipse-SourceReference for GIT is not +implemented and no clear commitment to do it, despite being a regression +in available functionality, see .* + +D. Provide archived p2 repositories. Again, I personally think this +should be "required", but am not positive how many other projects do +this already (I know many many do), and can not say for sure we would +use them in the aggregation builds for Juno, so not sure it should be +"required" this year ... but, it would go a long way towards having +"reproducible aggregation builds". Plus, my speculative guess is, +something like archived repos might be required for Eclipse LTS (Long +Term Support), both to have something to depend on to re-create some +packages, but more so, to be sure there is a concrete deliverable from a +build against which future builds could be compared. + +*Ending up removing. Even though some projects and adopters use/need +these, there was concern that not all builders (je.g. Tycho) could +easily produce or consume them). It is counter to some people's view +that there be only a few repos and while contents change, the repo +location does not.* + +*It was said it was thought to be a "good idea" to produce these repos +... all the mature projects already do ... but a) we should we be +concerned too much about simply documenting good ideas and b) we do not +know what the LTS solution is so unclear we can justify it for that +reason. (Not to mention, the Planning Council is not responsible for +LTS, so while ok to make things easier if/when needed, there is no +reason to jump the gun, were some views discussed). So, unless ever +needed by the release train itself, is unlikely to ever be required.* + +#### Other requirements? + + - I added 2 more "new" ones, marked with \[11/09/2011\]. We won't + "settle" these today, since obviously no time to review completely + with PMCs, members, etc., but hope to introduce them and discuss a + little. + +A. +[SimRel/Simultaneous_Release_Requirements\#Unit_Tests](SimRel/Simultaneous_Release_Requirements#Unit_Tests "wikilink") + +'' dup '' + +B. +[SimRel/Simultaneous_Release_Requirements\#Compatibility_with_Previous_Releases](SimRel/Simultaneous_Release_Requirements#Compatibility_with_Previous_Releases "wikilink") + +'' no time to discuss'' + +#### Other clarifications? + +'' no time to discuss existing requirements to see if improvement can be +made'' + + - Comments after the meeting: The following notes were posted to + planning list after meeting, which I copy here, to capture more + easily with other items discussed, and document the "conclusion" or + if other discussion needed. + +... the list of 40+ "requirements" is pretty daunting for new projects +coming to the train (even if half of them are optional). I think we +should take any opportunity we can to cut this down or combine entries. +I read through the document this morning and the following came to mind: + +1\) There are five items about localization: "Message Bundles", "Support +Translations", "Excel in NL Support", "Test Localization" and "Enable +Use With All Languages". We could probably combine these into a single +"Localization" bullet point that contains all the details. We can leave +it alone if people think it is helpful but I think having the +information in one place would streamline it. Some of the specific +technology choices will really vary across projects anyway. + +*Good idea* I grouped them under a common heading for now, but left as +separate items. We can discuss if a paragraph would be better ... but +... somehow they seem like "separate activities" to me. I would like to +keep the "NL Translation" items separate from the "NL Enablement" since +I think the later effects nearly everyone (even runtimes) whereas the +former would not be applicable to any projects with no UI ... if there +are any. '' + +2\) Retention Policy - this could just be a sentence on the "Provide p2 +repository" entry. + +*Not sure ... are p2 repositories the only thing we retain? I know we in +webtools say a lot more than that, see [WTP Retention +Policy](WTP/Retention_Policy "wikilink").* + +3\) Metrics. Do projects really do this? Is it just part of the release +review documentation? One option here is just to submit your git +repository to and let it produce your project stats. +dash.eclipse.org, and Wayne's fancy new project pages also provide some +stats. + +''Gone. (I once had high hopes of doing more here ... but, with nothing +concrete, it is merely a good idea). '' + +4\) Optimization. I'm not really sure what this means. It just provides +a link to a list of available p2 ant tasks. The "Provide p2 repository" +entry already says repositories need to be conditioned and packed. What +other optimization does this refer to? + +'' Good point, I removed as an "items" but did move a form of the +sentence to the p2 repository section.'' + +### Checklist (aka tracker) + +Investigate if checklist can be improved and who can do it. + +*Did not have time to discuss* + +### Other business + +Any discussion or suggestions of ["delegation +policy"](Simultaneous_Release_Roles#Planning_Council "wikilink"). + +*It was agreed it was a "good idea" to state the policy (and allow +delegation).* + +## Next Meeting + + - [November_23_2011](November_23_2011.md) + (a "extra" meeting, to be sure everyone has a chance to voice their + opinions about requirements document). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_10_2010.md b/wiki/Planning_Council/November_10_2010.md new file mode 100644 index 0000000..dab170f --- /dev/null +++ b/wiki/Planning_Council/November_10_2010.md @@ -0,0 +1,394 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, November 10, 2010, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=11&day=10&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

Y

Oisin Hurley

Stp (PMC)

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + +

Wayne Beaton

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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - Eclipse Platform has officially stopped building AIX Motif and Linux + Motif. + +## Maintenance Schedule + +### Helios SR2 + +2/25/2011 (Fourth Friday of February) + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Indigo Status + +*M3 coming together roughly, but good part of that is at least people +are contributing/participating.* + +## Indigo Plan and Schedule + + - [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + *All agreed it was ready, acceptable, with one exception. The + requirement wording on 'jarred bundles' needs to be improved so no + explicit exception required (it is required for any requirement in + that section) and to also make it more generic and easier for a + project to document why a bundle is not jarred. Or, maybe even + detail when it should be documented, and what is an automatically + acceptable?* + + + + - Discuss "once in always in". Is there a + [proposal](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01842.html) + to change this? + + + + - + ''No proposal to change, but given the discussion and + misunderstandings, some wording should be improved, maybe 'once + participating, always participating', or 'participation is + continuous', or something. Plus, should improve the wording of + 'Exception process' to better emphasize its purposes: a) improve + communication, b) improve PMCs shepherding their own projects (not + the planning council, or planning council chair), and c) be sure + decision point is not just one person (the planning council chair) + but is instead a group effort. '' + +Suggestions during (previous) meeting: + + - Make explicit that to be in repo, feature includes must be strict, + so installs or builds are reproducible. (Even if there might + eventually be improvements that allow additional features, with + loose constraints ... but "minimum" requirement is the strict + inclusion. Unclear what loose requirement solution will be. Note: + the strict requirements are the way things are currently done ... + just best to make explicit, since it has come up before. + + + + - Move capabilities to "good citizen" section (and check wording to + make clear that to document "not supported" is one option ... or, + possibly "we don't know what this means" :). + + + + - Consistent license. No real change to requirement, but should + provide pointers to bugs where standard "user agreement" may change + (to include EDL) and where p2 may be improved to allow pointer to + URI ... or something. + + + + - Add a "must do" to be in EPP package, must run on/test on Eclipse + 3.7. + + + + - Add a "should do" to have a 4.1 theme item in plan to describe what + project is doing for 4.1 (and give some examples). + +Tracking "setup" required from Foundation in + +See initial [Indigo Wiki page](indigo "wikilink") + +Review: There is a subtle implication of specifying Java 6 as "minimum +runtime" requirement. Currently, we require contributors to use Java 5 +when using pack200, since if not, and if involves a jar that contains no +Java (e.g. source or documentation) then it can not be unpacked with +Java 5, Java 6 would be required. This has been a headache for people +since for many it means tweaking build scripts so an "old" (1.5) VM is +used for that one step. During aggregation, we purposely use Java 5 to +catch errors in this regard. For Indigo, I propose we not worry about +being consistent here, and just use Java 6 during aggregation. Some +projects may still want to use 1.5 VMs to do their pack200 ... if their +adopters want it ... but I see no reason for mass consistency here ... +if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent? + + - + *Some concern expressed, but mostly a matter of letting people know + and documenting options. For example, for projects that **want** + compatibility with VMs less than 1.6, they still can, of course, but + will no longer get "built in" test from aggregation. Plus, should + make clear, even a VM less than 1.6 can still use a pack200 (or, an + unpack200 executable) from another VM, such as a 1.6 distribution, + and [specify it on their command + line](Pack200#Pack200_Executable_location "wikilink") using + `-Dorg.eclipse.update.jarprocessor.pack200`.* + +### Issues and Proposal for 3.7 versus 4.1 + + - See working notes in + + +## Other business + + - ''TODO: I (dw) agreed to make initial +1, +2, ... table for project + signup. '' + + + + - + + - + Done. See + [Indigo/Participating_Projects](Indigo/Participating_Projects "wikilink") + + + + - Eclipse Platform 4.1 must move to be +1 because of dependency on + EMF. We should discuss how this will be coordinated because there + may eventually be cyclic dependencies (JohnA). + + + + - + ''John opened to see if part of emf could be +0. + + + + - Discussion on build machine QoS (JohnA): + - Is build machine contention/availability currently an issue for + projects? + - Do we need to adjust schedules to account for this? + - Consider other measures such as reducing continuous or regular + builds during milestone periods? + + + + - + *There was agreement this might become a problem (has been in the + past), but not sure if it currently is, and not sure what to do + about it if/when it becomes a problem. Its hard to pick favorite + projects or take away resources from some committers ... though is + is a shared, constrained resource, so might come to that. And by + "take away" it it meant to reduce, have various rules about niceness + level that are enforced, etc.* + + + + - + *TODO: I (dw) agreed to ask webmasters if there was some way to see + who was using what how much, as improved understanding might lead to + better solutions.* + + + + - + ''Long term, if it is only a matter of "peak usage", may want to + investigate (or, encourage others to investigate:) some sort of + "cloud" solution so during final milestone/release weeks we could + have 10 slaves, or something, whereas most of the time we just need + one or two. '' + + + + - ''Tom wondered if we need a "central" patch repository ... that + could be "built in" to all versions of Eclipse. It was suggested to + try to keep at project level, but agreed, some improvements might + make that better. For example, if in EPP packages, there was more + than one top level feature? Also, there maybe should be some other + attributes identifying patches, such as "security fix", or something + ... as some people may want to turn off checking for routine + updates, but turning off security fixes should probably be a + separate decision, as it is on many OS platforms. I was so excited, + I opened . Plus, later, I opened to improve the EPP package update + story, if possible. '' + +## ToDo Items + + - *Note from Wayne, to Wayne: (actually from last meeting) Remember to + review plans starting after M4 (at latest) so questions can be + clarified before "road map" produced.* + + + + - *Wayne teased us all with promise of new tools to check CQs against + downloads, which we projects can use ourselves ... but he wasn't + ready to tell us about them today and he'll be saying more over next + few days or weeks.* + + + + - *dw to sort out tracking path.* + +## Next Meeting + +November 3, 12 noon Eastern + +## Reference + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_23_2011.md b/wiki/Planning_Council/November_23_2011.md new file mode 100644 index 0000000..0dcc72c --- /dev/null +++ b/wiki/Planning_Council/November_23_2011.md @@ -0,0 +1,428 @@ +## Logistics + +| | | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, November 23, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=11&day=09&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Mik Kersten (Steffen Pingel)

Mylyn (ALM) PMC

D

Brian Payton

Datatools (PMC)

R

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

R

Ed Merks

Modeling (PMC)

Jesse McConnell

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

TPTP (PMC)

X

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + +### Requirements + +Review +[Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") for +substance and wording. + +In brief, the things to focus on, for this "off cycle" meeting, are the +[proposed changes for Juno +Release](SimRel/Simultaneous_Release_Requirements#Changes_for_Juno_Release "wikilink"). + +See [last meeting notes from November 09, +2011](November_09_2011.md) for detailed notes +of previous discussion. But, below is a brief summary of what we talked +about last time and actions taken. + +*This meeting was not well attended, due to holidays and conflicting +meetings, so some issues may come back up at our next meeting, but at +this meeting there was general agreement with substance of the plan, +edits made so far, and that "Getting source from repositories" is worth +keeping (in semi-optional, ease adoption category), if wording can be +improved and agreed upon.* + +#### The three new major headings. + + - Changed headings based on feed back from last meeting. + +#### 4 (now 2) proposed new items, all marked (currently) with "\[added 10/18/2011\]" + +A. Source build. + + - I removed the proposed new item and closed as wontfix. + +B. Target Environments (Platforms and Java Levels). I tried to add some +general advice, to especially help new projects, but no substantial "new +work" ... just to encourage teams to think through and document what +they support. + + - I simplified the wording. + +C. Getting source from repositories. I once thought it'd be nice to +"require" the use Eclipse-SourceReference, but there was some discussion +on cross-project list that not everyone liked that idea, for valid +reasons. So, tried to word so that "its a good idea, and if you don't +use Eclipse-SourceReference, you should provide some other easy way". + +*Need to discuss more? Need to clarify purpose. Is it to improve +workflow, so contributors can easily provide patches? Is it so adopters +IP staff can get a copy of all source used in a build? Or, both? Larger +question is if it is implementable. Currently there are no commonly used +tools to created team project sets (though, there are ant scripts around +that do it, such as Orbit). Currently, an Eclipse-SourceReference for +GIT is not implemented and no clear commitment to do it, despite being a +regression in available functionality, see .* + +D. Provide archived p2 repositories. + + - Removed the proposed new item. Not enough agreement it was required + to mention, though often good idea, many already do provide, and + seemed counter to one popular builder. PLUS, we (Planning Council) + have always resisted in the past doing anything to "make builds + better or easier" (as it was not actually our mission), instead, + focusing simply on what makes it easier for users to install things, + and improve consumability by adopters. So, bad idea to include for + many reasons (though, still a good idea to do). + +#### Other requirements? + + - [SimRel/Simultaneous_Release_Requirements\#Compatibility_with_Previous_Releases](SimRel/Simultaneous_Release_Requirements#Compatibility_with_Previous_Releases "wikilink") + + + + - + no time to discuss at previous meeting. Its already "required" as + part of standard plan ... but, I think some guidance/mention in this + document helps clarify expectations for Simultaneous Release. Any + objections? Suggestions? + +#### Other clarifications? + + - Comments/actions after the meeting based on John's note to planning + list ... see [last meeting + notes](November_09_2011.md) for detailed + notes. + + + + - + I incorporated most, but not all suggestions, so further discussion + welcome. + + + + - I did some more "grouping" of like-items ... + + + + - + grouped several under "Excel in NL support" heading, as suggested by + John + moved 3 items up under "plan" + moved several under a "bundle form and format" heading + moved 2 API related items together under "APIs" (net effect was to + move one "required" item to "optional" sections ... but, was + basically about documenting things, anyway ... nothing "concrete" to + (easily) test for common repo. + + + + - In addition to removing the "metrics" item, I propose we remove the + "capabilities" item + + + + - Other comments/improvements to plan? + +### Checklist (aka tracker) + +Investigate if checklist can be improved and who can do it. + +Possible solutions: + + - correct Portal, to be accurate to current list (and correct some + minor issues, such as in some cases two fields for data were + included, when one would have sufficed). + + + + - + + - + After that's done the summary PHP pages would need to be fixed + to match the Portal data. + + + + - medium budget fix: request "XML file" (similar in concept to + "standard plan") that would have and specified schema, with standard + headings, etc., and then someone could write XSL/XQuery scripts to + roll-up results. In theory, someone could write a form-like "front + end" to produce the XML files. + + + + - low budget fix: provide a template (or, example) wiki page, that + would consist of headings only ... that projects could copy and fill + out for their project. In this approach there would be no "roll up". + +*Good discussion around this issue. While no good solution is in sight +for Juno, some tactical plans made.* + +*Achim and Wayne have discussed the first (high budget) item, and Wayne +said that there are not resources in Foundation to do either (neither +they themselves fix, nor for them to do the work to allow someone else +to work on "Eclipse Foundation code" to fix).* + +*The second "medium budget" item was deemed too expensive, too much +work, and not fitting in with long term approach of having super-portal +that would "do it all".* + +*Tactical solution was to a) disconnect current code and summaries, +leaving only the 'simultaneousrelease' field (and its summary page) but +to remove the rest; b) provide a wiki page "template" (not official wiki +template) and tell projects if they wanted their own checklist or +summary they could make a copy of that, and fill it in, as they go; c) +will require projects in Simultaneous Release to have a section where +they state "Have complied with Simultaneous Release requirements, and +have listed any exceptions below".* + +*Longer term, not in time for Juno, fields such as link to rampdown +plan, link to accessibility testing, link to API policy, retention +policy, etc. will be part of the new "super portal" for projects to fill +in, or not, depending on type of release, needs of the project, etc.* + +*Some of the discussion here pointed out that there is a fundamental +conflict here, which we must be careful to not lose sight of, and +explicitly keep balanced: on the one hand we want things to be as easy +as possible for projects to "release" and for committers not to have to +do one bit of anything that is "extra work". On the other hand, the +Simultaneous Release is expected to be held to a higher standard than a +normal, ordinary project release; more work is expected for those +wishing to voluntarily participate, especially with regards for +providing a solid foundation for (strategic member) adoption. The +pendulum swings ... if participation is too hard, projects will not +voluntary participate, if expectations are too low, strategic members +will lose interest and not see or get any value. Thus, important to +always discuss from both points of view.* + +*To document reasons for the checklists and summary pages:* + + - *Projects have asked for it, in the past; to have a short summary to + follow, to guide them along, especially new projects.* + + + + - *It was intended as a way for Project leads and PMCs and Planning + Council to check progress towards compliance.* + + + + - *It was intended as an easy way for adopters to get quick, overall + information about a project. For example, if a project had no + retention policy and did not do any work towards accessibility, then + an adopter might decide it was not suitable to include in their + commercial product. Without such a summary, there is risk it will be + more work for everyone (clearly for adopters, trying to find out + that information) but also for projects, if they get asked the same + questions frequently. Similarly, a project might be "overlooked" for + adoption because there is no information easily available with this + important data.* + +### Other business + + - Are we failing in our mission, if common repo (as a whole) is not + able to be mirrored? + + + + - + See + *Off hand, quick comments were "mirroring is hard, there's many + complications, methods, ins and outs, and probably beyond our scope + or mission to worry too much about ... its more about the tools to + allow and do the mirror and resolve issues." In general, I think it + is a problem that two, perfectly consistent repositories, might not + be consistent when taken in composite ... but ... agree its a + problem that is not the Planning Council's concern (unless ... + someone comes up with a specific reason our process causes it).* + + + + - Anything else? + +## Next Meeting + + - December 7, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_2_2017.md b/wiki/Planning_Council/November_2_2017.md new file mode 100644 index 0000000..4ebf70f --- /dev/null +++ b/wiki/Planning_Council/November_2_2017.md @@ -0,0 +1,192 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, November 10, 2017, at 1100 Noon Eastern

Dial in:

Topic: PC call - Nov 10 only Time: Nov 10, 2017 11:00 AM Eastern Time (US and Canada)

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/636198543?pwd=tWzAHHXJzXQ

+

   Password: 123456

+

Or iPhone one-tap :

+

   US: +14086380968,,636198543#  or +16468769923,,636198543#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 408 638 0968  or +1 646 876 9923  or +1 669 900 6833
+   Meeting ID: 636 198 543
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=nNBU6gfmKc0Nc84Dn4eAG6zY9BDa2x6C

+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - OBEO (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) - R + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Oxygen & Photon status (by Fred Gurr/Mikael Barbero) + - JDT & Platform news (by Dani Megert) + - Status of the brainstorm about the future of the SimRel (by Mélanie + Bats) + +## Notes + +### Oxygen & Photon status + +Photon M3 was a little bit tend Oxygen 2 RC1 is for December 20th Photon +M4 on 15th + +No real issues at the moment. + +### JDT & Platform news + +Java releases will occur in March & September every year. It was decided +to keep the Simultaneous Release schedule stable as lots of projects are +not interested by Java at all and so do not depend on the Oracle +planning. So when necessary a ".a" version will be released as it was +done for Oxygen1. + +The Eclipse SDK will change its release cadence after Photon to a +release every 3 months. See the cross project mailing list for details : +[1](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15021.html) + +JDT and Platform has decided to + +#### JDT dependent projects + +To avoid the problem that appeared during the last JDT update, it was +discussed at ECE to list all the projects depending on the JDT. The +purpose is to get an overview, then we have to decided what we will do +next when a JDT update come out? Should the automated build must +notified automatically those projects ? + +Here is the list of JDT dependent projects, that I gathered by scanning +for "\*.jdt\*" in MANIFEST.MF files in all plugins (except JDT plugins) +in the latests Photon release P2 repo: + + - List of JDT dependent projects + - ./org.apache.jasper (bundles jdt so not affected) + - ./org.eclipse.acceleo + - ./org.eclipse.ant (Eclipse TLP so released together with JDT) + - ./org.eclipse.birt + - ./org.eclipse.bpmn2 + - ./org.eclipse.buildship + - ./org.eclipse.cft + - ./org.eclipse.datatools + - ./org.eclipse.debug (Eclipse TLP so released together with JDT) + - ./org.eclipse.dltk + - ./org.eclipse.e4 (Eclipse TLP so released together with JDT) + - ./org.eclipse.eclemma + - ./org.eclipse.egf + - ./org.eclipse.egit + - ./org.eclipse.emf + - ./org.eclipse.epp + - ./org.eclipse.fx + - ./org.eclipse.gmt + - ./org.eclipse.graphiti + - ./org.eclipse.jem + - ./org.eclipse.jface (Eclipse TLP so released together with JDT) + - ./org.eclipse.jpt + - ./org.eclipse.jst (WTP) + - ./org.eclipse.jubula + - ./org.eclipse.jwt + - ./org.eclipse.libra + - ./org.eclipse.linuxtools + - ./org.eclipse.lsp4e + - ./org.eclipse.m2e + - ./org.eclipse.m2m + - ./org.eclipse.modisco + - ./org.eclipse.mylyn + - ./org.eclipse.net4j + - ./org.eclipse.ocl + - ./org.eclipse.oomph + - ./org.eclipse.papyrus + - ./org.eclipse.pde (Eclipse TLP so released together with JDT) + - ./org.eclipse.pmf + - ./org.eclipse.qvtd + - ./org.eclipse.rap + - ./org.eclipse.rcptt + - ./org.eclipse.recommenders + - ./org.eclipse.sapphire + - ./org.eclipse.scout + - ./org.eclipse.sirius + - ./org.eclipse.sphinx + - ./org.eclipse.swtbot + - ./org.eclipse.team (Eclipse TLP so released together with JDT) + - ./org.eclipse.uml2 + - ./org.eclipse.viatra + - ./org.eclipse.wb + - ./org.eclipse.wst (WTP) + - ./org.eclipse.xpand + - ./org.eclipse.xsd + - ./org.eclipse.xtend + - ./org.eclipse.xtext + +This includes optional dependencies. \ No newline at end of file diff --git a/wiki/Planning_Council/November_6_2013.md b/wiki/Planning_Council/November_6_2013.md new file mode 100644 index 0000000..a76c4ea --- /dev/null +++ b/wiki/Planning_Council/November_6_2013.md @@ -0,0 +1,323 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, November 6, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - *We were reminded the deadline for EclipseCon submissions is Nov. + 18th. (Notifications of acceptance to come "in early December").* + + + + - + *Please remind your PMCs and projects you represent.* + +## Kepler SR2 + + - ? + +## Luna Planning + + - Review and formally approve (or not) new "format" of [Proposed + Requirements + Document](SimRel/Simultaneous_Release_Requirements_PROPOSED "wikilink") + that Dani and Neil have been working on. + + + + - + *New Format formally approved. Was not much discussion, other than + to say it was clearer and (main document) shorter. Mission + accomplished\! Thanks Dani and Neil\!* + + + + - + *Dani or Neil will rename old one with "obsolete" or date, or + something, and rename "proposed" to be main one.* + + + + - + ''Once renamed, etc., David will break "Policy FAQ" out into + separate document, and provide link at bottom, along with other + "additional links". + + + + - Any new requirements? Any to remove or change? + + + + - + If we ask people to specify exact feature (or repository) versions + in b3 aggregator files (see ) is that a new "requirement" or + implementation detail? For some, it would require "more work" and/or + better tools to generate the files more easily. + + + + - + + - + *Next meeting we'll discuss any new/modified requirements, if + any, and formally approve requirements for Luna*. + + + + - *After the meeting, realized I never had incorporated "Doug's + wording" about new features in SRs into our Policy FAQ. I have now + done so. See + [SimRel/Simultaneous_Release_Policy_FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink"), + the note that starts "\[added April, 2013, modified November + 2013\]".* + +## Progress on Action Items + + - GSoC project for "Development Channel"? (Wayne) + + + + - + + - + '' While GSoC is over, for a year, Wayne will at least recall + history and open a bug for this.''. + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan "by end of August". (dw -- no progress)\] + - Complete Google Calendar. (dw) + - Compute Luna SR dates. (dw) + +## Next Meeting + + - December 4, 2013 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/November_7_2018.md b/wiki/Planning_Council/November_7_2018.md new file mode 100644 index 0000000..600774f --- /dev/null +++ b/wiki/Planning_Council/November_7_2018.md @@ -0,0 +1,191 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Nov 7, 2018, at 11:00 EST

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Temporary Planning Council Chair: Nick Boldt Planning Council Chair: +Melanie Bats (returns Dec 2018) + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +TBD + +## Agenda + + - \[Ed\] oomph updates + +:\* no longer does 32-bit, now does dmg files, includes fixes for +equinox changes + +:\* oomph catalog is less restrictive w/ ranges. Upper bounds are 5.0 so +all 4.x updates will work (rather than \[4.9,4.10) which prevented it + + - \[Alex\] Missing EPPs for M1 - Java EE package missing + +:\* package maintainers ( should / must ) provide automatable tests? + +:\* publish all of them, but mark not approved, with link to previous + +:\* AI: Fred to delegate to web team to push all & mark red w/ bug +details - maybe for M2? + +:\* if maintainers provide tests, to be run on EPP jenkins, then manual ++1 email no longer needed + + - \[Dani\] Train name - we're now "Eclipse IDE for ___", "Eclipse + IDE" on splash screen + +:\* EclipseCon planning meeting: 6 in attendance, and in agreement + +:\* Eclipse TLP still not renamed + +:\* AI: Dani to email Thabang (cc: Ed) about replacing "Simrel" with +"IDE" on download and marketing pages because "Simrel" makes his eyes +hurt (though it should be noted that instead of calling the release a +"train" he does refer to it as "the simrel") :P + + - \[Dani\] liaison person for Eclipse marketing (Thabang - new + marketing guy; Ian is gone) + +:\* Sept release marketing was weak + +:\* No landing page for Jakarta EE, no buzz + +:\* Plan is to have the June releases be the big buzz, but quarterly +releases will get some love too + +:\* They need our help to know select N\&N items as input to marketing + +:\* Suggestion: Sopot Cela; nominate him to PC + +:\* AI: Alex to talk to Wayne about appointing Sopot + + - \[Fred\] cross-projects list should only be used for simrel + announcements? + +:\* no, nothing to change + + - \[Dani\] new list to be created for jakartaee-projects@ train + + + + - \[Fred\] simrel looking good + + + + - \[Ed\] not seeing a lot of contributions from projects; will we see + problems because no one is watching platform changes? + +### Actions from last time + +Per: + + - **AI**: Wayne: add a new date to the simrel schedule for when an + announcement is send to cross-projects@, to report who we think is + participating. If URLs are found w/ /latest/ or snapshot, they + should be disabled? + + + + - **AI**: Wayne: send note to cross-projects@ to announce not opting + in + + + + - **AI**: Wayne: update "ASAP" re: "Create your release record (for + new releases)". Actual date is on/before Oct 19. + + + + - **AI**: Wayne to produce documentation re: rules and send to + planning-council list + + + + - **AI**: Fred restrict pushing to simrel w/o gerrit review + +:\* not done yet; planned for after M2 + +### New business + + - TBD + +## Regrets + +## Notes \ No newline at end of file diff --git a/wiki/Planning_Council/Oct_01_2008.md b/wiki/Planning_Council/Oct_01_2008.md new file mode 100644 index 0000000..fa869ce --- /dev/null +++ b/wiki/Planning_Council/Oct_01_2008.md @@ -0,0 +1,155 @@ +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Oct 01, 2008](Oct_01,_2008 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2008&month=10&day=1&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Ed Merks + - David Williams + - Doug Gaff + - Neil Hauge + - Georg Schmidt + - Anthony Hunter + - Markus Knauer + - Brian Fitzpatrick + - Christian Kurzke + +Visitors + + - Nick Boldt + +### Regrets + + - TBD + +## Topics + + - Galileo [Requirements for + Participation](Galileo_Simultaneous_Release#Requirements_For_Participation "wikilink") + - It seems most are happy with the new table format, though + verification of content needs to be completed (expected by + in-person meeting at EclipseWorld). Also, it seems to be the + consensus that we should leverage Bugzilla to track individual + items. Another idea was to utilize the plan.xml format for a + high-level Galileo plan that would report on these bugzillas. + - Galileo Themes and coordination/communication with Requirements and + Architecture Councils (StAC meeting Tuesday, October 28th from + 1300-1700 at the Hyatt during EclipseWorld) + - Some members of the PC are planning to attend, though not many + (Rich G., Anthony H., Pat Huff, Markus K., and maybe Doug G.) + - Roadmap production: how to aggregate individual product plans? what + else to include? + - It seems we'll take a shot at the simplest approach of rollup + (indexing), and also investigate the benefits that use of the + galileo flag may provide. + - What is in an SDK? Sources, JavaDoc, Examples? + - To be continued at EclipseWorld - need to take a close look at + what each product includes in SDK. + - Galileo delivery... update site, packages, [custom + installer](http://build.eclipse.org/eppwizard/go)? + - It seems a central repository is still desired, and it should be + possible to leverage p2 in a virtual way to accomplish. The + consensus at this point is that packages and a custom installer + wizard should be provided. Additionally, to address the + additional agenda item below from Markus, it seems we all agree + that a benefit of train participation is to have high visibility + on the download pages, leaving non-train packages to be made + available from another location. But, there needs to be a review + of the thread on this topic first, leaving it as another + follow-up topic for the in-person meeting. + +As discussed on the last call, a couple of approaches were discussed to +help track compliancy of "Must do" and "Should do" items. Regardless of +the approach used for tracking, it seems we could benefit from some more +detail on each item, including verification method, target milestone, +etc. as seen below. Also included are those we agreed should move to +"Must do" from "Should do" in addition to some rewording of existing +items. In lieu of sorting by priority, I categorized each and reordered +a bit. I consolidated all requirements into just "Must Do" and "Should +Do" as it seems having several levels is not beneficial. + +| Category | Item | Description | Target Milestone | Verification Method | Overall Status | +| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ---------------------------------------------------------- | ------------------------------------- | +| Participation | Intent | Projects must have stated and demonstrated their intent to join Galileo by the M4+0 date. Projects do so by adding themselves to the table/list above, by signing off each milestone/RC on the [Galileo/Signoffs](Galileo/Signoffs "wikilink") page, and by contributing an .sc file to the [Galileo common build](Galileo/Build#The_Projects.27_Roles "wikilink"). **Note:** the .sc file approach may change for Galileo. | M4 | Manual | [detail](#intent "wikilink") | +| Communicate | At least one person from each project must subscribe to cross-project bug inbox, i.e. edit Bugzilla prefs to watch "cross-project.inbox@eclipse.org". Build team members from each project will provide communication channels: phone, mail, IM, IRC and will be available during *to-be-specified* crucial integration times. | M4 | Manual | [detail](#communicate "wikilink") | | +| Attendance | Project representatives must attend the planning meetings and conference calls - you have to be involved to be involved. A few misses are ok, but chronic lack of attendance is a no-no. | M4 | Manual | [detail](#attendance "wikilink") | | +| Ramp Down Policy | Projects must have a written ramp down policy by M6+0, linked in the table above. (One of the issues identified with this guideline is that its not so much the ramp down policy of how many votes are needed for each bug fix that we need to be consistent on, but rather the meaning of each of the milestones and release candidates. See [Platform 3.4 Endgame plan](http://www.eclipse.org/eclipse/development/freeze_plan_3.4.php) as a guideline. See also [Galileo Final Daze](Galileo/Final_Daze "wikilink").) | M6 | Manual | [detail](#ramp_down_policy "wikilink") | | +| IP | Projects must have their IP approved (a normal Eclipse requirement) and will follow the Eclipse Legal deadlines to do so. See also . | RC | Manual (Legal) | [detail](#ip "wikilink") | | +| Development | APIs | Projects should leverage only published APIs of dependencies. As a Release Review requirement, deviations should be listed as part of a migration plan, with bugs listed where APIs need to be provided by dependent projects. **Perhaps a '99 44/100% Pure APIs' indicator for projects with no improper usage can be used to advertise the 'cleanest' projects?** ;) | M6 | [PDE API Tools](http://www.eclipse.org/pde/pde-api-tools/) | [detail](#api "wikilink") | +| Message Bundles | Projects must use Eclipse message bundles unless there are technical reasons not to. (see [Message Bundle Conversion Tool](Message_Bundle_Conversion_Tool "wikilink") and [1](http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html)) | M4 | Manual | [detail](#message_bundles "wikilink") | | +| Bundles | Version Numbering | Projects must use 4-part [version numbers.](Version_Numbering "wikilink") | M5 | Manual (script?) | [detail](#version_numbers "wikilink") | +| Leverage OSGi | All plug-ins (bundles) must use the true bundle form. That is, provide a manifest.mf file, and not rely on the plugin.xml file being 'translated' into a manifest.mf file at initial startup. See [bug 130598](https://bugs.eclipse.org/bugs/show_bug.cgi?id=130598). With that, empty plugin.xml files in the presence of a manifest.mf file should not be included in a bundle. | M5 | Manual (script?) | [detail](#bundles "wikilink") | | +| Execution Environment | All plug-ins must correctly list their required JVM versions in the manifest.mf. See the wiki page about selecting the correct JVM [2](http://wiki.eclipse.org/index.php/EMF_2.3_JVM_Requirements#Runtime_.2F_Compilation_Compatibility). | M5 | Manual (script?) | [detail](#execution_environment "wikilink") | | +| Signing | Projects must use [signed plugins](Modeling_Project_Releng/Building/Signing_And_Packing "wikilink") using the Eclipse certificate. Exceptions must be authorized by the planning council for technical reasons. | M4 | Script | [detail](#signing "wikilink") | | +| Use Jars | Projects must have use jar'ed plug-ins unless there are technical reasons. Nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-ins. The OSGi runtime is fine with it but the compiler is not able to handle classpaths that contain nested jars. In case only one nested jar exists, it is often better to expand the contents of that jar into the root folder (i.e. unnest the jar). If a plug-in contains large files that are frequently used (opened and closed), a jar'ed plug-in might degrade performance significantly since the file must be decompressed each time it is opened. | M4 | Manual (script?) | [detail](#jars "wikilink") | | +| Releng | Builds | Projects must have build process maturity and their own functional project update site - the Galileo site will reference these sites, not replace them. | M4 | Manual | [detail](#builds "wikilink") | +| Orbit | Any new third-party plug-ins that are common between projects must be consumed via [Orbit](http://www.eclipse.org/orbit/); the final Galileo release will not have duplicate third-party libraries (note that this only applies to identical versions of the libraries; thus if project A requires foo.jar 1.6 and project B uses foo.jar 1.7, that's ok). | M4 | Manual | [detail](#orbit "wikilink") | | +| Optimization | Projects must [optimize](Update_Site_Optimization "wikilink") their update site using [pack200](Pack200 "wikilink") to reduce bandwidth utilization and provide a better update experience for users. Additionally, they should do [site digesting](Update_Site_Optimization#The_Update_Site "wikilink"). With the introduction of p2, project update sites also need to have metadata generated (artifact and content repository info). | M4 | Manual (script?) | [detail](#optimization "wikilink") | | +| Deployment | Work Together | This means that one should be able to load any subset of the Galileo projects into Eclipse and each of the loaded projects should be able to pass all the same tests as if it had been loaded independently. | RC | Manual | [detail](#work_together "wikilink") | +| Capabilities | Each project will provide basic capability/activity definitions to allow for their UI contributions to be hidden. These should be provided in a separate plugin/feature to facilitate inclusion/exclusion by consumers in product development. | M6 | Manual | [detail](#capabilities "wikilink") | | +| Localization | The project participates in Babel, meaning it is registered and available for string translation, etc. | M6 | Manual | [detail](#localization "wikilink") | | + +**Galileo Release "Must Do" Items** + +| Item | Description | Target Milestone | Verification Method | Overall Status | +| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | +| Releng | Build reproducibility through proper tagging and documented build process should be provided. This includes the execution of unit tests and build [RSS feeds](:Category:RSS "wikilink"). | RC | Manual | [detail](#should_releng "wikilink") | +| Usability | Should follow the [User Interface Guidelines](User_Interface_Guidelines "wikilink"). The [UI Checklist](UI_Checklist "wikilink") is a good place to start. Also, should participate in a [User Interface Best Practices Working Group](User_Interface_Best_Practices_Working_Group "wikilink") [UI walkthrough](UIBPWG_UI_Walkthrough "wikilink"). | M4 | Manual | [detail](#should_usability "wikilink") | +| Accessibility | Should design for accessibility | M4 | [ACTF](http://www.eclipse.org/actf/) | [detail](#should_accessibility "wikilink") | +| Performance | Projects should devote at least one milestone to performance and scalability improvements. | M7 | [3](http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html?view=co) | [detail](#should_performance "wikilink") | +| Branding | Each major project (the top-level projects except for the Tools and Technology projects where it is the sub-projects) should have an About dialog icon and contribute to the welcome page. | RC | Manual | [detail](#should_branding "wikilink") | +| Localization | Should use [ICU4J when appropriate](ICU4J "wikilink"). | M5 | Manual | [detail](#should_localization "wikilink") | +| New & Noteworthy | Should have new & noteworthy for each milestone. Should be something readable and usable not just a static list of all the bugs. Corollary: individual new & noteworthy should be linked in to the collective New & Noteworthy. | RC | Manual | [detail](#should_nandn "wikilink") | + +**Galileo Release "Should Do" Items** + +For tracking, these are the two approaches discussed that we can decide +on the call: + + - One was to use Bugzilla to assign to each participant a prioritized + bug for each item (P1 = must, P2 = should, etc.) with target + milestones, as it's best to have certain items completed by a + specified milestone (e.g. API lockdown). A "master" bug for each + could be used to clearly show dependencies and their status. + - The other was to use the familiar checklist approach, whereby each + participant would indicate completion of each item. + +| Item | [BIRT](http://www.eclipse.org/birt) | [Buckminster](http://www.eclipse.org/buckminster) | [CDT](http://www.eclipse.org/cdt) | [DLTK](http://www.eclipse.org/dltk) | [DD](http://www.eclipse.org/dsdp/dd/) | [DTP](http://www.eclipse.org/datatools/) | [ECF](http://www.eclipse.org/ecf/) | [Eclipse](http://www.eclipse.org/eclipse/) | [EMF](http://www.eclipse.org/emf/) | [EMFT](http://www.eclipse.org/modeling/emft) | [EPP](http://www.eclipse.org/epp/usagedata) | [GEF](http://www.eclipse.org/gef/) | [GMF](http://www.eclipse.org/gmf/) | [MDT](http://www.eclipse.org/modeling/mdt/) | [M2M](http://www.eclipse.org/m2m/) | [M2T](http://www.eclipse.org/modeling/m2t/) | [TMF](http://www.eclipse.org/modeling/tmf/) | [Mylyn](http://www.eclipse.org/mylyn/) | [RAP](http://www.eclipse.org/rap/) | [STP](http://www.eclipse.org/stp/) | [Subversive](http://www.eclipse.org/subversive/) | [TPTP](http://www.eclipse.org/tptp/) | [WTP](http://www.eclipse.org/webtools/) | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| Intent | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | style="background:palegreen" | | | | | | | | | | | | | | | | | | | | | | | | | +| Communicate | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | style="background:lightsalmon" | | style="background:palegreen" | | | | | | | | | | | | | | | | | | | | | | | | | + +### Reminders + + - In person meeting to coincide with + [EclipseWorld](http://www.eclipseworld.net) + - December 10-11, 2008 - plenary session with Board + +## Additional Topics + + - IP process improvement discussion with Janet Campbell - tentative + - Building non-Ganymede EPP packages and put them on the [packages + download page](http://eclipse.org/downloads/packages) - see + discussion on [bug \#238960](https://bugs.eclipse.org/238960) - + Markus Knauer + +## Action Items + + - Move Must-Do and Should-Do list to the Galileo page (Rich) **Done** + - Look into Bugzilla for tracking train requirements (Rich) + - Look into plan.xml rollup (both with and without the use of a + galileo flag) (Rich) + - Investigate the use of p2 to create a "virtual" simultaneous release + update site, sans the jar copying (Rich) + +**Carry over items** + + - Query Babel project for string freeze deadline and participation + requirement info (Rich) + - Query ACTF for information on accessibility to include as release + requirement (Rich) + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/Oct_27_2008.md b/wiki/Planning_Council/Oct_27_2008.md new file mode 100644 index 0000000..fc6a70a --- /dev/null +++ b/wiki/Planning_Council/Oct_27_2008.md @@ -0,0 +1,293 @@ +| | | +| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council In-Person Meeting @ EclipseWorld 2008** | +| Date & Time: | Monday [Oct 27, 2008](Oct_27,_2008 "wikilink") from 8:00 am to 5:00 pm [Google calendar event](http://www.google.com/calendar/event?action=VIEW&eid=bW84N2d1NXEwZGIxdGoxZHBwMTViMHRoY2MgZWNsaXBzZS5vcmctcGxhbm5pbmctY291bmNpbEBlY2xpcHNlLm9yZw&tok=NTIjZ2NoczdubTRudnBtODM3NDY5ZGRqOXRqbGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbTExOGU1ZTE3NmNkNzIwZjg2MmNiOWE2NGJjM2NlOTUwYzIxM2Y1Zjg&ctz=America%2FNew_York&hl=en&gsessionid=xHBllKy_75-7I7GWbC9MVw) | +| Place: | [Hyatt Regency Reston](https://resweb.passkey.com/Resweb.do?mode=welcome_ei_new&eventID=69096) | + +## Attendees + + - Richard Gronback + - David Williams + - Pat Huff + - Anthony Hunter + - Markus Knauer + - Oliver E Cole + - Bjorn Freeman-Benson + - Neil Hauge + +### Regrets + + - Oisin Hurley + - John Duimovich + - Karsten Schmidt + - Doug Gaff + +## Topics + + - Galileo [Requirements for + Participation](Galileo_Simultaneous_Release#Requirements_For_Participation "wikilink") + - Finalize list + - The list was refined and agreed upon. Each will be added to + Bugzilla under the new Eclipse Foundation \> Simultaneous + Release \> Galileo component with the appropriate priority (P1 = + must-do, P2 = should-do) and target milestone. A clone of each + bug will be created for each participating project with a + dependency on the master bug to allow for reporting. + - Discuss project plan format, content, and ownership (see details + below) + - The consensus was to leave the Galileo plan as a high-level + document with rollup in the form of links to participating + Galileo project plans, and include bugzilla queries for the + entries listed above. Bjorn's report for non-Galileo projects + need to be addressed by individual PMCs to ensure each project + provides a plan, as the Planning Council also agreed this is an + acceptable requirement for each project for any release or + continuation review. + - Create planning section of the Roadmap to present to the Board at + December meeting, using input from individual [Project + Plans](Development_Resources/Project_Plan "wikilink") per + [this](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01422.html). + - As mentioned above, the plan will be provided in the form of the + now-standard plan.xml format with Galileo participation + requirement Bugzilla queries to track progress. + - Plan + [status](http://www.eclipse.org/projects/temporary/project-plans-status-report.php) + per project. Should plans be required by M3 as a train must-do? + - Added as a requirement, though M4 was agreed as the timeframe. + - Galileo participation status + - Each project should declare intent with Planning Council + representatives so that each can have its tracking Bugzillas + created and be added to the overall project plan. Each project + or PMC to decide on what level of granularity they'd like to + have presented on the rollup plan. + - Galileo deliverables (EPP packages, update site, all-in-one, etc.) + - It was agreed that the product-based build proposed be used as + the basis, which provides p2 metadata and content repositories + and unified artifact location for all participants. The actual + product produced will not be provided as a downloadable to all, + though certain requests may be satisfied on a case-by-case + basis. + - EPP packages will be provided, though likely based on .product + files as well. + - The [installer (RAP-based p2 + director)](http://build.eclipse.org/eppwizard/go%7Ccustom) will + be promoted, with categories to be aligned with those presented + in the main Galileo repository. This requires that only Galileo + train participants are allowed to be made available in this + custom installer. The initial proposed structure of categories + is found below, with an additional SDK site/categorization to + also be provided. + - Email from Babel team re: gray box testing of strings + - It was decided that the testing will be a should-do item, though + Babel participation is a must-do for train projects. + - PC update to members on Nov. 17th before ESE (wwdi?) + - Bjorn agreed to provide the update with material provided by + Rich + - PC meeting 12/10, the day before the plenary in San Francisco... + needed? + - It was agreed that an in-person meeting in December would not be + required, as it's unlikely we'll need more than calls in the + near future, and also as a consequence of tightening travel + budgets + - TPTP "POG" initiative + - Advised TPTP broadcast to committer list their request for + participation on helping to improve the profiler, and to perhaps + consider those open bugs that have the performance keyword for + potential contributors. + - SDK composition + - It was agreed that some guidelines be provided to bring + consistency in the way each project packages SDKs are necessary. + To being, a basic wiki page with a list of the current issues + and recommendations for a solution to begin the discussion. Once + a consensus is reached, an approach to providing an SDK site to + complement the end-user tooling site for Galileo consumption can + move forward. + +### Project Plan Discussion + +From Jeff's email: + + - **What is the intended use/audience of these plans?** In my projects + we have always attempted to address the consuming community and + attempted to paint a general picture of the kinds of significant new + directions, functions, etc that are on the table for the next + release. In looking over the DSDP and DASH plans I was struck by how + detailed they are. There are a great many items (bug reports) + listed. Given the volume and the format (many entries starting with + the same \[tag\]), the document is not very consumable IMHO. People + can find out what is going to be worked on in any given milestone by + doing a query but that is raw information, not a considered and + crafted plan. + + + + - **What should the community expectations be wrt the plans + changing?** Our plans have always changed say 4 times as the dev + cycle goes on. This IMHO a positive attribute as it more accurately + reflects reality as reality unfolds. However, where the plan is + composed of bug queries for particular \[tag\]s (or the like) there + appears to be a danger of anyone in the community unknowingly + putting something on the public plan simply by putting \[tag\] in + the summary line. Change is good but too much churn and fluidity + undermines confidence. + + + + - To address the above two concerns I propose that we explicitly state + a best practice for project teams to use the "plan" keyword (or any + other explicit and relatively exclusive marking mechanism) to + clearly and explictly mark bug reports as being for the plan. + Following this approach we would likely end up with fewer plan items + and less churn. Both changes would increase the consumability of and + confidence in the project plans. + + + + - **What do we think plan readers want to see and should expect?** I + saw some discussion about having more text related to the plan items + in the plan itself but no real conclusion. Currently the rendering + shows only the summary (I suppose that is a conclusion :-). Again, + from a consumability point of view this is less than optimal. It + requires a lot of clicking and makes it hard to see the big picture. + I've been to countless meetings where people sit down with a printed + copy of the plan and talk about the different items. If all the real + content is had only by following a link, ... In part this is a + rendering question but from a best practice point of view, what do + we think plan readers want to see and should expect? If you walk up + to a project about which you know little, what do you expect from + their plan document? I expect to see some sort of digested form of + the raw information that tells me the intent, direction, challenges + and what problem is being addressed. Imagine trying to get funding + based only on your plan document. Again, we can have links to all + the gory details. Make the simple thing simple and the hard things + possible... + + + + - **Should it be easy or hard to create a plan document?** (sucker + question) The main [plan wiki + page](Development_Resources/Project_Plan "wikilink") highlights a + plan template designed for "little HTML" and implies that the "lost + of HTML" approach is for legacy folks. From a best practice point of + view, should plan authors be producing rich plans or machine + generated queries? I guess my point here is that while people are + free to choose which xml tagging scheme they use, we should be + encouraging them to create good looking, easy to read plans. Guiding + them towards archane XML namespace markup and "prefix"ing is likely + to make crafting such a plan appear unattractively hard. I suggest + that we reorient the main plan page to guide folks through the + simple path first with off-shoots for the non-XML-averse folks. + + + + - These issues/questions were discussed in general, with no obvious + problems identified. We're going to deliver a basic plan (see above) + until suggestions for improvement are presented by consumers. + +## Galileo Categories + +Some discussion on improving/simplifying the category list for Galileo +resulted in the following proposed structure. A separate SDK structure +will be provided as well. Note that elements not found within categories +are either expected to appear in the default uncategorized category, or +be found using the filter on the dialog. Also, changing the view to +by-name or by-site may facilitate finding additional features. Sections +are used to indicate the web-based UI division of categories. + +Note that this is a basic outline and still needs to be +refined/completed. + +### Wizard page \#1 + + - Programming Languages + - Java + - C/C++ + - JavaScript + - Ruby, etc. + - Web Development + - HTML/CSS/XML + - JavaScript + - JavaEE + - RAP + - STP elements + +### Wizard page \#2 + + - Database Development + - DTP elements + - Modeling + - UML + - DSL Toolkit + - BPMN + - SCA + - etc. + - Testing and Performance + - Profiling + - etc. + - Device Development + - DSDP elements + +### Wizard page \#3 + + - Collaboration + - ECF + - Mylyn + - CVS + - SVN + - Tools & Goodies + - Buckminster + - Remote Access + - UDC + - BIRT + - Runtime elements + +## Other Discussion Items + + - Regarding the naming of subsequent release trains, it was proposed + and accepted that the PC provide a short list of names to be decided + in some manner during EclipseCon. The only concern is that the + naming process should not serve as too much of a distraction from + the release in progress. The current short list includes: Io and + Triton + - It was suggested that a ramp-down policy element be added to the + current plan format + - The consumption of Orbit bundles was discussed, as although many + projects utilize bundles, they often do it in different ways (e.g. + with dedicated feature, with 3rd party feature, with no feature). An + approach should be recommended and added to future release train + participation requirements. + - On the discussion of a single all-in-one Galileo download, the + bandwidth issue was raised and led to the recommendation that + perhaps eclipse.org servers should limit download access by allowing + only "Friends of Eclipse" access, leaving mirrors to service the + majority of the community. + +## Action Items + + - Create bugzillas for use in plan administration (Bjorn) + - Invite Babel project to next PC call to discuss project status and + perhaps demonstrate UI testing procedure (Rich) + - Provide PC update material for presentation at members meeting prior + to ESE (Rich) + - ~~Create a wiki to begin discussion on SDK composition and + delivery~~ (Rich) [SDK Composition](SDK_Composition "wikilink") + - Organize a mechanism to vote on train name during EclipseCon, + selected from PC-provided short list (Bjorn) + - ~~Remove galileo flag queries from the current plan.xml for + Galileo~~ (Rich) + - Send list of projects as desired to be listed on Galileo for linking + to individual plans (which may then link to plans), or better yet, + apply patch to plan.xml found on this + [bug](https://bugs.eclipse.org/bugs/show_bug.cgi?id=250840) (All) + +## Additional Topics + + - IP process improvement discussion with Janet Campbell - ? + +## Reminders + + - December 10-11, 2008 - plenary session with Board + +## Action Items + + - TBD \ No newline at end of file diff --git a/wiki/Planning_Council/October_03_2012.md b/wiki/Planning_Council/October_03_2012.md new file mode 100644 index 0000000..e932d36 --- /dev/null +++ b/wiki/Planning_Council/October_03_2012.md @@ -0,0 +1,440 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, October 03, 2012, at 1200 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Marc Dutoo for Adrian Mos

SOA (PMC)

D

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Juno + + - SR1 out and on time. Thanks\! + + + + - + Well, sort of. "Updates" of EPP packages had to be disabled, due to + a bug for Mac users, where the update operation would delete the + eclipse.ini file. + + + + - + Looks like solution nearly in hand and (I'm assuming) EPP will need + to respin at least EPP repo (but, we should not have to respin + common repo). + + + + - + Unsure of plans (or recommendations) for re-spinning EPP + downloadable packages. They are essentially correct, but (I think) + if not re-created then those that unzip an SR1 package will + immediately be offered an update (that basically does nothing ... + just a few IU versions change). I don't think that'd be so bad ... + but ... the final call is up to EPP (i.e Markus). + + + + - + The surprising thing is that this problem was not noticed during + testing. Guess no one well tests EPP updates on Mac's? + + + + - + + - + *Will leave up to Markus to decide if to respin/replace + downloadable packages. PC would be fine either way* + + + + - + + - + *We should encourage more/better early testing, somehow ... + better enlist community?* + + + + - + + - + *Ian pointed out we need to test the case where someone has + already had their eclipse.ini file removed ... would they get + the "update" and get the eclipse.ini restored? Or, maybe not, + since no artifacts actually installed? Just a reminder to test + that.* + + + + - Issue "in community" about having two streams of EPP builds. See . + + + + - + The goal in our meeting to decide what action to take and/or how to + respond in the bug. + + + + - + In mailing list, Ian provided these references to the issue, which I + wanted to paste in here, to make sure easy to find. + + + + - + + - + + + + + + + + + + - + + - + Another reference to follow: + [Platform_UI/Juno_Performance_Investigation](Platform_UI/Juno_Performance_Investigation "wikilink"). + + + + - + *The PC discussed, and decided, that we would not like to see 2 EPP + packages provided from Eclipse Foundation, and below I've tried to + capture the main points of discussion.* + - *The primary reason is that the 4.x stream is the strategic + direction. That is what we want to encourage people to use and + at least for many people, it works fine, if not great. We, the + PC, and Eclipse project, are committed to improving that 4.x + stream, particularly the performance problems that effects some + users and use cases to the point they consider it unusable. We + recognize that's terrible, if people feel they can not + productively use it, but we don't feel in the big picture of + things it is so dire that we must "back peddle" or provide extra + packages. Better to focus on making 4.x better.* + - *Would give confusing message to community, and seems a little + ill-timed. Kepler will be out before you know it. That is, seems + a short term solution for (hopefully\!) a short term problem.* + - *Also mentioned that we (the Planning Council or Eclipse + Foundation) are not really in the "packaging business". Yes, we + do want to make things easier for users to "get started", but + many companies package all sorts of distributions, based on 4.x, + 3.8, 3.7, 3.6, etc., and let users/companies get exactly what + they want ... and many are quite happy staying on 3.6 or what + ever ... but, ease-of-use is not our (Planning Council's) only + goal ... we primarily want to get Eclipse projects coordinated + and headed in the same, strategic direction. We are sympathetic + to those that like the convenience of getting one download with + everything they want, but we want to encourage focus on the + strategic direction.* + - ''Technically, 3.8 is not "part of Juno". Each project decides + what it wants to contribute and the Eclipse Project PMC choose + 4.2. While, technically, there is no rule against EPP producing + what ever kind of packages it wants to (3.8, 3.7, 3.6, etc.), + their role to date has been to draw from the (strategic) common + repo and create packages from that. Even if they did produce + different packages, it would still be up to us (the Eclipse + Foundation) to decide what to put on main "download page". '' + - *I should note, that technically, it would not be a huge amount + of work to mechanically crank out more packages, but there is a + lot of "corollary" work needed to test, track bugs, sort through + issues ... and, its hard to know, what surprising things might + be found if not well planned, coordinated, and tested ahead of + time. In other words, there would be risks and unknowns in + providing more packages or repos.* + - *As far as "actions" we (the PC) could take, we didn't have + anything too specific, though we should/could probably do a + better job of encouraging early testing. Many of the problems + being reported are problems the platform team, by itself, would + likely never have seen on their own and (in most cases) are + having a difficult time reproducing -- though there is no doubt + they are real (and very serious) problems for those users + experiencing them. We greatly appreciate the community's help in + finding ways to reproduce the issues and/or help fix them and/or + help test fixes when possible.* + - *There was one suggestion that the Eclipse Project consider an + early SR (before February) if great progress was made. John did + share that the Eclipse PMC has discussed that with arguments on + both sides ... it would distract committers from other work, but + they (the PMC) are interested in the idea of "faster release + cycle" (seems many browsers, etc., are doing more of that these + days), but they think they should be well planned and + coordinated, not reactionary to fix particular problem or set of + problems. So, while not completely ruled out (I don't think) it + sounds very unlikely and should not give anyone a false + impression (or "false hope") that there might be an early + release. I pointed out that projects are free to release anytime + they like, and do not necessarily have to be only at SR1 and SR2 + (WTP, Mylyn, and EGit, do it all the time), but it is a larger + (PC) discussion if considering new common repo or EPP packages. + There is a long standing issue that most EPP packages do not + "see" updates automatically, if EPP itself is not updated. While + this is not an unsolvable problem (see ) someone would need to + solve it, and it would not help in the short term for this + particular problem (since a user needs to start off with the + right "version" (metadata) for all of its components to be + update-able automatically. But, this situation highlights the + need for that bug () to get some attention?* + - *I (dw) will update the bug () as "won't fix" but emphasize we + appreciate the suggestion and community feedback, know that is + was well intended, but have decided against it for the strategic + reasons mentioned above.* + +## Kepler + +### Kepler Requirements Planning + + - [SimRel/Simultaneous_Release_Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") + + + + - + Begin discussion of requirements, if changes needed. To the extent + possible, I suggest we start with high level issues this month (such + as, should any be added, removed?) and perhaps finish up with + wording changes for clarification (if any) next month. + + + + - + ''Didn't discuss much. I brought up issue of low compliance to + "greediness" issue, and as far as I know, to define everything in + features is the only way for adopters to provide patches ... so ... + either I need education, or better educate others on why important? + Or ... maybe others don't need patches? What's alternative? New + release? (which, adopters can not do "on their own", typically, such + as for a "hot fix" for one customer). '' + +## Other Business + + - +## Next Meeting + + - November 7, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_05_2011.md b/wiki/Planning_Council/October_05_2011.md new file mode 100644 index 0000000..b83e0bf --- /dev/null +++ b/wiki/Planning_Council/October_05_2011.md @@ -0,0 +1,312 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, October 05, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=10&day=05&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

??

?TPTP? (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Jesse McConnell

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)

Neil Hauge

Oracle (Strategic Developer)

Kaloyan Raev

SAP AG (Strategic Developer)

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - Any? *none* + +## Indigo SR2 + + - Anything? *none* + +## Juno Plan and Requirements + +### Plan + +I've updated our [Planning +Document](Juno/Simultaneous_Release_Plan "wikilink") with SR dates ... I +consider the document "done for Juno" ... except for links (and content) +for requirements and tracking. (That is, please proof read, especially +dates for SRs). + +### Requirements + +Previous year's document on ["eclipse +web"](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php), +moved to ["eclipse +wiki"](SimRel/Simultaneous_Release_Requirements "wikilink"). I have +edited, for clarity and organization. Only "requirement" I've changed, +so far, it the one about 3.8 support (previously, was about 4.1 +support). + +*In general, everyone thought "fine", but admitted had not had time to +read carefully yet, so (I hope) still room for improvements to be made.* + +*issue: is there a way to make clearer what is "normal Eclipse +Foundation requirement" and what is "release train" requirement. I think +it pretty obvious, if someone reads whole document, but TODO: will look +at changing/adding to the 3 main headings to make clearer.* + +*issue: is the "using Orbit bundles" an Eclipse Foundation requirement +or train requirement? Answer: train. EF requires the CQ, but does not +specify where to get it from. In general, should be easier for projects +to get from Orbit, and avoids "inconsistent" bundles if things installed +together in unexpected ways, whether on train, or not. So it would be +odd _not_ to get from Orbit, even for non-train release. There might +be some exceptions for some projects (such as Virgo?) where "they have +existing customers that expect the bundle to be in a certain form" ... +similar to any "software migration" when existing customers exist, I +guess. In theory, such exceptions should be "equally valid" whether on +train, or not ... but there could be real "conflicts" that would +preclude being in common repo.* + +*issue: is the "must be signed" requirement from Eclipse Foundation or +release train? Answer: train. Wayne clarified, if "signed or not" is +release train requirement, but Eclipse Foundation requires "if it is +signed, and distributed from Eclipse, it must be signed by the Eclipse +certificate".* + +Other requirements? + +*none mentioned.* + +Other clarifications? + +*none mentioned. But members will raise issues on planning council +mailing list, or on "talk page" of wiki. (typos and small grammar fixes +can just be made on wiki, directly, by any PC member). All PMC members +are encouraged to "watch" that wiki page, to be aware of changes or +discussions.* + +### Checklist (aka tracker) + +Is it worth someone investing the time to update this? + +I have heard both ways, some like, some don't ... so I hope others have +some strong opinions one way or the other? + +Let's first decide what we want ... then we can discuss how to get it +done, if desired. + +*In general, thought to be fairly worth while, and fairly easy for +committers to fill out ... as long as no one "hounded" to do it. In +particular the "checklist" aspect was thought nice, in that helped guide +people, so especially useful to new projects. Especially important to +adopters/consumers to learn more about a project, such as "is it tested +for accessibility" (which some adopters need to know, for selling +services/products in some markets). Some of the "difficulty" to projects +is in the inaccuracies ... such as something reported as "not complete +yet" and people just have to fill in "junk URL" to get the form happy. +And, is easy in that many/much data does not change year to year ... +such as a link to milestone documents, or similar. Another way to help +"automate" some information is to provide links to the "report pages" +where things like "signed or not" and "4 part version numbers" can be +tested, instead of merely checked off as "done or not done". TODO: for +now, will mark which requirements have reports and provide a link to +main report page in requirements document. Unlikely this could ever be +"fully automated, project by project" (without a lot of effort).* + +''Was mentioned that "resource constraints" to improve the "Portal +tracker" is a real constraint. As an aside, Wayne mentioned Portal may +be "completely replaced" perhaps second quarter of 2012 (so, may need +some action at that time: port code to new tracker? Move tracker out of +Portal? Achim mentioned he (they) might be interested in helping to +support/improve that tracking code, so he will discuss "internally" and +chat with Wayne about it before next meeting. (There is, some "portal +code" that no one but EF could access ... but some of it is "just" PHP +pages that others could provide patches for.) '' + +## Next Meeting + + - ~~November 2, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern).~~ + - (Achim) This is the first day of **EclipseCon Europe** (clashing + with the 10 Years Eclipse keynote and the 10th Birthday party)\! + - Reschedule 11/2 meeting to November 9, 2011, at Noon (Eastern)? + +*agreed, next meeting 11/9* + + - Subsequent, December meeting (back to 'first Wednesday'): December + 7, 2011, at Noon (Eastern) + +## Reference + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_05_2016.md b/wiki/Planning_Council/October_05_2016.md new file mode 100644 index 0000000..2fa63c1 --- /dev/null +++ b/wiki/Planning_Council/October_05_2016.md @@ -0,0 +1,544 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Oct 05, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

R

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

R

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Fred Gurr did attend (again)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Y

Alexander Nyssen

itemis AG (Strategic Developer)

R

Nick Boldt

Red Hat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

EPP (appointed)

R

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

X-R(2)

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Do we need a "rebuild" for ? Will also include . See also where I + would like to try a "new" method of creating "off-schedule" fixes to + Sim. Release Repo. + + + + - + See also the [message to cross-project + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13693.html). + ~~- BUT, there has been no official request via Technology PMC or + their Planning rep.~~ + A [formal + request](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02650.html) + has been made -- with [one + vote](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02651.html) + so far -- can someone give a second? Any objections? + +*Ian Bull did "officially vote yes". No objections raised. So we will do +the respin. Anticipate package to be "done by Monday" and "made +available by Tuesday".* + + - Are we done with these? + + + + - + \- Will soon need a Neon.1 info center () + - + Such as, Eclipse platform did change some docs, but they did not + respond or list them in . (See for list of Platform doc + changes.) + A related topic: anyone see an issue with implementing an + automatic process to find bundles with "toc" extension in + plugin.xml and using that as our "help input"? See + \- \[Wayne?\] Create New and Noteworthy for Neon.1 () + +*No overall conclusion about "done or not" (Dani said probably just an +oversite, in their case).* *No one could think of any problem with +implementing . Perhaps "now", for list of Neon.1 bundles would be a good +start? We could even use the output in existing bug, even though +eventually would like improved code.* *Wayne not present to say if New +and Noteworthy "done".* + +## Oxygen Planning + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. See . + + + + - + \- Further discussion in the meeting lead to the idea that one thing + that is missing is what DO we call the "thing" we are releasing. + "Eclipse Neon" seems too vague and definitely sounds like a + different thing than "Eclipse Mars" (even if you add "release". Some + quick suggestions were "Eclipse IDE - Neon Version" or similar (with + dates, probably). + - \- ~~ACTION ITEM: Doug said he would try to re-ignite the + discussion via blog or similar.~~ + - \- Main point is that we owe the community some response on bug + 493490 about what our plan will be. + + + + - + *During \[previous\] meeting, it was decided that we can not "solve" + for Oxygen, but we can probably make incremental improvement. After + that incremental improvement, we may have a better idea of the core + problem to fix. As things are now, there is little chance of getting + agreement on what the problem is or how to fix it. It is sort of + like now the problem is "things are confusing" -- a little too broad + to fix all at once. I will comment in that we don't want to abandon + the name, but that in general, any place the "code name" is used + there needs to be more information, such as version or date or build + id (depending on context). Also, I think that "check for update" + should give some indication that a "whole new stream" is available + -- as the Installer currently does.* + *No new discussion in 10/5 meeting.* + + + + - A "new business" item that we did not have time to discuss in + previous meetings was about the impact of the new levels of IP. Do + we, as Planning Council, want to stipulate a participating project + must be of "type B"? Or, do we not care? It may depend on "how + labelled"? But he will open a bug and/or we will discuss at the next + meeting. See and comment in . + + + + - + *Spent a long time discussing this. Mostly asking questions where no + one knew the answer. Such as "how labelled?"* + *When asked "who wants this" the only answer known was "web + projects" such as Orion, where they do not necessarily have + detailed, advance knowledge of "which jars, exactly, might be pulled + in as they run". It was also believed that perhaps "new projects" + wanted this, to get a quick start, but we were not positive about + that.* + *While the PC is open to further discussion and a different + decision, we believe our initial position should be "status quo" -- + that is, to say it is required that each project in the Sim. release + repository (and EPP packages) be of Type B.* + - + ''A few reasons given: '' + - + *- Adopters or users may be surprised to get a different + legal process than what they are used to. This not only + concerns adopters which build stand alone commercial + product, but some build features which prereq certain EPP + packages are installed, so they direct their customers to + install those packages first, and then install their + features. Plus, while is it commonly believed "users don't + care", many of those users work for corporations or + government agencies which may care. For example, the + corporation may have a policy that "it is ok to download and + install things from Eclipse" (because they know all the code + has been "reviewed as Type B") where as the corporations + might not say that for "Type A". It is unlikely to get + corporations to state what their internal policies are, + since they would consider that confidential, so it just + seems safest to go with "status quo" -- until we learn + otherwise or have good reason to change.* + *- Some projects that want to use this new Type A policy, + such as Orion, have always been "part of the Simultaneous + Release", but not part of the Sim. Release repository. It is + only the repository that we are saying it is required for, + not the Release, per se.* + *- Some obvious things that would change are minds is if + half the projects in Sim. Release repo (especially those + that have a lot of dependants in the repo) were to say they + are always going to be of Type A. So we still need to + clarify who plans to use this new process.* + *- "How labelled" may make a difference. For example, as far + as we know, it is still required that any EPP package that + contains "incubating projects" label the whole EPP package + as "incubating". Could there be something similar for "Type + A" or "Type B" projects?* + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **ACTION ITEM** from 6/8 meeting. Doug volunteered to "take up" + this item to better specify "what does it mean" and "what will + it take" to update across major releases. \[Doug, it is up to + you, but I suggest you form a small team of like 3 people, such + as Ian and Dani or, others who know some of the technical + issues, to help if they are able and willing.\] The goal being + just a more specific statement of what it means, and what + projects have to do differently for Oxygen. That is, we don't + need to reach Nirvana in one release cycle.'' + + + + - + + - + What would this take? Such as, + - + features can never be removed but are replaced and + transitioned? + I am assuming for Oxygen we want have a "streamless URL" + available (not built in) to make it easier for some to start + testing the update from Neon to Oxygen. (See ) + Preferences, views, etc. have to "migrate" (if their ID + changes)? + What testing would projects have to do? + What is the effect on commercial products? That is, will + users get sufficient information that they "... can not + upgrade without voiding their warranty", so to speak? + Have we ever had a case where year-to-year updates worked? + - + For Neon, it was the change in package layouts. (Hence + we backed-off having a "streamless URL".) + For Luna? it was the change in MacOS layouts + For Mars? it was the Window executable would not be + updated. (Now it can be, as long as it is named + "eclipse.exe"). + + + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In Neon M6 we changed to have (nearly) all features to be "root + features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + Can we make an official policy on "off scheduled fixes" (as we are + considering for MPC)? + +## New Business + + - Discuss how to deal with Java 9 being moved to July 2017 \[Dani\] + + + + - + *-This was a hot topic during the meeting. It was clear we did not + want to change our June Release (since, after all, the July date is + not exactly guaranteed). Instead we will come out with a quick "July + update" in addition to the already planned September update. That + was easy enough, but then asking "what does this mean" made it clear + that we needed a "Java 9 Coordinator". Dani graciously agreed to + take on that role. The July update means -- at least -- that JDT and + any related platform component will update (which primarily means to + make the "BETA Java 9 Patches" be part of the deliverables instead + of patched in).* + *-There are two other important aspects to coordinate, though. + First: who else has "Java 9 changes" that might be required. It was + thought that projects such as Webtools might (such as to "run a + server using Java 9", or their "faceted projects" may require a new + Java 9 type). Do they plan/desire to be part of the July update? Or + will they do something later? Second: does the "July update" imply + all the EPP packages (and code in the repository) **run** on Java 9? + If nothing else, projects will need to make sure they use no + "internals" which will no longer be available in Java 9. (i.e. run + jdeps, etc.) Also, some Eclipse projects (such as e(fx)clipse, may + need to make sure the "module definitions" suit their runtime (or, + are available, etc.)). Worse, some rules about reflection and class + loading may be changing (which might impact a lot of old third party + code, some of which does a lot of custom class-loading and lots of + reflection or inspection).* + *-So, as "Java 9 coordinator" Dani's task will be to 1) Find out + which other projects plan to participate in the July update and 2) + Educate projects on how to test their code "running" on Java 9. + Ideally, as projects test using Java 9, there will be a synergy + where projects will "educate each other" on what to look for + (perhaps on a wiki, somewhere?). That is, Dani is just to explain + the basics and the importance of testing with it, not necessarily to + know each and every little thing that might need to be done or + changed.* + + + + - The remaining "new business" items are from previous meetings. I am + not sure they resolved so left them for now. + +:\* ''Wayne could not make the meeting, but posted a [message to our +mailing +list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02606.html) +about concern over some specific projects -- some of which may have to +be "removed" from the train. But, in addition, expressed concern over +"the process". + + - + + - + \- ''I agree and commented on a similar issue on [cross-project + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13122.html) + about two projects who "declared intent", but thought they could + join the build at the last minute. '' + \- *I wondered out loud if it was time for more of a Sim. + Release process where projects had to "prove they were ready to + be in the Sim. Release" instead of us just saying what they + needed to do, and then assume they were doing it. We did not + discuss at this meeting, but, for example, I mean like a + checklist (web app) that has to be updated every milestone? Just + an idea.* + +:\* A question was raised if people have to "announce" they will be in +"Neon.1" if they were in Neon. The answer was "no". \[Did not mention it +at meeting, but they should announce if they are NOT going to be in +Neon.1.\] + + - + + - + \- This led to a brief discussion if projects should "rebuild" + if their prereqs change. For example, if a security bug is found + in an Orbit bundle. A few thought "yes", but seemed the + consensus was "there was no way we could force them to" (i.e. + can not leave them out, or else their "previous release" would + still be there with the bad bundle) and it was probably a fringe + enough case we did not need to have a rule about it. + +:\* A question was raised how we can avoid issues such as with Neon +where Window Builder was excluded for Neon. They were ready at the very +very last minute but had not done any builds or testing for all of the +Neon development cycle. Somehow, we should "detect" when projects are +not active so we can approach them early to find out if the project is +viable if they are testing, etc. + +## Next Meeting + + - November 2, 2016 - Regular First Wednesday Meeting + +## Reference + + - + Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + + + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_07_2009.md b/wiki/Planning_Council/October_07_2009.md new file mode 100644 index 0000000..957d668 --- /dev/null +++ b/wiki/Planning_Council/October_07_2009.md @@ -0,0 +1,311 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, October 07, 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=10&day=7&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

Y

Brian Payton

Datatools (PMC)

Y

Doug Gaff

Dsdp (PMC)

Anthony Hunter

Tools (PMC)

Y

Oisin Hurley

Stp (PMC)

Y

Ed Merks

Modeling (PMC)

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Y

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

R

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

EclipseSource (Strategic Developer)

R

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.

+ +## Helios + +### Criteria and Process + +Introduce and overview [Eclipse Simultaneous Release +Document](http://www.eclipse.org/helios/planning/EclipseSimultaneousRelease.php). + +It is in cvs repo /cvsroot/org.eclipse in www/helios + +Notes from 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](https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 +[Cross_Project_Teams/Accessibility](Planning_Council/Cross_Project_Teams/Accessibility.md) + +#### 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](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (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](November_04_2009.md), Noon + Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_07_2015.md b/wiki/Planning_Council/October_07_2015.md new file mode 100644 index 0000000..f7ff508 --- /dev/null +++ b/wiki/Planning_Council/October_07_2015.md @@ -0,0 +1,547 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 2, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (occasional)

Cloud (PMC)

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

R

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

R

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Welcome Sam Davis as new (official) PC rep from Mylyn (ALM) PMC; and + thanks to Steffen Pingel for his years of service. + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before meeting, but if questions or + issues with previous minutes, this would be a good time to bring + them up. + +## Mars Planning + + - Mini Mars.1 retrospective: + + + + - + \- Some (committers) expressed ?surprise? that new projects could + "join train". (I think "surprise" is the right word?) + - + \- Doug has mentioned "we need to socialize the changing rules + better" (Anyone know how, and able, to do that?) + + + + - + + - + \-*No one in attendance knew "how to socialize better" to + committers.* + + + + - + + - + \-*During meeting, also discussed need to communicate better + with "community", consumers, adopters, occasionally even "the + press".* + - + \-*One suggestion was to ask projects "what is new and worth + mention in marketing materials", as we do for the June + release. It wouldn't expected to be as long a list, but, + best to have something to say about it. Even if "bug fixes + only", that's fine, but best to say. Might be nice to as for + "number of bugs fixed" or even links to queries that listed + the bugs fixed?* + \-*It was also learned that we should communicate "slipped + dates" better. At minimum, update the Planning Council calendar + and various wiki's to mention the new date.* + + + + - + \- The respin + - + \- Seemed a borderline case, to me. But, in the end, glad we + did. Not just for workspace dialog issue, but also improved repo + and packages to include only one (latest) version of + com.jcraft.jsch. That in turn was "lucky", since Eclipse.org + infrastructure upgraded and quietly included only "latest" + Ciphers. Unclear if really only needs to be one, like a + singleton, but there have been reports of "uses constraints + violations", when both present. + \- Then there was (some) surprise about the "one week slip" in + releasing. + - + \-- Of all "lessons learned", I like the idea of "if we + rebuild during quiet week, then automatic one week slip in + schedule". + \-- Not only makes gives time for others to re-test, or + adopters to rebuild, but makes it easier for me and Markus. + \-- I plan to codify this practice in the Sim. Release Plan. + Any objections? See [addition to Mars + Plan](Mars/Simultaneous_Release_Plan#Mars.1 "wikilink"). + + + + - + + - + \-*There were no objections to adding this explicitly to plan + documents.* + + + + - + + - + \- As a side observation, the workspace dialog bug was + introduced by a code change on June 6, which (partially) + validates our caution by allowing Buildship to join in June. The + bug had been reported earlier (than last week of Mars.1) but a + fix was not known before then. Thanks again to Tom Watson for + providing the correct fix ... otherwise, would have still be a + problem (albeit rarer) if we had re-spun with originally + proposed fix. + +## Neon Planning + + - See initial working draft of plan at + [Neon/Simultaneous_Release_Plan](Neon/Simultaneous_Release_Plan "wikilink"). + + + + - \- Neon's 2016 Milestone Dates (M5, M6, M7, and RCs) + + + + - + + - + See [Neon's + Schedule](Neon/Simultaneous_Release_Plan#Schedule "wikilink") + Similar to last year (EclipseCon is similar dates, as last year + -- but on East Coast again\! Yeah\! :) + Do we all agree with those dates? (That is, can we declare them + now official?) + + + + - + + - + \- *There was agreement with these milestone dates. Nothing + controversial, or, changing from previous years.* + + + + - \- Neon's Update Release Dates + + + + - + At our [last meeting](September_02_2015.md) + it was decided to have 3 update releases (instead of current 2), and + have them approximately equally spaced: + - + June (3) September (3) December (3) March \[(3) June\] + \* I propose we plan the availability of Update Releases to be + the same as the end of specific Neon+1 milestones. + \- That would be M2, M4, and M6. (See Neon's schedule, for a + rough idea of when Neon+1 milestones would be. + + + + - + + - + \- *There was general agreement this seemed reasonable, but, + some wanted more detail, such as how "test time" would line up, + for the milestone vs. update releases. So that will be the next + step, for me to map our some detail, and show both milestones + and update releases on same schedule or calendar.* + + + + - + + - + \- This has one obvious advantage: for projects that are + essentially working on one stream only (such as fixes-only, + especially for first Update Release), they can submit same + content to the Update Release, and the Milestones stream. + + + + - + + - + \- *Nick suggested: Would this be a good time to look at + changing the /staging/ and /maintenance/ URLs so they're + \*release-specific\*? eg., instead of:* + \* '', '' + \* *,* + \* ** + *... we could do* + \* '', '' + \* '', '' + \* ** + *... so as to differentiate staging of update releases + (maintenance) from staging of .0 releases (staging) and avoid + conflicts between mars/neon or neon/neon+1 URLs.* + + + + - + + - + \-*Post-meeting observation from David: If we had release name + as apart of the URL, we would not need "maintenance" just + "neon-staging" and "mars-staging"* + + + + - + + - + \- Also, looking at schedule, the December "match up" seems a no + brainer ... not much other time to do it? + \- M6 matching the last Update Release is nice, since gives + "clear focus" for M7 and the end-game of Neon+1. + \- And Neon.1 matching M2 completes the rhythm. + \- From those "end dates" we would count backwards, to establish + the same RC pattern we have now. + - + \- I've not looked closely, but believe the first "warmup" + RC, would be same or near the previous Neon+1 milestone. + (one quiet week, plus 3 one week RCs, plus 1 two week RC + equals 6 weeks) \[Is that good or bad? Do we still need that + early warm up RC? (I'm inclined to say yes, if for nothing + else, "new projects" joining train, and for those adding + minor feature updates -- we still want a relatively early + warm-up for them, similar to a update release milestone). + +:\* Can we say now we all agree with these dates? (I suggest "official +vote" for next meeting, but if disagreement or concerns, speak up now\!) + +:\* Has everyone had a chance to talk to their PMCs, Projects, or +Strategic Members they represent? (Please do, we need, and want, +complete buy-in from all stack holders -- that is, not so much what we +dictate, as it is what they want ... or, at least tolerate). + + - Off-cycle "hot fix" releases/patches. + + + + - + \- *We did not discuss this topic much, at 10/7 meeting.* + + + + - + One proposal: have all features in EPP packages be "root features" + and establish a procedure of adding new code to the Sim. Release + repository "at any time" -- for "hot fixes" only ... after + review/approval by Planning Council? + AND, change p2? to "not allow" addition of reference repositories + during feature installs. + - + + - + (Would likely have to be a "product preference" since some + adopters may depend on that feature, but EPP could "set" the + preference). + Easy for me to say "change p2" :) but ... who would do the + work? + + This "reference repositories issue" was a discussed as a concern + at Architecture Council + + - + Apparently there have been cases of users getting "mixed" + installs, because reference repositories are sometimes very + broad. \[I hope I've captured that issue correctly, I was + not there, so please correct if I read it wrong.\] + Does Oomph solve this problem at all? Does it have a possible + solution? + + + + - Rolling "release" issue + + + + - + \- *We did not discuss this topic much, at 10/7 meeting.* + +:\* Upon re-reading, that was another topic discussed at Arch. Council. + +:\* Probably several ways to solve ... if it is a real issue? ... and, +if I understood what the "end goal" was better? + + - \- \[ACTION ITEM from previous meeting\] Wayne took as a "to do" + item, to check with IP staff if a CQ deadline should be set for + update releases. + + + + - + + - + \- Cons (probably not needed): there are few new ones, every one + knows the limits + \- Pros (would be helpful): helps set expectations of committers + and new contributors on how much can be done, by when. + - + (Though, still varies a lot, if "all new" large + contribution, vs. piggy back CQ) + + + + - + \-- *Wayne reported that at this time, no deadline needed. Might + change in future, as experience and new patterns emerge. But, + nothing obvious at this point, other than a general awareness that + "the earlier the better" and that all requests can not necessarily + be satisfied, depending on size and timing.* + +## New Business + + - ''It was mentioned it would be nice, if not important, to + "re-kindle" the face-face meetings at EclipseCon NA ... or, some + other form of more active Planning Council participation. + +## Next Meeting + + - November 11, 2015 - Regular First Wednesday Meeting -- on 'Second + Wednesday'\! + + + + - + \- at 10/7 meeting, decided to have on Second Wednesday, so as to + not overlap with EclipseCon Europe (Nov. 3 to Nov. 5). + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_2_2013.md b/wiki/Planning_Council/October_2_2013.md new file mode 100644 index 0000000..6519e46 --- /dev/null +++ b/wiki/Planning_Council/October_2_2013.md @@ -0,0 +1,432 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, October 2, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

R

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

R

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - EclipseCon 2014 Submission system is now open + + +## Kepler SR2 + + - Will re-start aggregation builds near end of year (unless requested + earlier) + +*Was suggested or requested to "leave enabled" and even build +periodically, say, once a week, just to give opportunity for early +testing for those that desire or need that.* + +## Luna Planning + + - Topics for possible discussion: + +:\* Change policy on disabling all in M1 to require "actively joining"? + +::\* Related to Wayne's proposal on new "how to join" method: + + + - + + - + Key aspects: + - + Projects to send note to cross-project list. (How to handle + "individual projects" vs. those that release as a "group", + e.g. WTP?, Platform?) + Planning Council (or, Wayne) enters their "entry" and +n + date in database. + Deadline? M4 seems "late" for those already in? We've said + "once in, always in". Hence, how does this interact with + "disabling in aggregation"? + + + + - + ''General agreement, though some questions still to work out ... '' + Action items: + Wayne will send note to Cross-project "in a day or two". For Luna, + he will start with initial data from b3aggrcon files that have had + contributions enabled. + - + ''Wayne mentioned only two thirds of "last years projects" have + responded to list ... so a) reps should remind their + projects/PMCs to re-join explicitly (or, be explicit, if not) + and b) Wayne will modify "participating projects" page to also + list those that haven't said, yet. + ''DW to open 2 bugs: '' + - + ''1) What are best "deadlines", in relation to b3aggrcon files. + The idea would be be something like "for those already in train, + they would "stay enabled" until after M1", then if had not been + heard from on cross-project list, they would be disabled. If not + heard by end of M3, they would be removed (since M4 is deadline + to be "in", even for new comers). '' + - + Done. See . I actually changed my mind and put M2 as + deadline, based on this year's experience that by M2, the + previous year's maintenance release (SR1) should be done, so + really little excuse after that, not to have announced and + be planning next years release). + *2) open (or find, and change priority of existing bug), that + b3aggrcon files would be changed to conform to "project name" + pattern.* + - + Done. See . + +:\* Should we revisit the policy about "release one month prior to SR"? + +::\* How can (or should) we better capture what new features are in an +SR for adopters awareness? + + - + + - + *There was agreement "we needed something", but flexible on + exactly what.* + *Doug took action item of working on wording of new policy for + Planning Council consideration and approval ... it'd be + something like "feature freeze by (and in) RC1 and Release + Review Materials complete by RC1". Release Materials would + include "new feature" descriptions for adopters, so that'd be + covered.* + + + + - + *Doug proposed [this wording on mailing + list](http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02194.html):* + :\*'' First major releases not allowed. Projects must maintain + backwards compatibility with the release.'' + :\*'' Projects must follow the ramp down schedule for the SR. The + bits for the release must be made available at RC1 and can not be + introduced later than that. Bug fixes of course can be made during + the release candidate cycle.'' + :\*'' Release review material must be available to the community by + RC1 to document the changes and new features in the release.'' + + + + - + '' We will allow one month for members to review with projects and + strategic members to be sure it "fits" with internal processes, etc, + but seems reasonably balanced. This would replace or be incorporated + into a rewrite of our [current + policy](SimRel/Simultaneous_Release_FAQ#Can_a_new_project_or_feature_join_a_Simultaneous_Service_Release_.28SR1_or_SR2.29.3F "wikilink").'' + +## On going discussions + +\[Can we turn this into an action item, owned by someone? Otherwise, +will remove from "on going discussion".\] + + - Do we need, or how can we help enable, "more frequent releases"? + Including what, exactly, that means. Such as, currently projects can + release whenever they want, but the issue seemed to be on EPP + packages and/or "prime real estate" of "Eclipse Foundations + Downloads" page? + +*Decided we'd remove as "on going discussion" ... that we've done all we +can as Planning Council ... but please raise topic again if +projects/members have any concrete suggestions/concerns.* + +## Progress on Action Items + + - Editing of "Requirements Document"? (Dani and Neil) + - See current draft of proposed changes + [SimRel/Simultaneous_Release_Requirements_PROPOSED](SimRel/Simultaneous_Release_Requirements_PROPOSED "wikilink") + + + + - + + - + '' Dani and Neil to update more in a couple of weeks and keep us + posted on mailing list. The goal is to have "yay or nay" version + by next meeting.'' + + + + - GSoC project for "Development Channel"? (Wayne) + + + + - + + - + '' While GSoC is over, for a year, Wayne will at least recall + history and open a bug for this.''. + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan "by end of August". (dw -- no progress -- will likely + be late, still "in October")\] + - Need to improve [Luna](Luna "wikilink") wiki page (dw) **Done.** + Updated categories of "standard" documents. Updated some FAQs. + Pointed "SimRel" to "Luna". + - Complete Google Calendar. (dw) + - Compute Luna SR dates. (dw) + +## Kepler Retrospective + +For reference, see +[Juno_retrospective](Planning_Council/Juno_retrospective.md). + + - what worked: + + + + - what could be better: + + + + - + ''For both categories, it was felt most had "already been said" (in + our on going meetings or previous retrospectives). '' + + + + - + *But one new concern was brought up: That "release engineering" is + not a very "diverse team" (Markus and David) ... and the concern was + "what do we do if they stop doing it". While no one volunteered to + help :) it was taken as a valid point to document. Briefly discussed + "getting help from Eclipse Foundation", but at same time we wanted + it to remain a "community driven" activity in general ... that is, + those that have a vested interest in producing and consuming the + release should be "in charge" ... and not become a "corporate + activity". But, perhaps there could be some help with tools, and + similar from Eclipse Foundation? Should b3 aggregator or EPP build + become part of "CBI project"? At a minimum, need to make sure some + of the process and mechanics are well documented so others could + "take over" when necessary.* + +## Next Meeting + + - November 6, 2013 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Juno + retrospective](Juno_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/October_3_2018.md b/wiki/Planning_Council/October_3_2018.md new file mode 100644 index 0000000..40ed31f --- /dev/null +++ b/wiki/Planning_Council/October_3_2018.md @@ -0,0 +1,204 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Oct 3, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Temporary Planning Council Chair: Nick Boldt Planning Council Chair: +Melanie Bats (returns Dec 2018) + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +Nick Boldt, Frederic Gurr, Martin Lippert, Pierre Charles David, Tom +Watson, Dani, Mikael Barbero, Alex K + +## Agenda + + - \[Wayne\] Simultaneous Release Dates for 2018-12 - + + +:\* CQ submission deadline + +:\* Nov 28 - IP log submission deadline + +:\* Dec 5 - Review and N\&N due + +:\* Dec 19 - Release reviews + +:\* Dec 19 - Eclipse SimRel 2018-12 GA + + - \[Wayne\] Opt-in rules: announcement requirement? join-in/drop-out + deadline? + +### Bonus Bikeshedding Topic + + - \[Wayne\] Eclipse *Placeholder* IDE for Java Developers, 2018-12 + Edition" is created from the "Eclipse *Placeholder* Simultaneous + Release": what could we use for *Placeholder*? + +## Regrets + +## Notes + +### Schedule, Dates, Opt-in vs. Opt-out + +Dani/Wayne: Rather than opting in, we throw everyone out (disable all +aggregator files) and they re-add themselves if they're not a new +project. + +Fred: We used to do this, but because some projects didn't reply in +time, this broke some M1 builds. We decided to opt-out instead of opt-in +to avoid needlessly broken early builds. + +Wayne: I can't recall which approach we prefer. Dani: We decided not to +throw out projects as this would be too disruptive (see Fred's comment). + +Dani: what's wrong with using the release record for opt-in? + +Wayne: Even simpler than having to update release record, we would just +have this opt-in recorded in aggregator files. + +Dani/Wayne: we should enforce no /latest/ URLs in aggregator files, so +it's more obvious that people are opting in, contributing new builds. + +Wayne: if you're new, you must announce yourself. Existing projects w/ +breaking changes should announce those changes (eg., platform 4.10 +dropping 32-bit support). + +**AI**: Wayne: add a new date to the simrel schedule for when an +announcement is send to cross-projects@, to report who we think is +participating. If URLs are found w/ /latest/ or snapshot, they should be +disabled? + +**AI**: Wayne: send note to cross-projects@ to announce not opting in + +Fred: auditing will be in place to prevent late changes / new features +being added after M3, eg., as simple as disabling jenkins jobs? + +**AI**: Wayne: update "ASAP" re: "Create your release record (for new +releases)". Actual date is on/before Oct 19. + +**AI**: Wayne: create a wiki page for N\&N so projects can choose to +post their content. Deadline 2 weeks before GA (Dec 5). Offer of help +from Lakshmi? + + - + **AI**: Dani: to follow up if Wayne doesn't find Lakshmi's email + +**New** projects must join by M1, Oct 19 (not Oct 5 as previously +suggested). + +### Bikeshedding + +2 questions from the Foundation to solve: + + - TLP rename + - simrel rename + +Dani: (for TLP) show me the rules where it says the name must be +trademarkable + +Alex: who is responsible for maintaining this doc? how can we get it +changed/evolved? + +**AI**: Wayne to produce documentation re: rules and send to +planning-council list + +### ECE Planning Council Meetup? + +Dani: who will be at ECE? Arch council has a breakfast. We could do a +planning council meetup. Fred/Dani/Wayne to plan a meeting + +Wayne: if you want informal we can do that; if more formal might require +some effort to plan + +**AI**: Dani: send email to planning-council list to see who'll be at +ECE and who would want to meetup. + +### Simrel status + +2018-09M1 had some challenges, but plans are in place to avoid those +problems when we start up 2018-12 M1 soon. + +**AI**: Fred restrict pushing to simrel w/o gerrit review + +### Portal sunset + +Everything should be moved over to +already, but if you find anything that isn't please email wayne / open a +BZ with links/details. \ No newline at end of file diff --git a/wiki/Planning_Council/October_4_2017.md b/wiki/Planning_Council/October_4_2017.md new file mode 100644 index 0000000..0b5cbce --- /dev/null +++ b/wiki/Planning_Council/October_4_2017.md @@ -0,0 +1,230 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, October 04, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - OBEO (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) - R + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Oxygen.1a status (by Fred Gurr/Mikael Barbero) + - Photon update (by Fred Gurr/Mikael Barbero) + - EPLv2 adoption schedule for projects involved in Photon? (by Mélanie + Bats) + - Results of the brainstorm about the future of the SimRel / New Java + SE release schedule ? (by Mélanie Bats) + +## Notes + +### Attendance + +Aleksandar Kurtakov (Tools Project), Carl Anderson (Eclipse Web Tools +Platform Project), Dani Megert (Eclipse Project), Frederic Gurr (Eclipse +Foundation), Mélanie Bats (Obeo), Mikael Barbero (Eclipse Foundation), +Thomas Watson (IBM), Wayne Beaton (Eclipse Foundation) + +### Regrets + +Martin Lippert (Eclipse Cloud Development PMC) + +### Oxygen/Photon status (by Frederic Gurr / Wayne Beaton) + +#### Oxygen 1.a + + - Oxygen 1.a RC2 October 06, 2017 + - Oxygen 1.a GA October 11, 2017 + +The projects declaring their intents to particiate to this special +release to contribute Java9 and Junit5 related features are : Equinox, +MPC, WTP. This release will also include the fix for the MacOS issue: + + +Wayne raise a question to the planning council about the fact that +potentially if the Oxygen 1.a will be released as we do for the other +classical releases, due to the updates about Java 9, it could break the +IDE of 1.6 million people after the automatic update. Wayne proposed to +keep the oxygen 1.a separated from the main repo and just disseminate to +users who just want to do Java 9 development. Wayne was asking if enough +people had already tested the JDT update to Java 9 through the +marketplace available install, according to the results he got, it seems +that it represents around 2% of the IDE users. Dani and the JDT team are +confident and the only issues they got at the moment are VM arguments +problem which is fixed for Oxygen 1.a. Today people using Oxygen.1 and +trying to run under Java 9 result to a non starting IDE. After +discussing the pros and cons the planning council decided to keep +releasing Oxygen 1.a as a classical update release. We all agreed that +if a major problem is detected after this update a respin will be done +as quick as possible to fix it. + +#### Oxygen.3 / Java 18.3 + +Today Oxygen.3 is scheduled for March 21, 2018. In the past, we decided +to not move the Oxygen.1 release to provide Java 9 support and we +decided to release a special Oxygen 1.a. This in the end, confuse +people. So the question is do we want to adjust update.3 ? and so do not +no provide an update3.a ? The main problem for us at the moment is that +Java declared that they will do a release in March 2018 but they do not +define a clear date. Another question was raised that we pay attention +to the Java release schedule, but we do not care about C or PHP? Which +are important for CDT and or PDT? + +#### Photon + + - Photon M2 September 22, 2017 + - Photon M3 November 03, 2017 + +Intent for participation is running pretty smoothly. + +### EPLv2 (by Mélanie Bats) + +Mélanie asked for more precision about the EPL 2 and if the planning +council should propose a schedule for the projects who want to update +their license to coordinate or if we just let the projects do it when +they want. The first press release by the foundation was not clear +enough about this as it said : "Users and adopters of Eclipse projects +should expect the next release of each Eclipse project will be using EPL +v2." View : + + +Wayne said that the projects can move to EPL 2 when they want, there is +no specific requirement to update and he is trying to provide all the +expected documentation, CQs... about this before the end of the year. He +will send a mail on cross project also to clarify this. + +Mikael will work on adding the EPL 2 to CBI as today projects using the +shared licence can not update to EPL 2, and the recommended practice is +to use the shared licence when a project participate to the SimRel. + +### Brainstorm about the future of the SimRel (by Mélanie Bats) + +The document used as the base for the discussion is available on : + + +The planning council seems to agree that an evolution of the SimRel +habits would be useful and that we should give up the year long ramp up +to provide a predictable short release cycle. Some point have to be +discussed then to see how we go further: + + - What it would be exactly ? The idea is to provide no more update but + a new release each time with only one stream. In that case code + names seems meaningless. + - How do we release it ? An option would be to keep only one + repository in place and continuously update it which means from the + users point of view new stuff with every release. + - What would be the cadence ? A quarter release (every 12 weeks) looks + feasible as it is more or less corresponding to the actual + milestones cadence. The main change is that those "milestones" are + considered as releasable. + - How do we ensure API stability & compatibility ? When projects can + make API break? How do we organize API freeze ? How do we deal with + bigger features more than a release ? + - How do we organize the verification & tests in order to evolve from + a by hand homologation to a more automatic one ? + - If we imagine that the developments could be done organized on the + new release cycle, do the EDP delays, release review and manual IP + log would scale ? + +Mélanie proposed to continue this discussion on the mailing list to get +the maximum of opinions and be able to propose a new plan. + +Mélanie proposed also to discuss this topic with the architecture +council and Wayne proposed to organize a planning council meeting at +EclipseCon Europe during lunch time or just to 'hijack' the architecture +council meeting to discuss this with more people. \ No newline at end of file diff --git a/wiki/Planning_Council/October_6_2010.md b/wiki/Planning_Council/October_6_2010.md new file mode 100644 index 0000000..85566e4 --- /dev/null +++ b/wiki/Planning_Council/October_6_2010.md @@ -0,0 +1,393 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, October 6, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=10&day=6&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne [and Paul Webster]

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

X

Brian Payton

Datatools (PMC)

Y

Anthony Hunter

Tools (PMC)

N

Oisin Hurley

Stp (PMC)

N

Ed Merks

Modeling (PMC)

Y

Thomas Watson

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

N

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

N

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

N

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

N

Christian Kurzke

Motorola (Strategic Developer)

N

+

Appointed

+ + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

+


+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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - ? + +## Helios SR1 + + - Any issues? complaints? + + + + - One issue to document as feedback (that I have heard about from TPTP + PMC/Planning Council Rep): EMF didn't deliver any maintenance until + the day after RC4 +1 day \[but, unclear to me is if that was just + download zips or any form of delivered fixes, even in helios repo?\] + I think, it deserves repeating that communication is key. We all + need to make an effort to keep others informed. The late (or last + minute?) changes caused TPTP to have to do a lot of re-work and was + made worse by there being no notice or announcement on cross-project + list. I'm sure there's many things that could have been different, + from all teams involved ... but just documenting this case as once + example of the importance of keeping others informed. Not to + mention, of course, that incremental delivery of fixes allows for + better testing. I also suggested the TPTP team communicate more + directly with EMF team either through their mailing list or + cross-project list, to let them know when impacted, but I think in + this case, by the time it was discovered there wasn't much to do. + Anything we, as Planning Council, can do to help situations like + this? Foster timely communication? + + + + - + + - + *Ed said they will communicate better in future.* + + + + - The build machine failure and slow recovery was nearly enough to + derail the scheduled release. Not sure what more we can do, but glad + to hear IT team will provide more support for build machine recovery + (See ). + + + + - The mirrors were a bit overloaded with our "outflow" the day or two + before, and had trouble "catching up". + + + + - + There is no longer any need to wait until "day before" for projects + to put their artifacts in their final location, as long as leave + "invisible" until the official release. Everyone waiting until the + day before means the mirrors are very busy pulling content the day + before, and have trouble getting caught up and in a steady state + before the actual release. So, one action is to make sure everyone + is properly educated about his. It might take some thing more formal + ... some projects promote 5 days before, some 4 days before, some 3 + days before, etc. Also, may need better directions on how to promote + but leave invisible ... perhaps many projects wait and promote at + last minute because they don't know how to do that?'' + +### Maintenance Schedule + +SR2 Fourth Friday of February 2/25/2011 + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Helios Retrospective + +Any additions? *No additions. Move to reference section.* + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +## Indigo Status + + - M2 repo successfully created *\[discovered after meeting I forgot to + promote\! Done now\]* + + + + - No M2 EPP packages + + + + - + + - + And I've pestered Markus enough he's stopped returning my + emails? :( + + + + - 3 projects not in M2: + + + + - + jetty + riena + subversive + + + + - + Do they really intend to drop out? Or does this violate "once in + always in"? + + + + - + + - + *Tom with discuss with jetty and riena, Wayne and/or Chris to + discuss with subversive* + +## Indigo Plan and Schedule + +[Indigo +Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + +Suggestions during meeting: + + - Make explicit that to be in repo, feature includes must be strict, + so installs or builds are reproducible. (Even if there might + eventually be improvements that allow additional features, with + loose constraints ... but "minimum" requirement is the strict + inclusion. Unclear what loose requirement solution will be. Note: + the strict requirements are the way things are currently done ... + just best to make explicit, since it has come up before. + + + + - Move capabilities to "good citizen" section (and check wording to + make clear that to document "not supported" is one option ... or, + possibly "we don't know what this means" :). + + + + - Consistent license. No real change to requirement, but should + provide pointers to bugs where standard "user agreement" may change + (to include EDL) and where p2 may be improved to allow pointer to + URI ... or something. + + + + - Add a "must do" to be in EPP package, must run on/test on Eclipse + 3.7. + + + + - Add a "should do" to have a 4.1 theme item in plan to describe what + project is doing for 4.1 (and give some examples). + +Tracking "setup" required from Foundation in + +See initial [Indigo Wiki page](indigo "wikilink") + +Review: There is a subtle implication of specifying Java 6 as "minimum +runtime" requirement. Currently, we require contributors to use Java 5 +when using pack200, since if not, and if involves a jar that contains no +Java (e.g. source or documentation) then it can not be unpacked with +Java 5, Java 6 would be required. This has been a headache for people +since for many it means tweaking build scripts so an "old" (1.5) VM is +used for that one step. During aggregation, we purposely use Java 5 to +catch errors in this regard. For Indigo, I propose we not worry about +being consistent here, and just use Java 6 during aggregation. Some +projects may still want to use 1.5 VMs to do their pack200 ... if their +adopters want it ... but I see no reason for mass consistency here ... +if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent? + + - + *Some concern expressed, but mostly a matter of letting people know + and documenting options. For example, for projects that **want** + compatibility with VMs less than 1.6, they still can, of course, but + will no longer get "built in" test from aggregation. Plus, should + make clear, even a VM less than 1.6 can still use a pack200 (or, an + unpack200 executable) from another VM, such as a 1.6 distribution, + and [specify it on their command + line](Pack200#Pack200_Executable_location "wikilink") using + `-Dorg.eclipse.update.jarprocessor.pack200`.* + +### Issues and Proposal for 3.7 versus 4.1 + + - See working notes in + + +## Other business + + - ''We were reminded Mylyn is Top Level project now, and we should be + sure to invite rep to Planning Council. '' + + + + - *John mentioned Platform may drop Motif support from swt ... + decision not final yet, and not sure if it effects any adapters or + members ... just giving a heads up* + +## ToDo Items + + - *Note from Wayne, to Wayne: (actually from last meeting) Remember to + review plans starting after M4 (at latest) so questions can be + clarified before "road map" produced.* + + + + - *Wayne teased us all with promise of new tools to check CQs against + downloads, which we projects can use ourselves ... but he wasn't + ready to tell us about them today and he'll be saying more over next + few days or weeks.* + + + + - *dw to sort out tracking path.* + +## Next Meeting + +November 3, 12 noon Eastern + +## Reference + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/Sept_03_2008.md b/wiki/Planning_Council/Sept_03_2008.md new file mode 100644 index 0000000..bdb3975 --- /dev/null +++ b/wiki/Planning_Council/Sept_03_2008.md @@ -0,0 +1,70 @@ +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday [Sept 03, 2008](Sept_03,_2008 "wikilink") at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2008&month=9&day=3&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, please see the [Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + - Richard Gronback + - Neil Hauge + - David Williams + - Philippe Mulet + - Brian Fitzpatrick + - Anthony Hunter + - Ed Merks + - (Add your name here...) + +### Regrets + + - Oisin Hurley + - Doug Gaff + - Markus Knauer + +## Topics + + - Galileo [Requirements for + Participation](Galileo_Simultaneous_Release#Requirements_For_Participation "wikilink") + - begin to discuss each (keep, toss, amend) + - Accessibility? New project at Eclipse to aid in development + guidelines? ACTF? + - How to verify? Tooling? Checklist updated per milestone? - We + need to define a process of validating. Use bugzilla? (use + priority for must/should do, assign milestone, assign to each + project for each item and track with report?) + - Make capabilities definition a must-do? Package separately? + - Add Babel participation as a must-do? Need agreed upon date for + string freeze for localization. + - Increase importance of API usage violations? Make a "strong + recommendation"? Advertise tooling/best practices. Document all + exceptions with plan for migration off improper usage, including + bugs submitted to open API where required. + - Order should do list by priority. + - Suggest M6 as API freeze for all (documented?) + - Suggest M7 as the latest performance & scalability testing for + all projects (currently, the milestone used by platform) + - Look in RSS feed requirement + - Splash page icon (\#12) + - About dialog icons? + - Combine Encouraged and Could Do into Must/Should do list (or, + use P1-P4 in bugzilla?) + - Define what is found in an SDK to provide consistency (finally)? + - In person meeting to coincide with + [EclipseWorld](http://www.eclipseworld.net) + - December 10-11, 2008 - plenary session with Board + +## Additional Topics + + - IP process improvement discussion with Janet Campbell - conflict for + this call, so perhaps the next? + +## Action Items + + - Query Babel project for string freeze deadline and participation + requirement info (Rich) + - Query ACTF for information on accessibility to include as release + requirement (Rich) + - Investigate the use of p2 to create a "virtual" simultaneous release + update site, sans the jar copying (Rich) + - Look into having a "name that train" contest to coincide with + EclipseCon each year (artwork as well?) (Bjorn) \ No newline at end of file diff --git a/wiki/Planning_Council/September_02_2009.md b/wiki/Planning_Council/September_02_2009.md new file mode 100644 index 0000000..9a73794 --- /dev/null +++ b/wiki/Planning_Council/September_02_2009.md @@ -0,0 +1,550 @@ +## Logistics + +| | | +| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, September 02, 2009, at [1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin](http://www.timeanddate.com/worldclock/fixedtime.html?year=2009&month=9&day=2&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

Y

John Arthorne

Eclipse (PMC)

Y

Oliver Cole

Tptp (PMC)

N

Brian Payton

Datatools (PMC)

Y

Doug Gaff

Dsdp (PMC)

Y

Anthony Hunter

Tools (PMC)

N

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)

N

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Y

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)

R

Christian Kurzke

Motorola (Strategic Developer)

N

+

Appointed

+ + + + + + + + + + + + + +

Wayne Beaton

Eclipse Foundation (appointed)

Y

Mike Milinkovich

Eclipse Foundation (appointed)

N

+


+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 Members + + +++ + + + + + +
+ + + + + + + + + + + + + + + + + +

 ?

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 SR1 + +Any issues? + +*none report at meeting* + +## Helios + +### Goals + + - Simultaneous Release of participating projects + +:\*Includes Simultaneous Milestones and testing (within the defined +windows) + + - Improve Eclipse by having extra release criteria + +:\*These criteria, as previous years, need general agreement, and buy-in +from all projects represented by Planning Council. + +:\*The criteria are primarily in the interest of Strategic Members to +improve adoption, and in most cases benefits end-users as well. + + - Provide a "Common Discovery" repository, primarily for end-users, so + they can explore and discover interesting and useful function, + without having to try so hard. + +:\*This improves "early testing" of Projects, and eases migration to the +new release. + + - ~~(new?) Provide a single code repository for extenders and + committers to ease their development.~~ + +:\*~~Is this one we really want to support? As committers, we often lean +this way ... but, it is more work to do right, and in some cases can be +at odds with the "ease of use" goal of a repository for end-users.~~ + + - + ''At meeting, this last item raised little discussion. Someone will + need to champion it for us to add as a goal. '' + +### Items to improve this year? + + - the aggregation process (previously misnamed "the build"). + - accessibility + - capabilities: definitions, reuse, and contribution process? + + + + - + ''Note: This item was questioned "is it really needed" ... "are any + adopters making use of it". The answer from most on PC was "no, not + using". One said "yes, but just rolls their own, just uses to run + off some UI". One (ok, me) said "yes, we'd like to, for complicated, + large installs of multiple products with optional pieces, but is + currently unworkable". It appeared no one else on the call was aware + of the "progressive discovery" aspect of capabilities (which would + be the one requiring the most work from cooperating projects). '' + + + + - Structure and content of Common Discovery Site (e.g. categories, + classifications, allowable content) + +:\*minimal IDE runtimes vs. distributions for extenders + +:\*how to distinguish and organize IDE functional tools from runtime +targets + +:\*four divisions required? code, source, end-user doc, extender (sdk) +doc + + - How to track compliance? + +:\*bugzilla vs. web app? + +:\*Granularity of tracking (sub-Projects vs. Top Level Projects)? + + - + *This last item (how to track) generated the most controversy. + Several thought the bugzilla system wasn't great, but not sure bad + enough to invest in improvements. But, several thought "was + terrible" and unworkable. As someone who had to monitor all 33 + "projects" I agree its unworkable and not very meaningful. + Conclusion: needs work.* + + + + - Quick notes of comments from others at meeting + +:\* Doug + + - + + - + none, except that he didn't want to go first :) + +:\*Neil + + - + + - + The "must do" issue, and noted there are some items already in + the "feedback notes" from last year. + +:\*Tom Watson + + - + + - + IP. How to avoid mistakes, like the "mis-release" of one project + last year, which had to be removed. + Wayne mentioned he knew this was an issue and he has an + agreement with IP team to do more "manual" checking of IP logs + compared to distributions. But more work needed to better + automate. Also mentioned more could be done by mentors and PMC. + *wtb For completeness, when an IP Log is submitted, I download + the latest milestone build from the submitting project and + compare the contents of that file with the log. I work with the + project to resolve any discrepancies before greenlighting the IP + team to do their review. IMHO, this is very late in the process; + we need to make sure that problems are resolved earlier in the + process. Perhaps we can draw on the Architecture Council + mentors, and/or the PMCs to help* + +:\*Brian Payton + + - + + - + Was interested in marking bundles as 'code', 'source', + 'documentation' to improve ease of installs. + + + + - + + - + Most concerned with API compatibility and binary compatibility. + I suggested adding a 'release criteria' that (at least) projects + must document their policy. + +:\*John Arthorne + + - + + - + bugzilla tracking was awkward + better document "why" important (John volunteered\!), such as + "here's why it is in your best interest". + We will need all projects to use some new "standard" license to + property fit into new install dialogs (which groups items by + license, to make that agreement step easier (or feasible?). + +:\*Chris + + - + + - + API tools and usage scans should be a "must do" (boos broke out + in the virtual room). :) + PDE team can help incorporate this in builds/tests (another + volunteer\!) + +:\*Kaloyan + + - + + - + would like to see easier updates from one release to another. + p2 errors are obscure + +:\*Stefan + + - + + - + Would like to see structure of common discovery site improved + (was that another volunteer?) + +:\*Cedric + + - + + - + Would like to see more testing of packages fitting together, + such as ui consistency, functional testing, etc. + +:\*Oisin + + - + + - + ease pain of 'compliance' of must do items + he would like building-in api and usage tools (as a should-do + item) + +:\*Ed + + - + + - + Can't burden projects with more 'must do' items (but ok to ask + to document items). + +:\*Wayne + + - + + - + Granularity is problematic. Last year, "number of" projects was + 33 vs. 51 depending on how you counted. + IP compliance issues. Would be better if logs were earlier. + - + My note after meeting: perhaps we could have more checking + on a milestone-by-milestone basis? Especially if "diffs" + could be generated automatically? + +### Proposed (initial) process + + - Continuous Milestones (beginning with M1) + - Form cross-project teams to come up with recommendations for + Planning Council + +:\*Anyone can participate, but I'd like to be only on invitation from +Planning Council, to be sure we have a balanced, but diverse +representation that mirrors the composition of the Planning Council. + +:\*Planning council to act on those recommendations (one way or +another). + + - Not only better document and clarify criteria, but also refine their + measuremet when possible (so, not just "yes or no', but, when + possible "poor, medium, excellent", for example). + - ~~Require a "planned compliance" statement as part of the "standard + plan"?~~ *Not discussed at meeting. I doubt it would be useful + wihtout a vastly improved "tracking" system, which will be hard + enough to implement. * + +### Proposed (initial) Cross-Project Teams + +#### Aggregation + + - + John Arthorne (Platform) + Thomas Hallgren (Buckminster) + +#### Accessibiity + + - + Tammy Strum (IBM) + Neil Hauge (Oracle) + Kaloyan Raev (SAP) + ACTF (they will decide exactly who later this week) + +#### Capabilities + + - + Tim deBoer (IBM/WTP) + Oleg Besedin (Platform) + +#### Structure of Common Discovery Site + + - + ? + +#### How to track + + - + ? + +### 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) + + + + - + Notes regarding the +0, +1, +2, +3, EPP, and 'available' days + :\*The first three milestones use a two-week window and the + remaining milestones use 1-week windows. + :\*The sub-deadline patterns within the windows are as follows: + +| \+0 | | \+1 | \+2 | \+3 | EPP | Available | +| ------ | --- | --- | --- | --- | --- | --------- | +| Friday | Sat | Sun | Mon | Tue | Wed | Thur | + +2-week window pattern + + - + + - + + +| \+0 | \+1 | \+2 | \+3 | EPP | Available | +| ------ | ------ | ------- | --------- | -------- | --------- | +| Friday | Monday | Tuesday | Wednesday | Thursday | Friday | + +1-week window pattern + +::\*This pattern was arrived at with a couple of considerations: a) it +is very important that teams have a consistent rhythm (so, for example, +easier for a team to "always deliver on Tuesday" rather than Monday's +some milestones, Thursdays other milestones, etc. b) it represents the +**latest** possible time to produce common-discovery site ... teams can, +still, either on their own or work with other projects to do their final +builds earlier, making their delivery available earlier to specific +teams or test groups. + +::\*Remember, the +n categories represent **latest** possible time to +complete what is required of common discovery site (generally, at noon, +Eastern time, of the day). Teams have to do their builds and testing +before these common-site deadlines. + +::\*In general, teams often have complicated inter-dependencies which +are not captured by the simple "+1", "+2" descriptions. In those cases, +it is up to those projects to work out their detailed inter-dependencies +and agree to a processes to satisfy what they need from each other. The +dates and deadlines listed by Planning Council, apply only to the final +deliverable to the common repository. + +## Review Planning Council/Galileo postmortem + + - + + - + We'll continually review [the list of + comments](Galileo_postmortem.md) to + make sure issues are addressed, action plans made, owners found, + etc. + +## ToDo Items + +(volunteers welcome) + + - create (and update) [helios container + plan](http://www.eclipse.org/projects/project-plan.php?projectid=helios) + (Wayne volunteered) + + + + - coordinate community input for next year's name + +## Next Meeting + + - + [October 7, Wednesday](October_07_2009.md), + Noon Eastern Time. + +## Reference + +[Helios Simultaneous Release](Helios_Simultaneous_Release "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous_Release_Roles](Simultaneous_Release_Roles "wikilink") +and +[Simultaneous_Release_Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_02_2015.md b/wiki/Planning_Council/September_02_2015.md new file mode 100644 index 0000000..adb9f11 --- /dev/null +++ b/wiki/Planning_Council/September_02_2015.md @@ -0,0 +1,499 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 2, 2015, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

John Arthorne (occasional)

Cloud (PMC)

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel (Sam Davis)

Mylyn (ALM) PMC

D

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Nick Boldt

Redhat (Strategic Developer)

Y

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y?

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before meeting, but if questions or + issues with previous minutes, this would be a good time to bring + them up. + +## Mars Planning + + - Any issues? + + + + - How is the "minor releases" in Mars.1 update going? + + + + - + \- From the little I've seen, no radical change, but some change. + \- Some just being "more honest" about it (that's good). + \- Have seen the issue where changing "provisional API" to "API" is + reason for the minor bump + - + But, this can be "breaking" for anyone who was trying to use the + provisional API (depending). + Should we give any guidance in this area? + \- Have seen where "new features" would break translations. + - + Should we give any guidance in this area? + \- I see where WTP is adding a "controversial" feature (but, just + controversial "if its ready"). + - + That is, nothing violates Planning Council rules. + + + + - + + - + *Wayne reported there had been about 6 release reviews for minor + releases.* + +## Neon Planning + + - See initial working draft of plan at + [Neon/Simultaneous_Release_Plan](Neon/Simultaneous_Release_Plan "wikilink"). + - Continuing Discussion of if and how to change "yearly release"? + + + + - + \* - See ["design" wiki + page](SimRel/ChangingProcessAndTiming "wikilink"), which acts as + centralized place to document the main ideas and plans. + \* - Rough scheduling alternatives ... what do we want to + accomplish? + + + + - + \* Current + - + \- June (3) September (5) February \[(4) June\] + + + + - + \* Current plus one (equally spaced) + - + \- June (3) September (3) December (3) March \[(3) June\] + + + + - + + - + Advantage; similar to current + Disadvantage: hard and bad to release in (mid) December? + + + + - + \* Equally spaced (based on May) + - + \- May, (3) August, (3) November, (3) February \[(3) May\] + + + + - + + - + Advantages: predictable; each roughly 2, 6 week milestones + Disadvantage: arbitrary? + have to work around Thanksgiving holiday + + + + - + \* quick plus long + - + \- June, (2) August, (5) January, (2) March \[(3) June\] + + + + - + + - + Advantage: can have quick "service" after main releases, + those features/projects that "just barely missed" main release + points (June and January) won't have long to wait. + + + + - + + - + Disadvantage: does not easily map to 6 week milestones + still has as long period (5 months) of "no releases" + but, that long period can be good for committers -- to have long + period to focus on one stream. + + + + - Any new requirements? + + + + - + \* In "signing section", I would like to add that jars that are + already signed, must not be re-signed. + - + It messes up pack200 "conditioning" + + + + - Discussion of the timing of an extra update release + + + + - + \- End result was the direction should be + - + June (3) September (3) December (3) March \[(3) June\] + + + + - + \- General agreement to keep June as the month for the main (major) + release + - + \- Partially just to keep with long tradition -- long enough it + is an ingrained expectation from community. + \- Partially to fit better with the naturally occurring "summer + down time" due to vacations and holidays. + + + + - + \- Rough agreement that the goal of an extra update release was to + solve the problem of new projects and new features joining the + train. + - + \- The problem of individual projects needing to roll-out + important fixes "off schedule" is not addressed by having an + extra release, and should (probably) be addressed by changes in + EPP packaging or perhaps only the Sim. Release repository + (which, would require some change in EPP "features", but avoid + "all new" downloads). + + + + - + \- There was some discussion of having, say, the 1st and 3rd updates + be "service only", and middle (December-ish) update release be + "minor upgrades", but in general, thought that would be confusing, + restrictive, and would not solve main problem of "getting function + out to users". + + + + - + \- Another strong candidate for "rhythm" was to stick with the + current 3 per year, but move the September one, to October, so there + is more balance of "waiting period" between update releases (4 + months each, instead of current 3 months and 5 months). + - + \- It was thought this would not work well for Neon updates, + since we want a September release that matches Java 9 release + (which is currently scheduled for September 22 - + ). + \- Also some mentioned easier for adopters and contributors to + work based on a quarterly schedule. + + + + - + \- It was explicitly decided to leave Mars as-planned (that is, + Mars.2 in February, not December) partially since many plans based + on that already, and partially to allow more issues to be ironed + out, and partially to allow time to improve testing of Sim. Release + repository -- such as to add "API Tooling checks". + + + + - + \- Wayne took as a "to do" item, to check with IP staff if a CQ + deadline should be set for update releases. + - + \- Cons (probably not needed): there are few new ones, every one + knows the limits + \- Pros (would be helpful): helps set expectations of committers + and new contributors on how much can be done, by when. + - + (Though, still varies a lot, if "all new" large + contribution, vs. piggy back CQ) + + + + - + \- Another issue to carry is effect on translations. Both those done + by Babel, and those done by adopters. Should we try to get projects + to document changes to PII? Are there any tools in Babel that could + "diff" what has changed? + + + + - + \- Another issues to carry is what guidance (or rules) to mention + about "changing API". In particular, should "provisional API" be + treated as API, or non-API? Some quick remarks was "there is not + much we can do ... if doesn't impact train projects ... would be up + to each project to decide, and up to adopters to follow closely". + Can we do better? + + + + - + \- There was a brief discussion of if more "parallel streams" would + help. That is, currently the "culture" at Eclipse is primarily to + work on new features after one release, for the next update release. + But, in general, overlapping work efforts and releases might suit + some teams better. (Such as, after June, could work on new features + for December, putting minimal effort into September release -- and + while teams can "do this on their own", would there be advantages + (or need) to having a coordinated effort -- involving several + "coordinated release repositories" for teams to contribute to early? + \-- Some mentioned projects do not have enough resources to do that + much work? + + + + - + \- Speaking of resources, it was also mentioned that the "4 releases + per year" would be more effort for projects (committers) since even + if they do not contribute to a update release, they should still + test their stuff with each new update. Improved automated testing + might help some, with this. + +## New Business + + - ? + +## Next Meeting + + - October 7, 2015 - Regular First Wednesday Meeting + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Mars Wiki page](Mars "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_03_2014.md b/wiki/Planning_Council/September_03_2014.md new file mode 100644 index 0000000..9091124 --- /dev/null +++ b/wiki/Planning_Council/September_03_2014.md @@ -0,0 +1,300 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 3, 2014, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Y

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Adrian Mos (Marc Dutoo )

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Wayne Beaton

Eclipse Foundation (appointed)

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

Birt (PMC)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Previous meeting minutes + + - Review [previous meeting + minutes](August_06_2014.md) if you'd like. + +## Luna SR1 + + - Any issues? + + + + - + + - + Several "minor" releases ... ECF, PTP, Linux Tools, ?CDT? ... + others? Nothing drastic, nor problematic that I know of (but + doesn't seem well communicated, to me?) + + + + - Do we want to have a Luna "retrospective"? If so, who wants to + volunteer to coordinate and run that? + + + + - + + - + *Decision was "no", not needed, no volunteers.* + +## Mars Planning + + - + Please Review [the plan](Mars/Simultaneous_Release_Plan "wikilink"), + especially the + [dates](Mars/Simultaneous_Release_Plan#Schedule "wikilink"). + - + We will consider these dates "final", unless there are + objections. + *Approved.* + +## Progress on Action Items + + - Split stream aggregation builds (done, last month). + - Changed "test" project to allow easier "contributions as bundles" + \[Thanks to Dennis Hübner for the suggestions, and some + improvements\] . + + + + - + + - + Implies we'll "need a build" and a "repo" for it some day. + Perhaps a candidate for "CBI"? Not sure if it needs to be + "mavenized" first? + + + + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan (Gunnar has proposed a solution he's willing to be + responsible for, and is working on a "proof of concept". See + +## New Business + + - ? + +## Next Meeting + + - October 1, 2014 - Regular First Wednesday Meeting. + +## Reference + + - + 2013 EclipseCon face-to-face follow-through action items. For + original meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Kepler + retrospective](Kepler_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_05_2012.md b/wiki/Planning_Council/September_05_2012.md new file mode 100644 index 0000000..230ec69 --- /dev/null +++ b/wiki/Planning_Council/September_05_2012.md @@ -0,0 +1,344 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, August 01, 2012, at 1200 Eastern

Dial in:

(See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

+

Phone Numbers:

+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-877-369-7806
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
+
+
+
+
Participant conference extension: 710 then enter pin 35498 +
+
+
+
+
    +
  • SIP clients:
    • +
+
+
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Y

Doug Schaefer

Tools (PMC)

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Ian Bull (Plus Jesse, transition)

Rt (PMC)

Y

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Igor Fedorenko

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Y

Achim Loerke

BREDEX (Strategic Developer)

Y

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + + + + - + *none* + +## Juno SR1 + + - SR1 coming soon\! See + [Juno/Simultaneous_Release_Plan\#Service_Releases](Juno/Simultaneous_Release_Plan#Service_Releases "wikilink"). + Issues? Problems? + + + + - + *One issue was mentioned at end of meeting, where Tycho? signing + plugin? (something) changed that broke ability to sign and produce + packed jars. \[Apologies, not sure who was speaking\]. But they said + they'd have to research more to figure out what the issue what + (they'd just returned from vacation) ... if issue was that "builder + suddenly changed on them" (and they don't know how to specify a + particular one) or if "no one is responsible for overall framework" + (or, something like that, I'm sure I'm misquoting). If this is about + then yes, jar processor should be fixed, but seems like possibly + could be worked around? But, member said they'd have to look into it + more and get back to us once they'd "caught up" from being out.* + +## Kepler + +### Continue and conclude annual debrief + + - [Juno_retrospective](Planning_Council/Juno_retrospective.md) + + + + - + Feel free to add things to the page before the meeting, if that + would facilitate discussion. + + + + - + *Mostly discussed "runtime projects" as has been being discussed on + Rt PMC list. I noted a few things in + [Juno_retrospective](Planning_Council/Juno_retrospective.md) + but was thought to be an on-going discussion.* + + + + - + Be sure to read last years: + [Indigo_retrospective](Planning_Council/Indigo_retrospective.md) + +### Begin Kepler Requirements Planning + + - [SimRel/Simultaneous_Release_Requirements](SimRel/Simultaneous_Release_Requirements "wikilink") + + + + - + Begin discussion of requirements, if changes needed. To the extent + possible, I suggest we start with high level issues this month (such + as, should any be added, removed?) and perhaps finish up with + wording changes for clarification (if any) next month. + + + + - + ''Didn't discuss much. I brought up issue of low compliance to + "greediness" issue, and as far as I know, to define everything in + features is the only way for adopters to provide patches ... so ... + either I need education, or better educate others on why important? + Or ... maybe others don't need patches? What's alternative? New + release? (which, adopters can not do "on their own", typically, such + as for a "hot fix" for one customer). '' + +## Other Business + + - What's status of new "Portal Interface"? (Wayne?). Is it (nearly) + ready to use for "Simultaneous Release data"? For example, links to + ramp down plan, accessibility support, reports? Etc. + + + + - + *Wayne said "release 1" is tentatively expected end of this month. + This would replace most (basic) functionality of current portal ... + enhancements would be added from there. To add "Simultaneous Release + tracking" (e.g. URLs for rampdown plans, accessibility, etc.), would + be considered, but "low on the list". Mostly focused on integrating + plans/releases so they are all easier, whether yearly train or not, + if I understood sentiment.* + + + + - Procedure and trade-offs for explicit "sign up" for "the next" + Simultaneous Release. + + + + - + *No one seemed to think it that hard the way it was, and was useful + to show "people still involved". Granted, more could be done with + automation, but seemed lower on priority than other things. + Concluded with asking PC members to comment on if they had opinions + or improvements.* + +## Next Meeting + + - October 3, 2012 (our regular "first Wednesday" meeting, at Noon + Eastern). + + + + - + + - + Plan for Kepler + +## Reference + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Indigo + retrospective](Indigo_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_07_2011.md b/wiki/Planning_Council/September_07_2011.md new file mode 100644 index 0000000..41fdace --- /dev/null +++ b/wiki/Planning_Council/September_07_2011.md @@ -0,0 +1,386 @@ +## Logistics + +| | | +| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, September 07, 2011, at [1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=09&day=07&hour=12&min=0&sec=0&p1=179) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

John Arthorne

Eclipse (PMC)

??

?TPTP? (PMC)

X

Mik Kersten

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos

SOA (PMC)

Ed Merks

Modeling (PMC)

Y

Jesse McConnell

Rt (PMC)

Y (with Tom Watson, "for his last meeting" :)

David Williams

WTP (PMC) (appointed Chair)

Y

Gary Xue

Birt (PMC)

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Kaloyan Raev

SAP AG (Strategic Developer)

Y

Pascal Rapicault

Sonatype (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

Christian Kurzke

Motorola (Strategic Developer)

Achim Loerke

BREDEX (Strategic Developer)

Y

width="100%" valign="top"

 + + + + + + + + +
Appointed

Wayne Beaton

Eclipse Foundation (appointed)

 + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

Nokia (Strategic Developer)

X

[no name]

CA Inc. (Strategic Consumer)

X

[no name]

brox IT-Solutions GmbH (Strategic Developer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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. + +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 +X = not expected + +## Announcements + + - *none* + +## Indigo SR1 + +### What to do about breaking changes? + +Achim: We discovered an issue where a change in Equinox broke +EclipseLink for Jubula +[Bugzilla](https://bugs.eclipse.org/bugs/show_bug.cgi?id=355484). We +filed this bug which is a showstopper for us shortly after RC1 and the +fix will be in RC4. This leaves us with very little time to do any +testing on the release (Of course we've tested this on internal builds +but the RCs where not testable). What is the recommended way to deal +with this? We could have fixed this for the EPP packages by using +specific versions of Equinox and/or EclipseLink but that would still +leave the feature in the repo unusable. + + - + + - + davidw: I think you handled it in the best way possible. First, + opening the bug, and second, drawing attention to it via your + [post to cross-project + list](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06428.html). + If you are asking if there is a way to extend the schedule for + extra time for testing, I'd say "no", we seldom have (never, so + far), and this case doesn't seem to need it. If you are asking + if there is an "escalation path", I'd also say "no" (there is, + if you feel you were being treated unfairly according to Eclipse + by-laws, but "technical issues" would seldom qualify). In other + words, "support" needs to be worked out between projects, and + there is no absolute, perfect, guarantee of support. In general, + there is certainly every intent to avoid breaking others, and + from reading the bug report, it sounds like there were two known + paths forward (fix the EclipseLink code, or the Equinox fix + could have been backed out until later). If you want to scold + the Equinox team for making a breaking change in behaviour ... + consider is done\! :) I do sympathize with them for this case + though, as it is a difficult case to deal with ... where the API + behaviour is implemented wrong, according to its documented + contract, so in fixing that bug, it is discovered someone was + accidentally depending on the incorrect behaviour. We must be + able to "fix API behaviour" but, granted, it is risky to do so + in a maintenance release and this case serves as an excellent + reminder to all teams to use great care in doing that. All in + all, this issue actually has an excellent outcome, thanks to you + and your teams testing early, and thanks to Tom Watson and Tom + Ware getting the fix in time for SR1. In other, cases, if had + been found too late, shortly after the Service Release, it would + have been impossible to "back out" the change, and would have + only left out the option of someone producing a patch to apply + after the fact. So, thank you for finding and thank you for + drawing our attention to it. + + + + - + + - + achim: Just to make this clear: we don't blame any project at + all. It was okay for the Equinox team to fix a problem in their + API and the EclipseLink team responded equally well. Since the + fix will be in RC3 we don't have a problem in testing the + release, so all changed for the good. Our heart rate is back + close to normal:-) I still don't know what would have happened + if the issue had not been resolved. Is it possible to "skip" a + service release in this case? Delivering a non-working + feature/package obviously can't be a valid solution. + +*We could not come up with general solution that would fit all cases +(after all, it is an exception, and hard to anticipate all possibilities +for exceptions) but "skipping a service release" could be one drastic +solution. A less drastic solution would have been to back out the +original fix ... as a general rule (after I have just said there were +not any :) ... is that "status quo" usually trumps "fixes" (that is, +better to have the original bug, until a better fix can be made, if a +fix causes a worse regression). The take-away message from this +experience, though, that pretty much any blocking problem can be solved, +due to the commitment and skills of Eclipse committers. It has happened +several times over the years. Thanks for reporting, thanks for fixing, +and thanks for the discussion.* + +### Tweak future SR drop windows? + +Should we tweak schedule for SR2 (and future maintenance releases)? So +weekly rhythm is same for maintenance as release? Namely, instead of +Monday (+0) to Friday, have Friday (+0) to Friday? + +*There were no objections during meeting, and I checked with John and +Kim for Platform, and they said "fine". I will change calendar, plan, +and announce to cross-project list after SR1 (to avoid confusion or +churn during SR1).* + +### Is there an issue with pack.gz files? + +I've not understood the the implications of the [cross-project +thread](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06431.html) +on this topic ... does anyone else? Is there something to fix or solve? + + - + I opened . Does seem an issue, but does not seem to be a regression. + +### Any other issues? + +*Ed gave a "heads up" that gmf-tooling might try a release and be a "new +addition" for SR1 ... as long as they fulfil the normal release and SR +requirements (such as signed jars, etc.) this is within our policy. +(but, getting pretty late\!) Ed said there were no direct dependencies +in Indigo stack, so no risk of breaking others (famous last words :). +But seriously, we do want to welcome those that make the effort to be +part of Eclipse Simultaneous Release and do what we can. It is mostly up +to the project's PMC to say "yea or nay" (and Ed said he'd support it, +if they get coordinated quickly).* + +## Indigo Retrospective + +Primary purpose is to brainstorm; to capture good and bad aspects of +Indigo Simultaneous Release. While we want items to be actionable, we do +not want to "judge" or get distracted by finding solutions, in this +initial meeting. + +We'll capture notes in [Planning +Council/Indigo_retrospective](Indigo_retrospective.md). + +Before the meeting, please review [last year's +notes](Helios_retrospective.md). + +''Useful discussion. See [Planning +Council/Indigo_retrospective](Indigo_retrospective.md) +for notes I captured. '' + +## Juno Requirements + +### Support for Eclipse 3.8 workbench + +We will have 4.2 as primary (hence the one used for EPP Packages) but +ask participating projects to have a clear plan item titled, exactly, +"Support for Eclipse 3.8 workbench" where possible descriptions might be +similar to: + + - Not at all. No support for 3.8 based apps. + + + + - We will accept bugs against 3.8 based apps, but do not test or + compile against it. + + + + - We will compile against and somewhat test 3.8, though 4.2 is + primary. + + + + - We will support 3.8 as well as 4.2, but the exact functionality may + differ. + + + + - We will support 3.8 and 4.2 equally. + +*Good discussion with Modelling Rep (i.e. Ed). He did feel sort of +obligated to support 3.8, since he knows it would "short circuit" a +whole stack of plans, if not. So, he'll look into what it'd take, at +least from a releng/build point of view (and, will likely depend on +consumers to test one of the stacks). He thinks they can do it with "one +stream", but the issue for them is their prereq versioning ranges. They +currently set ranges automatically during builds ... at least for lower +bound ... setting the lower bound to be equal to what they build +against, so, first impression, is they could build against 3.8 and that +be used for both 3.8 and 4.2 stacks. Apparently upper level is "set" to +be 5.0, or similar? Thanks for the insights.* + +## Next Meeting + + - October 5, 2011 (our regular "first Wednesday" meeting, at Noon + Eastern). + +## Reference + + - + [Indigo + Requirements](http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php) + + + + - + [Juno Wiki page](Juno "wikilink") + + + + - + [Planning Council/Helios + retrospective](Helios_retrospective.md) + + + + - + [Indigo Simultaneous + Release](Indigo/Simultaneous_Release_Plan "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_07_2016.md b/wiki/Planning_Council/September_07_2016.md new file mode 100644 index 0000000..1e3ad15 --- /dev/null +++ b/wiki/Planning_Council/September_07_2016.md @@ -0,0 +1,539 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, June 8, 2016, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Martin Lippert

Cloud (PMC)

R

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Sam Davis

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Marc Khouzam

Ericsson

Y

Alexander Nyssen

itemis AG (Strategic Developer)

R

Nick Boldt

Redhat (Strategic Developer)

R

Remi Schnekenburger

CEA List (Strategic Developer)

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Stephan Merker

SAP AG (Strategic Developer)

Markus Knauer

EPP (appointed)

(has PMC rep; Dani Megert)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

(was Gary Xue)

Birt (PMC)

X

(has/had PMC rep)

Actuate (Strategic Developer)

X

(was Rajeev Dayal)

Google (Strategic Developer)

X

Ed Merks

Modeling (PMC)

X

Adrian Mos (Marc Dutoo )

SOA (PMC)

R(2)

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - Special Guest: Fred Gurr + +*Fred introduced himself as the "new Eclipse Foundation release +engineer" and started that job around July 1. He said he will learn how +to do the aggregation builds with Mikael being his backup (if I heard +right :).* + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Neon maintenance + + - Nearing Neon.1. Any issues? + + + + - WindowBuild is back in RC3 at the declared version level (1.9.0). + - BPMN2 Modeler is back in since RC1 at 1.3.1 level. + + + + - Will soon need a Neon.1 info center () + - Create New and Noteworthy for Neon.1 () + + + + - + \- Wayne did volunteer to do N\&N for Neon.1 + +## Oxygen Planning + + - There has been a lot of discussion about "giving up release name" + and using "date" instead. See . + + + + - + \- Further discussion in the meeting lead to the idea that one thing + that is missing is what DO we call the "thing" we are releasing. + "Eclipse Neon" seems too vague and definitely sounds like a + different thing than "Eclipse Mars" (even if you add "release". Some + quick suggestions were "Eclipse IDE - Neon Version" or similar (with + dates, probably). + - \- ACTION ITEM: Doug said he would try to re-ignite the + discussion via blog or similar. + - \- Main point is that we owe the community some response on bug + 493490 about what our plan will be. + +*During today's meeting, it was decided that we can not "solve" for +Oxygen, but we can probably make incremental improvement. After that +incremental improvement, we may have a better idea of the core problem +to fix. As things are now, there is little chance of getting agreement +on what the problem is or how to fix it. It is sort of like now the +problem is "things are confusing" -- a little too broad to fix all at +once. I will comment in that we don't want to abandon the name, but +that in general, any place the "code name" is used there needs to be +more information, such as version or date or build id (depending on +context). Also, I think that "check for update" should give some +indication that a "whole new stream" is available -- as the Installer +currently does.* + + - Should we change "initial disable" practice? (See .) + + + + - + \- Is this an actual problem, or working as designed? + - + \- If working as designed, perhaps we should at least improve + expectations, somehow. + \- Or is there a way to improve "automation"? Such as, once "declare + intent" they automatically get "re-enabled" (even if project intends + to change contribution at some point). + \- Or, at least, can we improve documentation? + +*It did not take long to reach a consensus that it "punishes" those that +are trying to do things well, and does not give us very good data on +'who is not participating'. Hence we will return to "leave enabled" +(except when a project explicitly withdraws). AND we will come up with +some other ways to check on who is not participating (in the sense of +"paying attention"). Some brainstormed ideas of doing that were: check +if Git revision of aggrcon file has changed from milestone to milestone +or check if feature versions have changed from one stream to another. +Those things not changing would be "red flags" and cause some questions +to be sent to the project. M4 will remain (or return) as the deadline to +formally declare (for everyone, old and new projects) even though there +is an implicit "opt-in" for M1. Part of the reason to wait until M4 is +that most projects are not even thinking about "the next major release" +... they are working on update releases and the input to the update +release and the "next" one is the same -- especially now that we have +gone to quarterly updates.* + + - Two projects "leaving": + +:\* ECF (See [Sam's post to PC +list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02637.html)). + +:\* Riena (See [Christian's post to cross-project +list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13583.html) +and mentioned in that post). + +*We discussed if a) this was a sign that things were too hard and b) if +projects using a non-participating project was going to cause problems. +None of us have heard concrete cases of "item a" and it seems to be more +a matter of "other things becoming more important" to the committers on +those projects. As for "item b", it may or may not be a problem. Since +we can not "force" projects to participate and since it would be +detrimental to say that projects could not "include" non-participating +project releases our only option seems to wait until there is a known +problem, and then solve as they come up. The solution could be that some +part of the "required prereq" moves to a project that depends on it. Or, +perhaps someone else becomes a commtter on that prereq project to make +fixes that they need it to have.* + +### old (ongoing) stuff + + - Release Policy vs. Release mechanics. This is being tracked in . + + + + - + In M6 we changed to have (nearly) all features to be "root features. + Now what? That is, can we "stop" adding "reference repositories" via + feature p2.inf files? + + + + - "Rolling release" issue. + + + + - + + - + I have sometimes heard it suggested we allow more of a + "continuous release". Is this something we should discuss? + Should we have some long term planning for it? Such as, what + would it take to accomplish that? + This could be planned with or without the "beta stream" + mechanisms sometimes discussed. + + + + - + '' Did not discuss much during this meeting, other than to note + similarity to above issue.'' + + + + - Should the ability to update from yearly release to yearly release + be a 'requirement'? + + + + - + + - + **Impossible now, for Neon. Right? (for EPP Packages) Do we + still need "streamless-URL" now?** I am assuming "no". + + + + - + + - + **ACTION ITEM** from 6/8 meeting. Doug volunteered to "take up" + this item to better specify "what does it mean" and "what will + it take" to update across major releases. \[Doug, it is up to + you, but I suggest you form a small team of like 3 people, such + as Ian and Dani or, others who know some of the technical + issues, to help if they are able and willing.\] The goal being + just a more specific statement of what it means, and what + projects have to do differently for Oxygen. That is, we don't + need to reach Nirvana in one release cycle.'' + + + + - + + - + What would this take? (Such as features are never "just removed" + but are replaced or transitioned?) + Preferences, views, etc. have to "migrate" (if their ID + changes). + What testing would projects have to do? + May become "defacto requirement" once is implemented. + - + For Neon we will not have a "streamless" URL, since "won't + work" for upgrading to Neon for the EPP packages. + +## New Business + + - Dani: Does any feature, independent how small (e.g. new option), + force a release review for the Update release? Does it require full + review doc, or is there a way to report just the features + e.g. new + IP log? + + + + - + \- Good question, for Wayne? I think technically the answer is "yes" + unless something has been simplified? + + + + - + *Wayne said "yes". He did mention an "Architecture bug" () he has + opened to consider a modification to the EDP to lighten the release + burden, but that is a longer term issue. He did mention some + alternatives that might fit some cases: a) it is up to the PMC is + they think something small such as a "new preference" needs a "minor + increment". Perhaps "service increment" would suffice in some cases. + And, b) those that do need to have a formal release need not make it + as long and elaborate as they do for their yearly major release. + Just a short statement of the new feature (and release date) would + usually suffice. But, they do still need a normal "IP Log".* + + + + - In a similar vein, who is responsible for the "New and Noteworthy"? + I think Wayne did a "combined one" for the initial release. From + looking at the [version comparison + reports](https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/versionChecksFeatures.html) + it appears about 10 projects have "new minor increments" ... plus + the two that have "rejoined" the train. I have opened to cover the + specifics. But, am not sure who is the responsible "author" of the + document. + + + + - + *Wayne graciously agreed to be in charge of the Neon.1 N\&N. The + hardest part, for him, is deciding what is "general user oriented" + which is what he thinks this combined N\&N should focus on.* + + + + - *A "new business" item that we did not have time to discuss was + about the impact of the new levels of IP. Do we, as Planning + Council, want to stipulate a participating project must be of "type + B"? Or, do we not care? It may depend on "how labeled"? But he will + open a bug and/or we will discuss at the next meeting. See and + comment in .* + + + + - The remaining "new business" items are from previous meetings. I am + not sure they resolved so left them for now. + +:\* ''Wayne could not make the meeting, but posted a [message to our +mailing +list](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02606.html) +about concern over some specific projects -- some of which may have to +be "removed" from the train. But, in addition, expressed concern over +"the process". + + - + + - + \- ''I agree and commented on a similar issue on [cross-project + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13122.html) + about two projects who "declared intent", but thought they could + join the build at the last minute. '' + \- *I wondered out loud if it was time for more of a Sim. + Release process where projects had to "prove they were ready to + be in the Sim. Release" instead of us just saying what they + needed to do, and then assume they were doing it. We did not + discuss at this meeting, but, for example, I mean like a + checklist (web app) that has to be updated every milestone? Just + an idea.* + +:\* A question was raised if people have to "announce" they will be in +"Neon.1" if they were in Neon. The answer was "no". \[Did not mention it +at meeting, but they should announce if they are NOT going to be in +Neon.1.\] + + - + + - + \- This led to a brief discussion if projects should "rebuild" + if their prereqs change. For example, if a security bug is found + in an Orbit bundle. A few thought "yes", but seemed the + consensus was "there was no way we could force them to" (i.e. + can not leave them out, or else their "previous release" would + still be there with the bad bundle) and it was probably a fringe + enough case we did not need to have a rule about it. + +:\* A question was raised how we can avoid issues such as with Neon +where Window Builder was excluded for Neon. They were ready at the very +very last minute but had not done any builds or testing for all of the +Neon development cycle. Somehow, we should "detect" when projects are +not active so we can approach them early to find out if the project is +viable if they are testing, etc. + +## Next Meeting + + - October 5, 2016 - Regular First Wednesday Meeting + +## Reference + + - + Draft [Eclipse Project Branding + Requirements](http://www.eclipse.org/projects/handbook/trademarks.php) + (Wayne) + + + + - + [Neon Wiki page](Neon "wikilink") + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_12_2018.md b/wiki/Planning_Council/September_12_2018.md new file mode 100644 index 0000000..3fbd6f6 --- /dev/null +++ b/wiki/Planning_Council/September_12_2018.md @@ -0,0 +1,124 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, Sep 12, 2018, at 11:00 EDT

Dial in:

Topic: Planning Council Meeting Time: this is a recurring meeting Meet anytime

+

Join from PC, Mac, Linux, iOS or Android: https://eclipse.zoom.us/j/928841320

+

Or iPhone one-tap :

+

   US: +16699006833,,928841320#  or +14086380968,,928841320#

+

Or Telephone:

+

   Dial(for higher quality, dial a number based on your current location)：
+       US: +1 669 900 6833  or +1 408 638 0968  or +1 646 876 9923
+       Canada: +1 647 558 0588
+       France: +33 (0) 1 8288 0188
+       Germany: +49 (0) 30 3080 6188
+       United Kingdom: +44 (0) 20 3695 0088
+       Switzerland: +41 (0) 31 528 0988
+       Sweden: +46 (0) 8 4468 2488
+       Denmark: +45 89 88 37 88
+       Netherlands: +31 (0) 20 241 0288
+   Meeting ID: 928 841 320
+   International numbers available: https://eclipse.zoom.us/zoomconference?m=DufCm8dm7aEOYkLMWpY6qLgJMUtWhOnf

+ +## Members + +Temporary Planning Council Chair: Nick Boldt Planning Council Chair: +Melanie Bats (returns Dec 2018) + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Ericsson AB (Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - Obeo (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Attendance + +Nick Boldt, Wayne Beaton, Frederic Gurr, Pierre Charles David, Dani +Megert, Tom Watson + +## Agenda + +None posted in advance. + +## Regrets + +## Notes + +### \[Fred\] Simrel status: green + + - Small issues w/ aggregation + - Missing repo from RAP? Pipeline not notifying committers when + breaks happen. AI: Fred to fix today + - Gerrit trigger not compatible with pipeline job, so freestyle job + enabled instead for gerrit reviews + - HIPPs being flaky last couple days, not impacting simrel, just + upstream projects + +### \[Wayne\] Release review status: yellow? + + - Unsure if everyone has declared & approached EMO for reviews + - Concerned with projects ”breezing in late”, ie., changing things + between RCx and Final? BIRT did this for Photon. + - To prevent this, the aggregation pipeline job is disabled to + prevent new stuff being aggregated after RC + - Opt in date - is it still reasonable? + +BIRT still using their Photon contribution - is that cause for alarm +(project dormant), or does it demonstrate stability (nothing needs +changing between quarterly releases) ? More importantly, how do we know? + + - Arch council planning to change process for release reviews + annually, not quarterly. IP rules not changing. See [cross-projects + list](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15971.html) + for more info. \ No newline at end of file diff --git a/wiki/Planning_Council/September_15_2010.md b/wiki/Planning_Council/September_15_2010.md new file mode 100644 index 0000000..d97ef71 --- /dev/null +++ b/wiki/Planning_Council/September_15_2010.md @@ -0,0 +1,219 @@ +## Logistics + +| | | +| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Meeting Title: | **Planning Council Conference Call** | +| Date & Time: | Wednesday, September 15, 2010, at [1600 UTC / 1200 Eastern](http://www.timeanddate.com/worldclock/fixedtime.html?year=2010&month=09&day=15&hour=16&min=0&sec=0) | +| Dial-in: | For the call-in numbers, see the "Project Review" number on [Foundation Portal](https://dev.eclipse.org/portal/myfoundation/portal/portal.php) page. | + +## Attendees + + +++ + + + + + +

PMC (and Strategic) Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Chris Aniszczyk

Technology (PMC)

John Arthorne [and Paul Webster]

Eclipse (PMC)

Oliver Cole

Tptp (PMC)

X

Brian Payton

Datatools (PMC)

Anthony Hunter

Tools (PMC)

Oisin Hurley

Stp (PMC)

Ed Merks

Modeling (PMC)

Thomas Watson

Rt (PMC)

David Williams

WTP (PMC) (appointed Chair)

Gary Xue

Birt (PMC)

+

Strategic Reps

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Cedric Brun

OBEO (Strategic Developer)

Stefan Daume

Cloudsmith Inc.(Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Kaloyan Raev

SAP AG (Strategic Developer)

Markus Knauer

Innoopract (Strategic Developer)

R

Christian Kurzke

Motorola (Strategic Developer)

+

Appointed

+ + + + + + + + +

Wayne Beaton

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
+X = not expected

+ +## 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.

+ + + +## Announcements + + - ? + +## Helios SR1 + + - Any issues? + +### Maintenance Schedule + +SR1 Fourth Friday of September 9/24/2010 + +SR2 Fourth Friday of February 2/25/2011 + +For detailed RC schedules, see [Service Release Schedule in master +plan](Helios_Simultaneous_Release#Service_Releases "wikilink") + +## Helios Retrospective + +Any additions? + +[Helios_retrospective](Planning_Council/Helios_retrospective.md) + +## Indigo Plan and Schedule + +Tracking "setup" required from Foundation in + +See initial [Indigo Wiki page](indigo "wikilink") + +### Issues and Proposal for 3.7 versus 4.1 + + - See working notes in + + +## Other business + + - ? + +## ToDo Items + + - ? + +## Next Meeting + +[October 6, 12 noon +(Eastern)](October_6_2010.md) + +## Reference + +[Indigo Simultaneous +Release](Indigo/Simultaneous_Release_Plan "wikilink") + +[Planning Council +Members](http://www.eclipse.org/org/foundation/council.php#planning) + +[Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") and +[Simultaneous Release +Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_4_2013.md b/wiki/Planning_Council/September_4_2013.md new file mode 100644 index 0000000..4df6243 --- /dev/null +++ b/wiki/Planning_Council/September_4_2013.md @@ -0,0 +1,394 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 4, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992 (new number), 1-877-369-7806 (old number)
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members and Attendees + + + + + + + + + + + + + + + + +

width="100%" valign="top"

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PMC (and Strategic) Reps

Chris Aniszczyk

Technology (PMC)

Dani Megert

Eclipse (PMC)

Y

Steffen Pingel

Mylyn (ALM) PMC

Y

Brian Payton

Datatools (PMC)

Doug Schaefer

Tools (PMC)

Y

Adrian Mos (Marc Dutoo )

SOA (PMC)

D

Ed Merks

Modeling (PMC)

Ian Bull

Rt (PMC)

Y

Chuck Bridgham

WTP (PMC)

Y

Gary Xue

Birt (PMC)

Wayne Beaton

Eclipse Foundation (appointed)

Y

David Williams

(appointed Chair)

Y

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Strategic Reps

Cedric Brun

OBEO (Strategic Developer)

Neil Hauge

Oracle (Strategic Developer)

Y

Stephan Merker

SAP AG (Strategic Developer)

Y

Markus Knauer

Innoopract (Strategic Developer)

Markus Tiede

BREDEX (Strategic Developer)

Y

Rajeev Dayal

Google (Strategic Developer)

(PMC rep)

Actuate (Strategic Developer)

X

(PMC rep)

IBM (Strategic Developer)

X

width="100%" valign="top"

 + + + + + + + + +
Inactive

[no name]

CA Inc. (Strategic Consumer)

X

+ +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 + + - ? + +## Kepler SR1 + + - Two (known, approved) exceptions to "new features in SR1": Linux + Tools, Stardust + + + + - Any issues? + + + + - + *None mentioned* + +## Luna Planning + + - Do we have agreement on the Luna Milestone/Release schedule: + [Luna/Simultaneous_Release_Plan\#Schedule](Luna/Simultaneous_Release_Plan#Schedule "wikilink") + + + + - + *everyone agreed* + + + + - Topics for possible discussion: + +:\* Who should we scold the most for not communicating well? :) + +:\* Change policy on disabling all in M1 to require "actively joining"? + +::\* Related to Wayne's proposal on new "how to join" method: + + + - + + - + Key aspects: + - + Projects to send note to cross-project list. (How to handle + "individual projects" vs. those that release as a "group", + e.g. WTP?, Platform?) + Planning Council (or, Wayne) enters their "entry" and +n + date in database. + Deadline? M4 seems "late" for those already in? We've said + "once in, always in". Hence, how does this interact with + "disabling in aggregation"? + + + + - + ''General agreement, though some questions still to work out ... '' + ''Action items: '' + *Wayne will send note to Cross-project "in a day or two". For Luna, + he will start with initial data from b3aggrcon files that have had + contributions enabled.* + ''DW to open 2 bugs: '' + - + ''1) What are best "deadlines", in relation to b3aggrcon files. + The idea would be be something like "for those already in train, + they would "stay enabled" until after M1", then if had not been + heard from on cross-project list, they would be disabled. If not + heard by end of M3, they would be removed (since M4 is deadline + to be "in", even for new comers). '' + *2) open (or find, and change priority of existing bug), that + b3aggrcon files would be changed to conform to "project name" + pattern.* + +:\* Should "we" say anything about Java 5 vs. Java 6? (Have we already?) + + - + + - + *Not really, we already mention it in + [SimRel/Simultaneous_Release_Requirements\#Target_Environments](SimRel/Simultaneous_Release_Requirements#Target_Environments "wikilink").* + *Neil added agenda item to Arch. Council to discuss best + practices around + [Execution_Environments](Execution_Environments "wikilink")* + +:\* Should we revisit the policy about "release one month prior to SR"? + +::\* How can (or should) we better capture what new features are in an +SR for adopters awareness? + + - + + - + *There was agreement "we needed something", but flexible on + exactly what.* + *Doug took action item of working on wording of new policy for + Planning Council consideration and approval ... it'd be + something like "feature freeze by (and in) RC1 and Release + Review Materials complete by RC1". Release Materials would + include "new feature" descriptions for adopters, so that'd be + covered.* + +## On going discussions + +\[Can we turn this first one into an action item, owned by someone?\] + + - Do we need, or how can we help enable, "more frequent releases"? + Including what, exactly, that means. Such as, currently projects can + release whenever they want, but the issue seemed to be on EPP + packages and/or "prime real estate" of "Eclipse Foundations + Downloads" page? + + + + - + *We didn't address specifically, but may be covered by policy item + above and Doug's work below?*. + + + + - Doug mentioned taking over releng role? (Was going to work on + prototype before making specific proposal) \[Doug\] + + + + - + *Doug briefly mentioned he was still working on prototype, but he + didn't see it "taking the place" of any existing thing ... but, + would be "an IDE Installer" ... perhaps yet another package that + could be Downloaded from main EF DL page?* + +## Progress on Action Items + + - Editing of "Requirements Document"? (Dani and Neil) + - GSoC project for "Development Channel"? (Wayne) + - Improved "aggregator examples/doc". (dw -- no progress). + - \[Orbit plan "by end of August". (dw -- no progress -- will likely + be late, still "in September")\] + - Need to improve [Luna](Luna "wikilink") wiki page (dw) + + + + - + *No status updates given* + +## Kepler Retrospective + +For reference, see +[Juno_retrospective](Planning_Council/Juno_retrospective.md). + + - what worked: + + + + - what could be better: + + + + - + *We'll try again next month* + +## Next Meeting + + - October 2, 2013 - Regular First Wednesday Meeting + +## Reference + + - + EclipseCon face-to-face follow-through action items. For original + meeting notes, see + [March_24_2013](Planning_Council/March_24_2013.md) + and for discussion leading to action items, see + [April_10_2013](Planning_Council/April_10_2013.md). + For last status update, see + [May_8_2013](Planning_Council/May_8_2013.md). + + + + - + [Luna Wiki page](Luna "wikilink") + + + + - + [Kepler Wiki page](Kepler "wikilink") + + + + - + [Planning Council/Juno + retrospective](Juno_retrospective.md) + + + + - + [Planning Council + Members](http://www.eclipse.org/org/foundation/council.php#planning) + + + + - + [Simultaneous Release Roles](Simultaneous_Release_Roles "wikilink") + and [Simultaneous Release + Roles/EMO](Simultaneous_Release_Roles/EMO "wikilink") \ No newline at end of file diff --git a/wiki/Planning_Council/September_6_2017.md b/wiki/Planning_Council/September_6_2017.md new file mode 100644 index 0000000..7786c71 --- /dev/null +++ b/wiki/Planning_Council/September_6_2017.md @@ -0,0 +1,185 @@ +## Logistics + + + + + + + + + + + + + + + + +

Meeting Title:

Planning Council Conference Call

Date & Time:

Wednesday, September 06, 2017, 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.)

+
+
+
For all phone lines: Participant conference extension: 710 then enter pin 35498 +
+
+
    +
  • Ottawa (local call in Ottawa) 1-613-454-1403
    • +
  • North America (toll free) 1-866-569-4992
    • +
  • Germany (local call anywhere in Germany) +49-692-2224-6059
    • +
  • France (local call anywhere in France) +33-17-070-8535
    • +
  • UK (toll free) 0800-033-7806
    • +
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
    • +
+
    +
  • SIP clients:
    • +
+
+
+
call 710@asterisk.eclipse.org, then enter pin 35498. +
+
+ +## Members + +Planning Council Chair: Melanie Bats + +### Eclipse Foundation + + - Wayne Beaton + - Frederic Gurr + - Mikael Barbero + +### Strategic Members + + - CA Technologies + - CEA LIST + - Codenvy, S.A. (Tyler Jewell) + - Ericsson AB (~~Marc Khouzam~~ Marc-Andre Laperle) + - IBM (Thomas Watson) + - itemis AG (Alexander Nyssen) + - OBEO (Melanie Bats) + - Oracle (Neil Hauge) + - Red Hat, Inc. (Nick Boldt) + - Robert Bosch GmbH + - SAP SE (Stephan Merker) + +### PMC Representatives + + - Business Intelligence and Reporting Tools (BIRT) PMC (Gary Xue) + - Data Tools Platform PMC (Brian Payton) + - Eclipse Cloud Development PMC (Martin Lippert) + - Eclipse Project PMC (Dani Megert) - R + - IoT + - LocationTech Technology + - Eclipse Modeling Project PMC (Ed Merks) + - Mylyn (Application Lifecycle Tools) PMC (Sam Davis) + - PolarSys + - Eclipse Runtime Project (RT) PMC (Ian Bull) + - Eclipse Science + - Service Oriented Architecture PMC (Adrian Mos) + - Technology PMC (Chris Aniszczyk) + - Tools Project PMC (Aleksandar Kurtakov) + - Eclipse Web Tools Platform Project (WTP) PMC (Carl Anderson) + +Note: "Inactive" refers to [Strategic +Members](http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic) +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 Wayne Beaton 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 + +## Previous meeting minutes + + - Review [previous meeting minutes](../Planning_Council.md) if + you'd like. That is, review them before the meeting, but if + questions or issues with previous minutes, this would be a good time + to bring them up. + +## Agenda + + - Oxygen.1 status (by Fred Gurr/Mikael Barbero) + - Photon update (by Fred Gurr/Mikael Barbero) + - Java 9 release + - see [proposed + schedule](https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02785.html) + - Brainstorm about the future of the SimRel (by Mélanie Bats) + +## Notes + +# Attendance + +Aleksandar Kurtakov (Tools Project), Carl Anderson (Eclipse Web Tools +Platform Project), Frederic Gurr (Eclipse Foundation), Mélanie Bats +(Obeo), Mikael Barbero (Eclipse Foundation), Thomas Watson (IBM), Wayne +Beaton (Eclipse Foundation) + +# Oxygen.1/Photon status (Frederic Gurr /Mikaël Barbero) + +Fred sums up the status of the Oxygen.1 release: + + - some problems with the EPP package, it was not provided for the + first RC + - unreliable services for macOS build (UI testing, macOS bundles & DMG + files creation and signing). Mikael is trying to replace the actual + old MacMini machine by a new one not hosted anymore by the Eclipse + infrastruture, there will be two separate machines one for the UI + testing and another one for the signing services. As this new infra + will not be ready for Oxygen.1, an on demand signing is proposed for + people needing signing service. + +See the message sent by Mikael on the cross project mailing list for +details: + + +Next relevant dates for Oxygen.1: + + - Oxygen.1 RC4 EPP Thursday, September 14, 2017 + - Oxygen.1 RC4 Friday, September 15, 2017 + - **Oxygen.1 Wednesday, September 27, 2017** + +Next photon milestone, eveything is ok. Wayne ask for projects on the +cross project list to declare there intention to opt-in: + +Projects must declare before the M4 milestone. +1 and +2 projects should +declare and participate earlier as there is more consequences because of +the depending projects. If a project does not declared its intention +before M4, it will be out at M5. An email will be sent on cross-project +this week by Wayne at this subject. + +Next relevant dates for Photon: + + - Photon M2 Friday, September 22, 2017 + - Photon M3 Friday, November 03, 2017 + - Photon M4 Friday, December 15, 2017 + +# Java 9 release + +The schedule for the Oxygen Update 1a (Java 9 and JUnit 5) is: + + - **Oxygen JDT Official JDK9 release on Thursday, September 21** + - Oxygen.1a Platform RC1 on Friday, September 22 + - Oxygen.1a RC1 on Friday, September 29, + - Oxygen.1a Platform RC2 on Friday, September 29 + - Oxygen.1a RC2 on Friday October 6 + - **Oxygen.1a Wednesday, October 11** + +# Brainstorm about the future of the SimRel (by Mélanie Bats) + +The java community decided to move to a new Java release cycle with a +new Java release every 6 months in March and September starting from +2018: + +Melanie launched a discussion during the August meeting about the future +of the release train to evolve to a rolling release: + + +Mélanie asked the Planning Council members to review and comment the +following document before the next Plannning Council meeting in October: + \ No newline at end of file diff --git a/wiki/SimRel/2018-09.md b/wiki/SimRel/2018-09.md new file mode 100644 index 0000000..6153d1f --- /dev/null +++ b/wiki/SimRel/2018-09.md @@ -0,0 +1,51 @@ +This documents related to 2018-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2018. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Non-wiki pages related to 2018-09 Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2018-09) + +[Simultaneous Release Planning +Calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York) +([ICAL](http://www.google.com/calendar/ical/gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com/public/basic.ics)) + +## Important Dates + +- July 13/2018 - Opt-in deadline +- July 13/2018 - Create a Release record (required only for projects + that are releasing a new major or minor release) +- July 13/2018 - CQ Submission deadline (sooner is better; specify + that the CQ is required for the Simultaneous Release) +- September 5/2018 - IP Log submission deadline +- September 5/2018 - Review materials due +- September 12-19/2018 - Release reviews (required only for projects + that are releasing a new major or minor release) +- September 19/2018 - Eclipse SimRel 2018-09 GA + +> Note that an [IP Log](https://eclipse.org/projects/handbook/#ip-iplog) +> is a record of intellectual property for an entire project. The +> purpose of the IP Log review is to confirm that the project team +> understands the Eclipse IP Policy and is implementing the supporting +> processes. *An IP Log is not intended to reflect the intellectual +> property included with any particular release.* Project teams can +> continue to make changes to project code after submitting their IP Log +> for review. + +For milestone and quiet period dates, see this calendar: + + + + + diff --git a/wiki/SimRel/2018-12.md b/wiki/SimRel/2018-12.md new file mode 100644 index 0000000..636c830 --- /dev/null +++ b/wiki/SimRel/2018-12.md @@ -0,0 +1,46 @@ +This documents related to 2018-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2018. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Non-wiki pages related to 2018-12 Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2018-12) + +[Simultaneous Release Planning +Calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York) +([ICAL](http://www.google.com/calendar/ical/gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com/public/basic.ics)) + +## Important Dates + +- October 19/2018 - **Milestone 1** + - Opt-in deadline (new projects only) + - Create your release record (for new releases) + - CQ Submission deadline (new third-party content) +- November 9/2018 - **Milestone 2** +- November 30/2018 - **Milestone 3** + - IP Log submission deadline +- December 7/2018 - **Release Candidate 1** (no new features after + this date) + - Release Review materials due + - New and Noteworthy entries due +- December 14/2018 - **Release Candidate 2** +- December 19/2018 - **Eclipse IDE 2018-12 GA** + - Release reviews conclude on this date + +For milestone and quiet period dates, see this calendar: + + + + + diff --git a/wiki/SimRel/2019-03.md b/wiki/SimRel/2019-03.md new file mode 100644 index 0000000..54592a5 --- /dev/null +++ b/wiki/SimRel/2019-03.md @@ -0,0 +1,49 @@ +This documents related to 2019-03, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +March 2019. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Non-wiki pages related to 2019-03 Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2019-03) + +[Simultaneous Release Planning +Calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York) +([ICAL](http://www.google.com/calendar/ical/gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com/public/basic.ics)) + +## Important Dates + +- January 18/2019 - **Milestone 1** + - Opt-in deadline (new projects only) + - Create your release record (for new releases) + - CQ Submission deadline (new third-party content) +- February 08/2019 - **Milestone 2** + - [Release Participation + Page](https://projects.eclipse.org/releases/2019-03) updated +- March 01/2019 - **Milestone 3** + - IP Log submission deadline +- March 08/2019 - **Release Candidate 1** (no new features after this + date) + - API and feature freeze + - Release Review materials due + - New and Noteworthy entries due +- March 15/2019 - **Release Candidate 2** +- March 20/2019 - **Eclipse SimRel 2019-03 GA** + - Release reviews conclude on this date + +For milestone and quiet period dates, see this calendar: + + + + + diff --git a/wiki/SimRel/2019-06.md b/wiki/SimRel/2019-06.md new file mode 100644 index 0000000..bfa1ab1 --- /dev/null +++ b/wiki/SimRel/2019-06.md @@ -0,0 +1,46 @@ +This documents related to 2019-06, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +June 2019. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Non-wiki pages related to 2019-06 Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2019-06) + +[Simultaneous Release Planning +Calendar](http://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com&ctz=America/New_York) +([ICAL](http://www.google.com/calendar/ical/gchs7nm4nvpm837469ddj9tjlk%40group.calendar.google.com/public/basic.ics)) + +## Important Dates + +- April 19/2019 - **Milestone 1** + - Opt-in deadline (new projects only) + - Create your release record (for new releases) + - CQ Submission deadline (new third-party content) +- May 10/2019 - **Milestone 2** +- May 31/2019 - **Milestone 3** + - IP Log submission deadline +- June 07/2019 - **Release Candidate 1** (no new features after this + date) + - Release Review materials due + - New and Noteworthy entries due +- June 14/2019 - **Release Candidate 2** +- June 19/2019 - **Eclipse SimRel 2019-06 GA** + - Release reviews conclude on this date + +For milestone and quiet period dates, see this calendar: + + + + + diff --git a/wiki/SimRel/2019-09.md b/wiki/SimRel/2019-09.md new file mode 100644 index 0000000..c1142a3 --- /dev/null +++ b/wiki/SimRel/2019-09.md @@ -0,0 +1,100 @@ +This documents related to 2019-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2019. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2019-09 M1

Friday, July 19, 2019

07/12 to 07/19

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2019-06 GA

2019-09 M2

Friday, August 9, 2019

08/02 to 08/9

3 weeks from M1

2019-09 M3

Friday, August 30, 2019

08/23 to 08/30

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2019-09 RC1

Friday, September 6, 2019

08/30 to 09/06

    +
  • No new features after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2019-09 RC2

Friday, September 13, 2019

09/06 to 09/13

1 week from RC1

Quiet period

09/13 to 09/17

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2019-09 GA

Wednesday, September 18, 2019

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20190901%2F20190930&hl=en&mode=AGENDA) + +## Non-wiki pages related to this Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2019-09) + diff --git a/wiki/SimRel/2019-12.md b/wiki/SimRel/2019-12.md new file mode 100644 index 0000000..f532bcc --- /dev/null +++ b/wiki/SimRel/2019-12.md @@ -0,0 +1,103 @@ +This documents related to 2019-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2019. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2019-12 M1

Friday, October 18, 2019

10/11 to 10/18

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2019-09 GA

2019-12 M2

Friday, November 8, 2019

11/01 to 11/08

3 weeks from M1

2019-12 M3

Friday, November 29, 2019

11/22 to 11/29

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2019-12 RC1

Friday, December 6, 2019

11/29 to 12/06

    +
  • No new features after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2019-12 RC2

Friday, December 13, 2019

12/06 to 12/13

1 week from RC1

Quiet period

12/13 to 12/17

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2019-12 GA

Wednesday, December 18, 2019

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20191201%2F20191231&hl=en&mode=AGENDA) + +## Non-wiki pages related to this Release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2019-12) + diff --git a/wiki/SimRel/2020-03.md b/wiki/SimRel/2020-03.md new file mode 100644 index 0000000..6cb6f2b --- /dev/null +++ b/wiki/SimRel/2020-03.md @@ -0,0 +1,103 @@ +This documents related to 2020-03, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +March 2020. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2020-03 M1

Friday, January 17, 2020

01/10 to 01/17

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2019-12 GA

2020-03 M2

Friday, February 7, 2020

01/31 to 02/07

3 weeks from M1

2020-03 M3

Friday, February 28, 2020

02/21 to 02/28

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2020-03 RC1

Friday, March 6, 2020

02/28 to 03/06

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2020-03 RC2

Friday, March 13, 2020

03/06 to 03/13

1 week from RC1

Quiet period

03/13 to 03/17

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2020-03 GA

Wednesday, March 18, 2020

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20200301%2F20200331&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2020-03) + diff --git a/wiki/SimRel/2020-06.md b/wiki/SimRel/2020-06.md new file mode 100644 index 0000000..9c9e063 --- /dev/null +++ b/wiki/SimRel/2020-06.md @@ -0,0 +1,103 @@ +This documents related to 2020-06, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +June 2020. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2020-06 M1

Friday, April 17, 2020

04/10 to 04/17

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2020-03 GA

2020-06 M2

Friday, May 8, 2020

05/01 to 05/08

3 weeks from M1

2020-06 M3

Friday, May 29, 2020

05/22 to 05/29

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2020-06 RC1

Friday, June 5, 2020

05/29 to 06/05

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2020-06 RC2

Friday, June 12, 2020

06/05 to 06/12

1 week from RC1

Quiet period

06/12 to 06/16

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2020-06 GA

Wednesday, June 17 2020

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20200601%2F20200630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2020-06) + diff --git a/wiki/SimRel/2020-09.md b/wiki/SimRel/2020-09.md new file mode 100644 index 0000000..eb0ab91 --- /dev/null +++ b/wiki/SimRel/2020-09.md @@ -0,0 +1,103 @@ +This documents related to 2020-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2020. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2020-09 M1

Friday, July 17, 2020

07/10 to 07/17

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2020-06 GA

2020-09 M2

Friday, August 7, 2020

07/31 to 08/07

3 weeks from M1

2020-09 M3

Friday, August 28, 2020

08/21 to 08/28

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2020-09 RC1

Friday, September 4, 2020

08/28 to 09/04

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2020-09 RC2

Friday, September 11, 2020

09/04 to 09/11

1 week from RC1

Quiet period

09/11 to 09/15

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2020-09 GA

Wednesday, September 16 2020

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20200601%2F20200630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](https://projects.eclipse.org/releases/2020-09) + diff --git a/wiki/SimRel/2020-12.md b/wiki/SimRel/2020-12.md new file mode 100644 index 0000000..6d4ca72 --- /dev/null +++ b/wiki/SimRel/2020-12.md @@ -0,0 +1,103 @@ +This documents related to 2020-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2020. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2020-12 M1

Friday, October 16, 2020

10/09 to 10/16

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2020-09 GA

2020-12 M2

Friday, November 6, 2020

10/30 to 11/06

3 weeks from M1

2020-12 M3

Friday, November 27, 2020

11/20 to 11/27

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2020-12 RC1

Friday, December 4, 2020

11/27 to 12/04

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2020-12 RC2

Friday, December 11, 2020

12/04 to 12/11

1 week from RC1

Quiet period

12/11 to 12/15

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2020-12 GA

Wednesday, December 16 2020

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20201201%2F20201231&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2020-12) + diff --git a/wiki/SimRel/2021-03.md b/wiki/SimRel/2021-03.md new file mode 100644 index 0000000..f7f3d13 --- /dev/null +++ b/wiki/SimRel/2021-03.md @@ -0,0 +1,103 @@ +This documents related to 2021-03, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +March 2021. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2021-03 M1

Friday, January 15, 2021

01/08 to 01/15

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2020-12 GA

2021-03 M2

Friday, February 5, 2021

01/29 to 02/05

3 weeks from M1

2021-03 M3

Friday, February 26, 2021

02/19 to 02/26

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2021-03 RC1

Friday, March 5, 2021

02/26 to 03/05

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2021-03 RC2

Friday, March 12, 2021

03/05 to 03/12

1 week from RC1

Quiet period

03/12 to 03/16

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2021-03 GA

Wednesday, March 17 2021

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20210301%2F20210331&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2021-03) + diff --git a/wiki/SimRel/2021-06.md b/wiki/SimRel/2021-06.md new file mode 100644 index 0000000..26747de --- /dev/null +++ b/wiki/SimRel/2021-06.md @@ -0,0 +1,103 @@ +This documents related to 2021-06, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +June 2021. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2021-06 M1

Friday, April 16, 2021

04/09 to 04/16

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2021-03 GA

2021-06 M2

Friday, May 7, 2021

04/30 to 05/07

3 weeks from M1

2021-06 M3

Friday, May 28, 2021

05/21 to 05/28

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2021-06 RC1

Friday, June 4, 2021

05/28 to 06/04

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2021-06 RC2

Friday, June 11, 2021

06/04 to 06/11

1 week from RC1

Quiet period

06/11 to 06/15

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2021-06 GA

Wednesday, June 16, 2021

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20210601%2F20210630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2021-06) + diff --git a/wiki/SimRel/2021-09.md b/wiki/SimRel/2021-09.md new file mode 100644 index 0000000..aa13b8b --- /dev/null +++ b/wiki/SimRel/2021-09.md @@ -0,0 +1,103 @@ +This documents related to 2021-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2021. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2021-09 M1

Friday, July 16, 2021

07/09 to 07/16

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

3 weeks from 2021-06 GA

2021-09 M2

Friday, August 6, 2021

07/30 to 08/06

3 weeks from M1

2021-09 M3

Friday, August 27, 2021

08/20 to 08/27

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2021-09 RC1

Friday, September 3, 2021

08/27 to 09/03

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2021-09 RC2

Friday, September 10, 2021

09/03 to 09/10

1 week from RC1

Quiet period

09/10 to 09/14

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2021-09 GA

Wednesday, September 15, 2021

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20210601%2F20210930&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](https://projects.eclipse.org/releases/2021-09) + diff --git a/wiki/SimRel/2021-12.md b/wiki/SimRel/2021-12.md new file mode 100644 index 0000000..5fe400e --- /dev/null +++ b/wiki/SimRel/2021-12.md @@ -0,0 +1,103 @@ +This documents related to 2021-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2021. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2021-12 M1

Friday, October 08, 2021

10/01 to 10/08

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

2 weeks from 2021-09 GA

2021-12 M2

Friday, October 29, 2021

10/22 to 10/29

3 weeks from M1

2021-12 M3

Friday, November 19, 2021

11/12 to 11/19

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2021-12 RC1

Friday, November 26, 2021

11/19 to 11/26

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2021-12 RC2

Friday, December 3, 2021

11/26 to 12/03

1 week from RC1

Quiet period

12/03 to 12/07

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2021-12 GA

Wednesday, December 08, 2021

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20211201%2F20211231&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2021-12) + diff --git a/wiki/SimRel/2022-03.md b/wiki/SimRel/2022-03.md new file mode 100644 index 0000000..930cb5a --- /dev/null +++ b/wiki/SimRel/2022-03.md @@ -0,0 +1,103 @@ +This documents related to 2022-03, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +March 2022. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2022-03 M1

Friday, January 14, 2022

01/07 to 01/14

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +

4 weeks from 2021-12 GA

2022-03 M2

Friday, February 4, 2022

01/28 to 02/04

3 weeks from M1

2022-03 M3

Friday, February 25, 2022

02/18 to 02/25

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2022-03 RC1

Friday, March 4, 2022

02/25 to 03/04

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2022-03 RC2

Friday, March 11, 2022

03/04 to 03/11

1 week from RC1

Quiet period

03/11 to 03/15

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2022-03 GA

Wednesday, March 16 2022

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20220301%2F20220331&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2022-03) + diff --git a/wiki/SimRel/2022-06.md b/wiki/SimRel/2022-06.md new file mode 100644 index 0000000..b64cd56 --- /dev/null +++ b/wiki/SimRel/2022-06.md @@ -0,0 +1,106 @@ +This documents related to 2022-06, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +June 2022. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2022-06 M1

Friday, April 15, 2022

04/08 to 04/15

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
  • CQ Submission deadline (new third-party content)
    • +
    +
  • 3 weeks from 2022-03 GA
    • +
  • Good Friday
    • +

2022-06 M2

Friday, May 6, 2022

04/29 to 05/06

3 weeks from M1

2022-06 M3

Friday, May 27, 2022

05/20 to 05/27

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2022-06 RC1

Friday, June 3, 2022

05/27 to 06/03

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2022-06 RC2

Friday, June 10, 2022

06/03 to 06/10

1 week from RC1

Quiet period

06/10 to 06/14

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2022-06 GA

Wednesday, June 15, 2022

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20220601%2F20220630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2022-06) + diff --git a/wiki/SimRel/2022-09.md b/wiki/SimRel/2022-09.md new file mode 100644 index 0000000..9c7e84d --- /dev/null +++ b/wiki/SimRel/2022-09.md @@ -0,0 +1,102 @@ +This documents related to 2022-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2022. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2022-09 M1

Friday, July 15, 2022

07/08 to 07/15

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +

3 weeks from 2022-06 GA

2022-09 M2

Friday, August 5, 2022

07/29 to 08/05

3 weeks from M1

2022-09 M3

Friday, August 26, 2022

08/19 to 08/26

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2022-09 RC1

Friday, September 2, 2022

08/26 to 09/02

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2022-09 RC2

Friday, September 9, 2022

09/02 to 09/9

1 week from RC1

Quiet period

09/09 to 09/13

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2022-09 GA

Wednesday, September 14, 2022

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20220901%2F20220630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](https://projects.eclipse.org/releases/2022-09) + diff --git a/wiki/SimRel/2022-12.md b/wiki/SimRel/2022-12.md new file mode 100644 index 0000000..67a3fd0 --- /dev/null +++ b/wiki/SimRel/2022-12.md @@ -0,0 +1,102 @@ +This documents related to 2022-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2022. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2022-12 M1

Friday, October 07, 2022

09/30 to 10/07

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +

2 weeks from 2022-09 GA

2022-12 M2

Friday, October 28, 2022

10/21 to 10/28

3 weeks from M1

2022-12 M3

Friday, November 18, 2022

11/11 to 11/18

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2022-12 RC1

Friday, November 25, 2022

11/18 to 11/25

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2022-12 RC2

Friday, December 2, 2022

11/25 to 12/02

1 week from RC1

Quiet period

12/02 to 12/06

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2022-12 GA

Wednesday, December 07, 2022

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20221201%2F20221231&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2022-12) + diff --git a/wiki/SimRel/2023-03.md b/wiki/SimRel/2023-03.md new file mode 100644 index 0000000..e50a2f3 --- /dev/null +++ b/wiki/SimRel/2023-03.md @@ -0,0 +1,102 @@ +This documents related to 2023-03, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +March 2023. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2023-03 M1

Friday, January 13, 2023

01/06 to 01/13

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +

4 weeks from 2022-12 GA

2023-03 M2

Friday, February 3, 2023

01/27 to 02/03

3 weeks from M1

2023-03 M3

Friday, February 24, 2023

02/17 to 02/24

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2023-03 RC1

Friday, March 3, 2023

02/24 to 03/03

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2023-03 RC2

Friday, March 10, 2023

03/03 to 03/10

1 week from RC1

Quiet period

03/10 to 03/14

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2023-03 GA

Wednesday, March 15 2023

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20230301%2F20230331&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2023-03) + diff --git a/wiki/SimRel/2023-06.md b/wiki/SimRel/2023-06.md new file mode 100644 index 0000000..a7de4f5 --- /dev/null +++ b/wiki/SimRel/2023-06.md @@ -0,0 +1,105 @@ +This documents related to 2023-06, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +June 2023. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2023-06 M1

Friday, April 14, 2023

04/07 to 04/14

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +
    +
  • 3 weeks from 2023-03 GA
    • +
  • +0 day is Good Friday, +1 day is Easter Monday
    • +

2023-06 M2

Friday, May 5, 2023

04/28 to 05/05

3 weeks from M1

2023-06 M3

Friday, May 26, 2023

05/19 to 05/26

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2023-06 RC1

Friday, June 2, 2023

05/26 to 06/02

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2023-06 RC2

Friday, June 9, 2023

06/02 to 06/09

1 week from RC1

Quiet period

06/09 to 06/13

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2023-06 GA

Wednesday, June 14, 2023

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20230601%2F20230630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2023-06) + diff --git a/wiki/SimRel/2023-09.md b/wiki/SimRel/2023-09.md new file mode 100644 index 0000000..6550bec --- /dev/null +++ b/wiki/SimRel/2023-09.md @@ -0,0 +1,102 @@ +This documents related to 2023-09, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +September 2023. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2023-09 M1

Friday, July 14, 2023

07/07 to 07/14

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +

3 weeks from 2023-06 GA

2023-09 M2

Friday, August 4, 2023

07/28 to 08/04

3 weeks from M1

2023-09 M3

Friday, August 25, 2023

08/18 to 08/25

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2023-09 RC1

Friday, September 1, 2023

08/25 to 09/01

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2023-09 RC2

Friday, September 8, 2023

09/01 to 09/09

1 week from RC1

Quiet period

09/08 to 09/12

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2023-09 GA

Wednesday, September 13, 2023

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20230901%2F20230630&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](https://projects.eclipse.org/releases/2023-09) + diff --git a/wiki/SimRel/2023-12.md b/wiki/SimRel/2023-12.md new file mode 100644 index 0000000..ea01c58 --- /dev/null +++ b/wiki/SimRel/2023-12.md @@ -0,0 +1,102 @@ +This documents related to 2023-12, the Eclipse Foundation's +multi-project [Simultaneous Release](../Simultaneous_Release.md) of +December 2023. + +## Common information + +- [Simultaneous Release + Requirements](Simultaneous_Release_Requirements.md) + (aka must-dos) + + + +- [Simultaneous Release + Plan](Simultaneous_Release_Plan.md) - Information + that stays the same for each release, like requirements for + participation, communication channels, etc. + +## Release schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release

Date

Span

Due dates

Notes

2023-12 M1

Friday, October 06, 2023

09/29 to 10/06

    +
  • Opt-in deadline (new projects only)
    • +
  • Create your release record (for new releases)
    • +

2 weeks from 2023-09 GA

2023-12 M2

Friday, October 27, 2023

10/20 to 10/27

3 weeks from M1

2023-12 M3

Friday, November 17, 2023

11/10 to 11/17

    +
  • IP Log submission deadline
    • +

3 weeks from M2

2023-12 RC1

Friday, November 24, 2023

11/17 to 11/24

    +
  • No new features and APIs after this date!
    • +
  • Release Review materials due
    • +
  • New and Noteworthy entries due
    • +

1 week from M3

2023-12 RC2

Friday, December 1, 2023

11/24 to 12/01

1 week from RC1

Quiet period

12/01 to 12/05

No builds during "quiet period". It is assumed all code is done +by the end of RC2.

2023-12 GA

Wednesday, December 06, 2023

    +
  • Release reviews conclude on this date
    • +

5 days from RC2

+ + +[Google Calendar Link](https://calendar.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9tjlk@group.calendar.google.com&dates=20231201%2F20231231&hl=en&mode=AGENDA) + +## Non-wiki pages related to the release + +[List of participating +projects](http://www.eclipse.org/projects/releases/releases.php?release=2023-12) + diff --git a/wiki/SimRel/Contributing_to_Simrel_Aggregation_Build.md b/wiki/SimRel/Contributing_to_Simrel_Aggregation_Build.md new file mode 100755 index 0000000..0c24ab3 --- /dev/null +++ b/wiki/SimRel/Contributing_to_Simrel_Aggregation_Build.md @@ -0,0 +1,477 @@ +__TOC__ + +These instructions outline how to contribute to the aggregation build +for the common repository. + +These instructions were substantially changed in August of 2012, to +accommodate migration to new source repository, and at the same time a +rename of the main project needed from that repository. The instructions +and process for Juno (SR1 and SR2) are very similar to those for Kepler +(SR0, in June 2013) except for the branch to use to for +modifications/updates; Juno_maintenance for the former, master for the +latter. For history of migration and change of project names, see . +These instructions were also updated when moving to Gerrit, as discussed +in . However, those change are backward-compatible so there are also +relevant maintenance branches of the aggregator. + +If at anytime, there are questions, issues or problems, don't hesitate +to ask on [cross-project +list](mailto://cross-project-issues-dev@eclipse.org), or [open a +cross-project +bug](https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Cross-Project). + +## Get the simrel.build project + +The easiest way to setup and configure a specialized environment for +contributing to Simrel is to use Oomph's automated approach to create +it. Open [this +link](https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup&show=true) +in a new tab, follow the instructions, and then proceed to the [Edit the +aggregation description and +models](#edit-the-aggregation-description-and-models) +section. + +Otherwise, if you don't have it already, you'll need to install Eclipse +EGit, from common repository or their own repository at + +` http://download.eclipse.org/egit/updates/` + +You'll also need to have valid Gerrit settings (accept CLA, upload SSH +key...), as described in [Gerrit](Gerrit "wikilink") (so read +carefully). + +Then, clone the repository named `org.eclipse.simrel.build.git` and +import the project of similar name, `org.eclipse.simrel.build`. There is +only the one project in that repository. An appropriate URL would be +similar to + +` ssh://username@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git` + +For for casual browsing, see + +It is recommended that your remote branch specifies **rebase=true** to +avoid "Merge" commits. In the end, your config file for the repository +would have something similar to the following: + + branch.master.remote=origin + branch.master.merge=refs/heads/master + branch.master.rebase=true + +See the [Configuration](#Configuration "wikilink") section for more +details on the best way to set up your workspace and cloned repository. + +The 'master' branch of that repo is used for the most forward looking +release (namely Oxygen, as of this writing) and input for update +releases will be in a branch named '_maintenance' (so, for +example, Neon_maintenance is for Neon.1, Neon.2 and Neon.3). +\[Eventually this should change so "updates" is used instead of +"maintenance", such as "Oxygen_updates".\] + +## Configuration + +### Install the CBI p2Repo Aggregator + +- To be most current, it is best to use the latests Eclipse SDK + 2020-09 and use the latest 1.0.x version of the CBI Aggregator + Editor, installed from CBI's Aggregator repository, at following + URL: + +` https://download.eclipse.org/cbi/updates/aggregator/ide/4.13/` + + +\- Note: As far as is known, any EPP Package (or, plain Eclipse +Platform) should work, but, you will (naturally) also need EGit +installed to work with \*.aggrcon files -- so the Eclipse "Standard" EPP +package it a good choice to start with. + +- For more detail, see the instructions to install the [CBI Aggregator + Editor](CBI/aggregator/manual "wikilink") (and get the above + mentioned project in your workspace). + +- Open the file `simrel.aggr` using the **Aggregator Model Editor** + +### Configure the workspace + +\[This section originally copied from +[Platform-releng/Git_Workflows#Configure_the_workspace](Platform-releng/Git_Workflows#Configure_the_workspace "wikilink") +and then modified. + +Open the **Team \> Git \> Configuration** preference page and select the +**User Settings** tab. + +- Add entries for **user.name** and **user.email**. If you don't want + to share your e-mail you can also use your committer account ID. + Note that you will not be able to push changes to the repository if + the latter property is not matching with your records at the Eclipse + Foundation. +- Add entry **branch.autosetuprebase = always** + +On the **General \> Workspace** preference page, set **New text file +line delimiter** to **Unix**. + +### Configuring the repo + +This section originally copied from +[Platform-releng/Git_Workflows#Configuring_the_repo](Platform-releng/Git_Workflows#Configuring_the_repo "wikilink") +and then modified. + +To handle line-endings in the best possible way in our diverse (i.e. +multi-platform development), we recommend the same thing that [Github +recommends](https://help.github.com/articles/dealing-with-line-endings/) +as well as several [references on +Git](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace). +Namely, either globally or at least for the 'simrel.build' repository +set 'core.autocrlf' according to the platform you are working on: "On OS +X and Linux, you usually want to pass input for this setting. On +Windows, you usually want to use true." + +These settings should provide CRLF endings in Windows checkouts, but LF +endings on Mac and Linux systems and in the repository. (Note, for +"builds" we set it to "input". While we never check in changes from the +build machine, we do not want line endings changed on check-out, or else +on the next checkout or pull it may appear to Git that the "files have +changed" and it will refuse to overwrite the changes.) + +Unless you are working on topic branches, we work in a fairly linear +history. Please make sure branch.**branchname**.rebase = true is set. If +you've set **branch.autosetuprebase = always** as explained in +[\#Configure_the_workspace](#Configure_the_workspace "wikilink"), then +this is done automatically. + +Otherwise, once you've cloned a repository, you can go to the +**Preferences \> Team \> Git \> Configuration** page. Select your +repository, select the branch you picked when you cloned the repository, +and click **New Entry...**. Append "rebase" to the text in the 'Key' +field and enter "true" as value. + +![Image:RepositoryConfigurationSettings.png](RepositoryConfigurationSettings.png "Image:RepositoryConfigurationSettings.png") + +### Configuring the workspace content types + +By default, the aggr file and aggrcon file types will not be recognized +by Eclipse and thus treated as "binary" files. This, for example, will +prevent you from using the "Convert Line Endings" function on these +files. Because of several issues with Git, EGit, and mixed line endings, +we follow the convention of trying to always have only "LF" in the +repository version of the files. It is strongly recommended to have only +the "LF" version of the file in your workspace too. But, in some cases +(due to mistakes or your own settings) you may have to "manually" change +the CRLF back to LF and then commit and push those changes. + +One way to enable these file types to be seen as "text files" is to go +into content type preferences, and associate \*.aggr and \*.aggrcon +files with the content type of "XML". After doing this you may have to +go back into "associated editors" and reset CBI Aggregator Editor to be +the default editor for \*.aggr files (or, else, the XML editor will be +the default, and you really should not edit that file with XML editor, +except in very specialized circumstances). + +## Edit the aggregation description and models + +### For new project contributions + +- Create the following elements (**New Child**) under top + **Aggregation:** node or **Validation set:**. + - One or more **Contacts** (show Property View to specify both + **Email** and **Name**). \[It must be a real email, not dev + list\]. + - A **Contribution** (specify **Label** and link to **Contact**) + - A **Mapped Repository** (specify **Location**: URL of your + p2 repository) + - Your **Feature**s (select name from features found in + your repository, select **Categories** from pre-defined + set, specify exact version to be included in aggregation + under **Version Range**) +- To create your aggrcon file, select your specific **Contribution** + and invoke **Detach Resource** from the context menu. Choose a + filename like *`projectname`*`.aggrcon` (renaming this file at a + later stage is not supported). For ease of bookkeeping, it is + advisable to use the exact name of your project as it appears in the + Eclipse Foundation databases, including top level and subproject + names, as appropriate, for example, `emf-validation.aggrcon` is + preferable to `validation.aggrcon` or `webtools.aggrcon` preferable + to `wtp.aggrcon`. + + + +- Verify. Be sure to "pull" to be sure you have current contents of + every thing (with no conflicts). To ensure that your contribution + will not break the build, right-click on top-most Aggregation: node + and + +1. **Validate** checks the general XML and EMF Model validity (short + running), then +2. **Validate Aggregation** checks the whole model specifies correct + and valid repo locations and compatibility dependencies (long + running). + +- Commit and Push. At this point, you are ready to commit and push + your contribution. You will need to check in changes to the + `simrel.aggr` file, as well as your **`.aggrcon` file. + +### Updating contributions + +- To change things like Contributors (contacts), Categories, Features + (adding or removing), you should use the Aggregator Editor with the + top level `simrel.aggr` file ... as these things often have + relationships that span multiple files and you need to update, + synchronize and check-in all effected files. Note: the Categories + are normally only added or edited by Planning Council, so be sure + large changes there have been discussed via bugzilla, etc. (You can + do this via a bugzilla entry in cross-project category). + - To add a feature to an existing category, for example: Using the + *Aggregator Model Editor* with the top level `simrel.aggr` file + -- Open your Contribution, And ... + - On an existing Feature, contextMenu\>New Sibling\>Feature. + - To edit the new Feature, select it and open the Properties + view. contextMenu\>Show Properties. + - Select the Categories property, and use the "..." button + on the right to select from possible values for + Category, and Add them to your feature. + - Select the Name property, and the "down arrow" button on + the far right lets you choose from feature names. + - Save the `simrel.aggr` file which will modify your project's + `aggr` file as well. + - Now use the contextMenu\>**Validate** on your Contribution + and make sure the validation completes successfully, with no + errors flagged with red X's. + - When done, commit the `simrel.aggr` file as well as your + `project.aggr` file. (Note that other `.aggr` files may have + been re-generated, possibly simply re-ordering attributes or + changing whitespace. You can ignore these.) + + + +- To change values of feature versions, or repository URLs, you can + directly change your *`projectname`*`.aggrcon` file with text editor + (or build scripts) and check those in, in isolation. Of course, you + can and should still use the Aggregator Model Editor, and it is + often desirable to do so, as it will do a "validate aggregation" and + will tell you if something is wrong. For example, if there is a + typo, and the repository URL does not point to a valid repository, + you'll know about it right away, if you use the Aggregator Model + Editor. + + + +- Note that contributions, features, and repositories can be enabled + or disabled, via property page. This allows temporary changes with + minimal disruption. For example, if you disable a contribution or + feature, it will be left out of a category, without having to also + edit the category). This is especially useful if there is a leaf + component that is "broken" and should temporarily be omitted from + the build. **Important:** One implication of this is you will need + to sometimes re-enable your contribution or feature, even if you did + not disable it. These are sometimes disabled by others -- without + notice -- especially if a contribution or feature is causing build + breaks for an extended period of time especially if there's been no + communication explaining it or describing status or outlook on + cross-project list. Of course, fixing the issue is the desired first + choice, as disabling one contribution or feature will often require + other contributions or features to be disabled simply because they + depend on the broken one. + +### Categories + +The overall categories used in the common repository are the +responsibility of the Planning Council (in that they have the final say +about any new ones, removals, etc.). So ... please open a cross-project +bug if you'd like to propose new categories or some reorganization. But +otherwise, feel free to add or remove your features to what ever +categories you think are appropriate (using the full aggregator editor, +since two files are changed when doing so) and others will open bugs if +something seems wrong, or in the wrong category. + +### Runtime Target Platform Category + +Some features (or bundles) are not intended to be installed into an IDE +... they do not contribute to the IDE (such as menu items, etc.). By +convention, such features should be placed in the "EclipseRt Target +Platform Category". This would be the case for, say, a "server" that +someone was coding and testing for. In some cases, a runtime feature +might "cause harm" (or, change behavior) if a user mistakenly installed +it into their IDE. To prevent a feature (or bundle) from being installed +into an IDE, the current "process" is for that feature or bundle to +specify a negative requirement on a "magic IU". This is usually done in +a p2.inf file, with contents of + +`# this bundle should not be installed into IDE` +`requires.0.namespace = A.PDE.Target.Platform` +`requires.0.name = Cannot be installed into the IDE` +`requires.0.range = 0.0.0` + +The details of the "magic" solution may change in Juno, as a cleaner +solution is being discussed in ... it would be a similar "negative +requirement" but just may be on a different (non magic) IU. + +## The best format and process for contributing to Sim. Release + +### Process + +It is best to use a composite site. Users or developers installing from +the composite site, can use it's URL to install updates. But, for +building, it is recommend to use the more specific child URL, which +should have "just one" version of your features and most bundles. Less +ambiguous and faster that way. The Aggregator Model Editor works similar +to installing software, with p2, when you specify "Contact all update +sites during install" so if you have a "wide open" repository, with lots +of children, that can, in principle, cause the aggregation to look at a +lot of repositories, trying to find the "optimal solution". + +Plus, you should put the child "in place" and confirm it is correct, and +then, update your composite's content and artifacts files to add it to +the list of child projects, and then, as the last step, add the specific +URL to your aggrcon file. + +When you add the new child to aggrcon file, be sure to leave the old +child or children in place at least for a day or two, maybe much longer, +depending on your project's retention policy. This is important, since +if an aggregation build is "in progress" (or, if a user is installing) +it can go ahead and finish. And then on its next build, will pick up +your new new contribution. This is better than breaking the current +build, and having it start all over again. Similarly, you should not +just "replace" what ever repo you had before, since this can break +anyone currently downloading your files. + +### Format + +In order to provide some level of predictability and reproducibility for +the Simultaneous Release build, we need to enforce some practice to make +sure the dependency resolution is deterministic from a given state of +the aggregation model. Please use any of the following approaches, at +your own convenience. + +#### Simple repo, and specify, exact versions + +The best format to use, in aggrcon file, is to use a URL that points to +a "simple repository" presumably a child of a composite repo, but +strictly speaking, that makes no difference to b3 aggregation process. +Be sure to leave "old repo" around, for a few days in case a build is in +progress, and be sure new repo is in place and "ready" before changing +aggrcon file. That is, aggrcon file should be last step in the process. + +Along with that, your aggrcon file should name exact versions of your +features that you desire to contribute. This looks like the following: + +`versionRange="[4.0.0.201503231230-m1]"` + +Notice the use of square brackets. That means to use exactly that +version. It is a common error for some to use something like +versionRange="4.0.0.201503231230-m1" which means you want to contribute +that version, or higher So, strictly speaking, if there is a higher +version available, either in your repo, or someone else's repo, then +that higher version might be used instead of the one you intend. + +As of this writing, EGit follows this format in their [egit.aggrcon +file](http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/egit.aggrcon). + +#### Composite repo, and exact versions. + +A good format to use, is to use a composite repo, but still use exact +version range as above (with square brackets). + +Why is this one not as good as first option? The reason is simply that +it provides more "automatic self checking" that all is as intended. In +this format, there is some risk you might accidentally update some +features to latest milestone, but accidentally leave some pointing back +to previous milestone. They might all be "resolvable" from a composite +repo, and lead to subtle errors that are hard to track down. + +As of this writing, EMF follows this format in their [emf-emf.aggrcon +file](http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/emf-emf.aggrcon). + +#### Simple repo, no version range + +In this case, the URL would point to a simrel repository, that was +assured to have just one version in it. This often works ok, but is not +as good as the first option, since you are basically saying "any version +will do" so if someone has a higher version in another repo, it might be +pulled instead. Even more extreme, someone may have a lower version, and +-- you did, after all, say any version would be ok -- then that lower +version might be used, if p2 decides that is an optimal solution. (An +optimal solution, to p2, does have some ability to provide a less than +perfect solution, since in some cases it will "stop trying" some +branches of the solution tree, if they happen to be taking a very long +time to compute, and some other branch "works"). + +As of this writing, the Eclipse Platform follows this format in their +[ep.aggrcon +file](http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/ep.aggrcon). + +## Test and Build locally + +From the local state of the aggregation model, there are various ways to +test your change and reproduce the Simultaneous Release (or parts of it) +locally + +### Aggregation (only) from Eclipse IDE and CBI aggregator + +From the aggregation editor, right-click on the aggregation model and +run `Clean then Build Aggregation`. See +[CBI/aggregator/manual#Global_actions](CBI/aggregator/manual#Global_actions "wikilink") + +### Aggregation and reports from CLI with Ant and Eclipse headless + +TODO + +### \`mvn clean verify\`: Aggregation and reports with Maven (Experimental) + +With a version of aggregator post Dec 14th 2017, simply run **mvn clean +verify**. The Maven-based orchestrator takes care of downloading the +necessary CBI aggregator features and of invoking them. + +## Pushing your changes + +~~There are 2 different ways of pushing content to the simrel +repository.~~ + +### Contribute via a Gerrit review (recommended) + +Anyone who has correctly configured Gerrit (as explained in +[Gerrit](Gerrit "wikilink")) can suggest an update in the form of a +Gerrit review. A committer will have to review the suggested change, and +if it conforms to the requirements, the committers can merge the change +from Gerrit. + +In order to suggest a change, a contributor only has to push it to the +repository's master branch, using the following pattern: +`refs/for/master`. After successfully pushing (either with EGit or Git +CLI), the remote Gerrit server reports an URL where to follow the +review. + +When submitting a change to Simrel, [validation will run on Simrel +Jenkins](https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/) +and the Jenkins CI user will vote ++1 if the validation +succeeds and -1 if it +doesn't. Getting a +1 +from automatic validation is a requirement before merging the patch. In +case you have some doubt about the results of this validation step, get +in touch with a Simrel committer to find out what's wrong in your +submission (or in the validation job). + +Currently, no-one is assigned to review and/or merge the suggested +changes, so the contributor *must notify a simrel committer* of the +suggested change. In general, it's recommended to ask the release +engineer for the project you're willing to update. Then the simrel +committer will be able to review and merge the change (by voting a ++2 for code-review +field and then hitting *submit* button) + +### As a SimRel committer, push directly to the target branch (to bypass Gerrit review) + +~~Some contributors are considered as simrel **committers** and are +allowed to push directly to this repo. Each project in the Release Train +generally has a "release engineer" who has the permission to update the +SimRel repo directly. If you plan to do frequent updates, and agree to +do them as suggested about, and need write access to this repository +location, then [open a bugzilla +entry](https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Cross-Project).~~ + +~~Then you can push directly your commit to the master branch on the +remote repo.~~ + +[Juno](Category:Juno "wikilink") [Kepler](Category:Kepler "wikilink") +[Luna](Category:Luna "wikilink") [Mars](Category:Mars "wikilink") +[Neon](Category:Neon "wikilink") [Oxygen](Category:Oxygen "wikilink") +[Photon](Category:Photon "wikilink") \ No newline at end of file diff --git a/wiki/SimRel/Overview.md b/wiki/SimRel/Overview.md new file mode 100644 index 0000000..83e75a0 --- /dev/null +++ b/wiki/SimRel/Overview.md @@ -0,0 +1,90 @@ +Here is a brief overview of how our Simultaneous Release works. + +Individual projects opt to participate in our simultaneous release. i.e. +a subset of Eclipse projects choose to participate. Non-participating +projects just do their own thing. + +Each participating project is responsible for doing their own local +build. They are free to use whatever technology makes sense to them. + +Each project is required to have at least one representative on our +[cross-project mailing +list](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev) +to monitor and participate in simultaneous-release-specific +communication. Communication is pretty key early on to avoid things like +dependency duplication (multiple versions of the same library) and such. +We've had great success with reducing other redundancy with this simple +step. The Web Tools project, for example, used to have its own database +tools; communication lead to them scrapping that development in favour +of adopting the work of the Data Tools project. + +Each project is required to conform to the published release schedule. +The schedule includes a total of three (3) milestone, two (2) RCs, and +one GA. Projects decide on an offset. The +[Eclipse](http://www.eclipse.org/eclipse) project has, for example a +"+0" offset: they provide their bits on the first day of any given +milestone or RC date. A project like [EMF](http://www.eclipse.org/emf) +is "+1" meaning that they provide their bits one day after the milestone +or RC date. This basically indicates that EMF "depends on" Eclipse; they +use the extra time to pull down the milestone/RC bits from their +dependencies and run tests before they contribute their own bits to the +milestone/RC. There are "+2" and "+3" projects as well. i.e. BIRT is +"+2" because it depends on a number of "+1" projects. + +Projects provide their bits as a p2 repository. They also provide some +metadata that describes their contribution (e.g. location of said p2 +repository, contact information of the provider, categorization +information, etc.) + +Projects are required to demonstrate conformance of a collection of +"[must dos](Simultaneous_Release_Requirements.md)" +(things that a project "must do" to participate). + +Projects update the +[simrel.aggr](https://git.eclipse.org/r/plugins/gitiles/simrel/org.eclipse.simrel.build/+/refs/heads/master/simrel.aggr) +and their specific component .aggrcon file from the [simrel git +repo](https://git.eclipse.org/r/admin/repos/simrel/org.eclipse.simrel.build). +These edits can be made with the [build +aggregator](https://wiki.eclipse.org/CBI/aggregator). + +To update a project's contribution short version (see [long version +here](Contributing_to_Simrel_Aggregation_Build)): + +`- install the `[`aggregator`](https://download.eclipse.org/cbi/updates/p2-aggregator/tools/milestone/latest/index.html)` into a recent Eclipse IDE` +`- clone the `[`simrel`` ``git`` ``repo`](https://git.eclipse.org/r/admin/repos/simrel/org.eclipse.simrel.build) +`- open the `[`simrel.aggr`](https://git.eclipse.org/r/plugins/gitiles/simrel/org.eclipse.simrel.build/+/refs/heads/master/simrel.aggr)` file` +`- open the Properties view` +`- find the Contribution for your project and expand it - see `[`this`` ``screenshot`](Simrel_screenshot.png)` for an idea of how this looks` +`- select the Mapped Repository node` +`- in the Properties view, edit the Location field to the new p2 URL and press Enter` +`- select all the features in the contribution, right-click and choose Fix Versions` +`- commit and upload to gerrit` + +We have a [build aggregator](https://wiki.eclipse.org/CBI/aggregator) that runs when +changes to contributions are detected. It picks up all the bits and +produces an über repository of everything that's currently available. So +on offset "+2", the über repository should contain all the bits from all +the projects that declared as "+1" (so the repository can be used by the +"+2" projects to test). During aggregation, dependency problems may be +discovered. If dependencies cannot be resolved, the offending project +bits are excluded and an email is sent to the cross-project list for +mitigation. While building up to a milestone or release, the aggregated +repository is moved to a ["staging" +repository](http://download.eclipse.org/staging/) for early testing by +committers, and once final, the staging area is moved to a ["releases" +repository](http://download.eclipse.org/releases/). To know when things +are "final", we do not have an "affirmation" check-off, but depend +simply on the planned date, and then rely on the projects to notify us +on cross-project list if they are late, need a little more time, or need +a re-build for some serious problem after their agreed offset. + +On "+4" the [EPP](http://www.eclipse.org/epp/) build meister runs the +build for "all in one" distributions, and pushes the result to [a public +location](http://www.eclipse.org/downloads/). Typically, those files are +allowed to mirror for approximately 24 hours before being made "visible" +to the general public, so that once the general public start downloading +them, not all downloads have to go through one single network. + +The release train end-game is carefully coordinated as the final release +date approaches. This end-game is outlined in the [Release +Checklist](Release_Checklist) document. diff --git a/wiki/SimRel/Release_Checklist.md b/wiki/SimRel/Release_Checklist.md new file mode 100644 index 0000000..500ac08 --- /dev/null +++ b/wiki/SimRel/Release_Checklist.md @@ -0,0 +1,197 @@ +This is a chronological list of things to do before, on and after a +release day. + +# Before release day + + + + + + + + + + + + + + + + + + + + + + + + + + +

Task

Description

Responsibility

Add info center

SimRel release engineer

Check mirrors

SimRel release engineer

Fix historical reports on SimRel JIPP main page

SimRel release engineer

+ +# On release day + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Task

Description

Responsibility

Update "latest" composite repository (15min before +release)

SimRel release engineer

Create P2 composite repository for next release

SimRel release engineer

Update SimRel wiki pages

SimRel release engineer

Send announcement email to cross-project-issues-dev mailing +list

SimRel release engineer

Update various eclipse.org websites

Webdev team

Upgrade community documentation

Upgrade https://wiki.eclipse.org/FAQ_How_do_I_upgrade_Eclipse_IDE%3F

Developers Community

Announce to user community

Marketing team / Developers Community

+ +# After release day + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Task

Description

Responsibility

Tag simrel aggregator repo

SimRel release engineer

Update build configuration

    +
  • Update TRAIN_NAME in Jenkinsfile
    • +
  • Update trainName, referenceRepo, eclipse.repo.url in pom.xml
    • +
  • Update release name label in simrel.aggr (see an +example)
    • +
+

=> Use update_build_configuration.sh +script (execute on local machine for now)

SimRel release engineer

Re-enable aggregator job

SimRel release engineer

Remove milestones and release candidate repos

SimRel release engineer

Move old release repos to archive.eclipse.org

    +
  • Only keep the last 8 releases on download.eclipse.org
    • +

SimRel release engineer

diff --git a/wiki/SimRel/Simrel_screenshot.png b/wiki/SimRel/Simrel_screenshot.png new file mode 100644 index 0000000..14a5859 Binary files /dev/null and b/wiki/SimRel/Simrel_screenshot.png differ diff --git a/wiki/SimRel/Simultaneous_Release_Cycle_FAQ.md b/wiki/SimRel/Simultaneous_Release_Cycle_FAQ.md new file mode 100644 index 0000000..4daeced --- /dev/null +++ b/wiki/SimRel/Simultaneous_Release_Cycle_FAQ.md @@ -0,0 +1,843 @@ +This page is to document answers to frequently asked questions about +Simultaneous Release cycle, process or build. + +# What is the Simultaneous Release cycle ? + +The releases will occur every 13 weeks. It will follow the planning +below: + +- **M1 Friday Week 3** : Milestone 1 + - all the projects are expected to contribute their latest working + version for a 1st alignment + - Staging repo is built \[1\] + - EPP packages are released for tests \[2\] +- **M2 Friday Week 6**: Milestone 2 + - API breakages are in + - all the projects are expected to contribute their latest working + version for a 2nd alignment + - Staging repo is built \[1\] + - EPP packages are released for tests \[2\] +- **M3 Friday Week 9** : Milestone 3 + - all the projects are expected to contribute their latest working + version for a 3rd alignment + - Staging repo is built \[1\] + - EPP packages are released for tests \[2\] +- **RC1 Friday Week 10** : + - API & Feature freeze + - Staging repo is built \[1\] + - EPP packages are released for tests \[2\] +- **RC2 Friday Week 11** : + - Only fixes. It is assumed all code is done by the end of RC2 + - Staging repo is built \[1\] + - EPP packages are released for tests \[2\] +- **Quiet Week 12**: + - If all goes well, no changes will occur this week + - If a blocker is found, this week allows for a final respin. +- **GA Wednesday Week 13** : + - is updated + with the latest EPP packages + - is updated to + point to the new release’s update site. + +\[1\] + +\[2\] + +The releases will occur near the middle of June, September, December and +March each year. + +# Why was the release cycle changed ? + +There were different motivations to update the release cadence from one +year to every 13 weeks. The main ones are: + +- Ease the update from one release to another for the end user +- Let developers provide new features faster to their users +- Simplify the maintenance by keeping only one stream for contributors + +# What are the streams to work on ? + +There is only one master stream, it will be updated continuously. This +means that there will be no more service releases after Photon. + +# As my project is part of the release train do I have to follow the exact cycle ? + +Individual projects may have their own cycle releases at any time if +they need to, but all participants in the Simultaneous Release, are +expected to participate fully in the Simultaneous Release. Projects are +expected to contribute a working version to each cycle, even if it is +the same as the previous one. What new features are added or what bugs +are fixed is up to each project to decide, but each project must, at +least, continue to "fit in"; build, install and avoid conflicts. + +Projects are free to have their own schedules as long as they meet the +deliverables & deadlines. + +# When can I add, update and remove API ? + +It is possible to add, update and remove API on any release. API breaks +should be contributed no later than M3 and API & feature freeze must +occur at RC1. Each project is responsible for its own API deprecation +policy. + +# My project is part of the Simultaneous Release but is quite stable. Do I have to provide new features for each release ? + +No, you just need to provide the same version as the previous one but +ensure that it continues to “fit in”, your build is ok, and it works +fine. + +For example, should API be added to a project on which you depend, you +must commit to updating your project so it can continue to be compiled, +run, and installed along with the updated dependencies. For example, if +Platform’s IJavaProject adds API to an abstract class, your +implementation in webtools.jsf must also add those new methods. + +# Where can I find the latest working (staging) version ? + +The latest working version is available on + where xxx = 2018-12, 2018-09, +photon, oxygen, neon... + +# Where can I find the latest stable release ? + +One repository will be used, which will be continuously updated after +each release: + +This will be a moving target pointing to the latest stable release at +any time. + +# Where could I find previous stable release ? + +All the stable releases will be also kept available on specific URLs +according to the following pattern: + where xxx = 2018-12, +2018-09, photon, oxygen, neon... + +# What is the naming pattern for the releases ? + +The releases will be named following the pattern year.month: **Eclipse +IDE YYYY-MM**. + +For instance *Eclipse IDE 2018-09*, *Eclipse IDE 2018-12*, *Eclipse IDE +2019-03*, *Eclipse IDE 2019-06*… + +Note that unlike past years, the name will no longer change annually +with an alphabetically increasing name (Kepler, Luna, Mars, Neon, +Oxygen, Photon) but will instead remain the singular name of the train. + +# What is the schedule for the next releases ? + +After the release of Photon in June 2018, we have switched to the new +release cadence. Releases are quarterly, or about every 13 weeks. + +The exact dates are listed in the Simultaneous Release Plan documents, +e.g. +[SimRel/2019-09/Simultaneous_Release_Plan](SimRel/2019-09/Simultaneous_Release_Plan "wikilink"). + +You can find the planning documents in the release overview here: +[Simultaneous_Release](../Simultaneous_Release.md) (look for the +"wiki" or "plan" links in the rightmost column). + +# How do we join the simultaneous release train + +Pretty much any project that wants to join the release train can and are +encouraged to. Of course, it does sometimes take more work ... it is not +just a matter of timing. But, often makes things much easier for your +adopters and users. You should discuss with your mentors and PMC if you +have any doubts or to make sure they agree its appropriate for your +project. + +For "how to join", see [Simultaneous Release +Requirements](Simultaneous_Release_Requirements#State_intent_early_.28M4.29) +document. + +## How to decide if offset is +N category + +It depends on who you depend on and who depends on you. The Eclipse +Platform is +0, so nearly everyone else is +1, +2, or +3. For example, +if you highly depended on "webtools" (which is +2) then you'd have to be +a +3. + +If no one else depends on you, in release train, then +3 would be a good +choice. Everyone else is somewhere in between. + +Of course, the lines are not always clear and pure ... such as part of +emf is required at +0 but part of it is later at +1. In such cases, +projects usually mark themselves as +1 and "work out the details", +project-to-project, with those that need things at +0. Another example, +part of a project such as WTP might depend on part of DTP and DTP might +depend on part of WTP, but both need to be +2 to "fit in". In cases +such, the projects might have to work out plans or agreements about +having the sensitive, overlapping parts to be stable and finished early +(in both API and version numbers) so neither has to build against the +literal final delivery of the other. + +Keep in mind, the +N category means the **last** possible time to drop +(without notifying others). You are welcome and encouraged to have a +"warm-up drop" a week or so earlier, with your "near final" bits, just +to see if anything breaks or effects others, even though your final +delivery may not be until +N. + +# When can projects join the release train ? + +The period to join the simultaneous release is at the beginning of any +cycle, four times a year. The project needs to declare its intention to +join before the +0 (Friday) of the M1 release week. The "statement of +intent" is still exactly the same as today: projects must formally +announce their participation on the cross-projects-issues-dev mailing +list. + +Once a year, EMO will take care of organizing the “opt-in” process as it +is today, so that all projects already in the train can declare their +intention to continue. Those not opting to continue will be removed, but +can be re-added should their intention change. + +# When can projects leave the release train ? + +A project can declare its intention to leave at any moment in the cycle. +If it does, it should inform depending projects in advance, so they can +adjust accordingly. + +# What are the most important URLs + +- [SimRel](SimRel "wikilink"), the wiki category page for the current + Simultaneous Release stream. + + + +- [Repository Aggregation, status and control on SimRel Jenkins + instance](https://ci.eclipse.org/simrel/) + +# Where can the common repository be tested, before it is rolled out for a milestone or release? + +The best place is the "staging area", by adding + to your "available +software sites" list, e.g. + +[`http://download.eclipse.org/staging/2019-03`](http://download.eclipse.org/staging/2019-03) + +Note: to get the best test, disable all other repositories in your list, +or you might end up pulling something from some other repository, not +staging. Be aware that moving a specific build to "staging" may happen +only every few days (if you need something promoted more urgently, just +ask on cross-project list). + +# What is the staging repository? + +Conceptually, it is simply a place to hold a repository temporarily ... +until the repository is promoted to a released location. + +## What is staging, for the current, most forward looking, yet-to-be-released stream? + +` http://download.eclipse.org/staging/` + +For example: + +[`http://download.eclipse.org/staging/2019-03`](http://download.eclipse.org/staging/2019-03) + +Before the actual release, a common milestone aggregation build is moved +from 'staging' to the 'releases' area. For example, once, for each final +milestone, staging is moved to + +[`http://download.eclipse.org/releases/`](http://download.eclipse.org/releases/)`/` + +## What's the best way to test with the staging repository? + +There are a couple of good tests to do, before a staging repository is +released: + +### Test staging all by itself + +Just add the staging repository to the available software sites, using +preferences, and ... very important ... make sure all other sites are +disabled. This then gives you the best view that everything in that one +repository is correct, and all dependencies can indeed be found, and +things show up in categories as expected. + +After confirming the categories are as expected, usually the next test +is just to install things, fresh, but often it is a good idea to test +various update sceneries, to make sure things work as expected (for +example, if you already have M1 installed, then once M2 is ready, test +to be sure it updates to M2 as expected. + +### Test staging as a pseudo composite + +After confirming staging repository is correct, its often useful to then +also (re)enable the released repository. Then, on install dialog, you +can select "all available sites" and this effectively simulates what the +eventual, final composite repository will look like to end users. There +are cases, especially during initial development, where invalid features +will show up. For example, if a feature was removed, renamed, its +version reduced, or its category changed from one milestone to the next, +it might still show up in the composite, and that might interfere with +correct installation (see ), if not merely be confusing to end users. If +there is a serious problem due to the composite, please open a bug in +cross-project component and we'll decide if the composite should be +changed or reduced to allow for correct installation. + +### Test EPP Package updates + +For a release, EPP packages are added to the common repository via +composite, so its exact (final) location is transparent to end-users. + +But before a release, similar to above, you can use a pseudo composite +to test if an EPP Package updates as expected. You'd need to follow (or +ask on) the epp-dev list to know details, but in addition to the above +staging repo, you would add (and enable) EPP's staging repo, which would +usually have a form similar to the following: + +` `[`http://download.eclipse.org/technology/epp/packages/`](http://download.eclipse.org/technology/epp/packages/) + +### Why do we use composites anyway, if there are potential problems with them? + +Three reasons: + +First, we use composites in order to be able to test early to make sure +there are no bugs in p2, etc., that need to be fixed. + +Secondly, someone may be using a previous milestone as a runtime target, +and once we remove it, it will invalidate that target, so we do not want +to force everyone to "move up" all at the the same time. Some developers +may need a few weeks to transition to the latest code. To save space, we +do not try and save all previous milestones, though. Our goal is to +maintain about 3 milestones in the composite. For example, if we had M1, +M2, and M3 in the composite, once RC1 came out, we'd only have M2, M3, +and RC1. But the number can not be guaranteed. If there are serious +problem with providing the composite we will reduce it to just two, or +even to just one, to make sure the repository is usable for testing and +continued development. + +Finally, to allow users to rollback an install. If you updated e.g. from +M1 to M2 and noticed that something's broken, you can revert to M1 +automatically (Via Installed Software -\> Installation History). +However, this feature only works if M1 is still available at the same +location, i.e. in the composite update site you used to update to M2 (Or +to initially install M1) [more +info](https://www.eclipse.org/lists/cross-project-issues-dev/msg17257.html). + +# Once I update my *.aggrcon* file, how can I start a build? + +You don't need to. The Gerrit validation job will start automatically, +once you submit a Gerrit review with your change. If the validation job +is successful, you can merge the change. The aggregation job polls the +Git repo every 10 minutes to see if there are any changes, and if so, +starts a build. It takes approximately 1 hour to run. + +## But what if I really want to kick off the build myself? + +If you can't wait 10 minutes, you can start the build yourself. Anyone +that has authorization to check in a build file, should have authority +to manually start a aggregation build. + +Plus, there are some cases where someone may need to kick off a build +manually. For example, if a build fails due to network issues. Another +common case is that a build may fail, even though the contribution file +is correct, the repository it points to might have had an error. Once +the repository is corrected, there's no automatic mechanism to detect +that change, so after the repository is corrected, a new build has to be +manually started (that, or the contribution file is "touched" and then +checked in again). To manually start a build, just click the "Schedule a +Build" button at the [simrel.runaggregator.pipeline job +page](https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/). +You need to be logged in for this. + +# A build failed message says it can not find xyz.feature.group, but I have nothing with "feature.group" in the name? + +The suffix ".feature.group" is added to feature names, to refer to the +whole feature ... the feature files themselves, but also all its +included bundles and features ... to help distinguish it from the +literal feature files. So "xyz.feature.group" just means the "xyz +feature", conceptually. See [Eclipse Help for detailed information about +metadata](http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_p2_featuremetadata.htm). + +# A build failed message says it can not find version 1.2.3.v9 but I can see 1.2.3.v9 on the file system? + +The key file, the one that "drives" P2, is the content.jar/xml file. Be +sure to check the version numbers there. If, inside it, the installable +unit (often a feature) says version="1.2.3.v8", then P2 will look no +further and conclude that the 'v9' feature it is looking for is not +there. This is usually a sign your meta data needs to be re-generated to +match the contents on the file system. + +# How is a final build made "invisible" until release? + +## Web download pages? + +You can put the zips in their download directory, so those large items +can replicate to mirrors, but don't use any HTML that would cause them +to be displayed as links to an end user. True, if someone knew the exact +URL they could still get it, but the idea is that the URL is not widely +announced or visible, so even if a few download it, it is not hit by +thousands of downloads. Then, on release day, you'd update the HTML +pages to make the downloads visible to browsers and click-able by users. + +Tip : you can hide some particular builds from download pages using the +hidden.txt file in downloads directory ( see for example emft : + +) + +## P2 repositories? + +There is a few ways to accomplish this, depending on if you have +composite or simple repositories, but they all involve promoting the +"main" parts of the repository (the artifacts, usually "plugins" and +"features" directory) to their final location so those meaty parts can +be replicating to mirrors, but do not put the metadata (usually +content.jar and artifacts.jar) to their final location until "release +day". p2 doesn't "see" the artifacts, until it can read the metadata. + +# I see that xyz is being pulled into the repository, how can I see who is pulling it in? + +There are times when someone may see an old, or inappropriate, bundle +being "pulled in" to the aggregation build, and they want to find out +how or why it is being included. While the full rules for how p2 decides +something is required, or satisfies a requirement, is beyond the scope +of this FAQ, there are two ways to get started narrowing it down. Just +to have a concrete example, I will use the use-case provided by to show +a specific case, where some old (unsigned) version of +org.eclipse.emf.teneo.hibernate.libraries was being included. + +## The quick approximate check of where its coming from + +Check the console log for a message about mirroring the problematic +bundle, and then look back "up" in the log, to see what repository is +being processed at that point. + +For, our example, searching for +'org.eclipse.emf.teneo.hibernate.libraries' we find the following line: + +`    [exec] - mirroring artifact osgi.bundle,org.eclipse.emf.teneo.hibernate.libraries,1.0.1.v200907090915 ` + +Then, looking back "up" in the log, we see the following repositories +were being used to pull things from: + +`    [exec] Mirroring meta-data from from `[`file:///home/data/httpd/download.eclipse.org/modeling/emf/updates/interim`](file:///home/data/httpd/download.eclipse.org/modeling/emf/updates/interim) +`    [exec] - mirroring meta-data reference `[`http://download.eclipse.org/modeling/mdt/updates/`](http://download.eclipse.org/modeling/mdt/updates/) +`    [exec] - mirroring artifacts reference `[`http://download.eclipse.org/modeling/mdt/updates/`](http://download.eclipse.org/modeling/mdt/updates/) +`    [exec] - mirroring meta-data reference `[`http://download.eclipse.org/modeling/emf/updates/`](http://download.eclipse.org/modeling/emf/updates/) +`    [exec] - mirroring artifacts reference `[`http://download.eclipse.org/modeling/emf/updates/`](http://download.eclipse.org/modeling/emf/updates/) +`    [exec] - mirroring meta-data reference `[`http://download.eclipse.org/modeling/emft/updates/`](http://download.eclipse.org/modeling/emft/updates/) +`    [exec] - mirroring artifacts reference `[`http://download.eclipse.org/modeling/emft/updates/`](http://download.eclipse.org/modeling/emft/updates/) +`    [exec] Mirroring artifacts from from `[`file:///home/data/httpd/download.eclipse.org/modeling/emf/updates/interim`](file:///home/data/httpd/download.eclipse.org/modeling/emf/updates/interim) + +In some cases, this might be sufficient to track down the problematic +contributor. + +## The detailed, exact check on requirements + +If the log doesn't help, the definitive source of "requirements" can be +seen in the content.jar/xml. It can be tricky to "find" the +content.jar/xml file, depending on composites repositories, if +compressed or not, etc., but for our example, from a temporary +maintenance repository, you can download it from + +` `[`http://download.eclipse.org/releases/maintenance/content.jar`](http://download.eclipse.org/releases/maintenance/content.jar) + +Once unzipped, you can search for your bundle, in our case. searching +for 'org.eclipse.emf.teneo.hibernate.libraries'. + +You'll certainly find the IU that defines the bundle + +` ` + +That IU, by itself, doesn't help narrow down who is requiring it. But, +continue to search. + +### The easy case of "Require-Bundle" + +If you find a match in a "requires" element, you can see what bundle +"requires" your bundle. If found, those matches would start with +"\ + +- Is the bug something that prevents other projects from working + correctly? + + + +- Is the bug something that causes install, or update, to fail, or + otherwise leave an installation in a bad, unfixable state? + + + +- Is the bug something that can not be solved by a patch feature, + applied by users or adopters after the release? + + + +- Is the bug a regression, from previous release? + + + +- Do other projects have to recompile, once a bug is fixed? For + example, are constants changed? APIs? version numbers? + + + +- Do other projects need to retest, once a bug is fixed? That is, is + it something that could potentially effect others ... such as a + change in timing or synchronization of some "notification" to + listeners? Or something clearly "internal" to your own code? + + + +- Do you have the support, approval, or review of your Project Lead + and PMC? (Or, otherwise follow what ever your project's rampdown + process is?) + + + +- Does it affect an EPP Package? Or just the common repository? + +## Past our +n day, but before window closes? + +If we are still within the "drop window" for a deadline, but you are +past your particular +n day, simply post a note to cross-project list, +with any relevant questions and answers from above list, the bug number, +and then just do it. (No need for further approval or coordination.) + +Keep in mind that spinning new builds past your deadline can result in a +lot of work for downstream projects and consumers as they make last +minute adjustment to your change. Projects are generally willing to +accommodate these changes as much as they can, but please keep this in +mind and only do it when absolutely necessary. + +## Past the drop window? + +In this case, it is completely past the drop window, after EPP packages +have been built. In this case, you still need to post to cross-project +list, with bug number, and relevant questions and answers from above +list, but now explicit review/permission from Planning Council is also +required. Please follow the [Planning Council Exception +Process](http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php#pcExceptionProcess), +but in cases of "tight timing", the Planning Council has authorized the +Planning Council Chair (currently Mélanie Bats) to make the initial +decision and allow others to review later or in parallel. + +# Common errors and what to do about them + +There are some errors that occur during aggregation builds that are +pretty common and asked about frequently so will list some here in this +FAQ. Please add others, if you notice any missing, and/or improve the +answers if any of these are incomplete or not helpful enough. + +## Aggregation model is inconsistent + +The title is typically how the error message always begins, and then has +several lines of hard to read notations, which are probably easy to read +if you know EMF real well. :) There are two common reasons for this +error, both are related to the fact that in some cases, the \*.aggrcon +file and the simrel.aggr file must \*both\* be updated. + +An interesting twist of this problem is that when it occurs there is no +"blame mail" sent out. The reasoning is that "since the model is bad it +is hard to trust the email data from the model". Another good reason to +use Gerrit, since then you know (pretty much) the error is yours, if +this error occurs after your contribution. Otherwise, the overall +Simultaneous Release Engineer must figure out the offending party -- +which is pretty easy to do if they use the CBI Aggregator Editor. + +**Solution:** + + + +If the hard-to-read notations mention something about "missing proxy" +then it is likely a "contact email" (or a feature id) was added to the +projects aggrcon file, but was not added to the simrel.aggr file. It is +easiest to use the CBI Aggregation editor (on the simrel.aggr file) to +add/remove the feature or the contact and also add to a contribution or +category. + + + + + +If the hard-to-read notations mention something about custom categories +and features that "do not refer to each other" then similar to the +above, someone tried to add a feature to a category, but changed only +their aggrcon file and not the simrel.aggr file. The solution is the +same, use the Editor! + +In both cases above, after the change is made, but the simrel.aggr file +and the project's aggrcon file should show "changed" and both should be +committed together. + +## Invalid pack.gz file + +The actual error message is not nearly so clear as the title of this +section, but more often says something like the following (from ) + + +org.eclipse.core.runtime.CoreException: Unable to unpack artifact +osgi.bundle,org.apache.hadoop.zookeeper,3.3.3.v201105210832 in +repository +: +Invalid + + + + +Caused by: org.eclipse.osgi.signedcontent.InvalidContentException: The +file "org/apache/zookeeper/server/upgrade/UpgradeMain.class" in the jar +"/home/hudson/genie.simrel/.hudson/jobs/simrel.neon.runaggregator.BUILD__CLEAN/workspace/tmp/signatureFile6913692817837489877.jar" +has been tampered! + +The problem is that the "pack.gz" file is invalid. For this example the +bundle is probably something like "org.apache.zookeeper.server", but +technically the error only mentions the package name, and the "temp +location" of the jar file. + +An interesting twist to this problem is that p2 itself will not complain +if someone is simply "installing" the bundle, since if an error occurs +with the "pack.gz" version of a bundle, p2 automatically falls back and +uses the "jar" version of a bundle. The reason that it is considered a +blocking error during aggregation is that most large repositories should +be "perfectly correct". It is no big deal if one out of several thousand +was wrong, but imagine if 25% of those thousands were "invalid pack.gz +files". The end-user will end up wasting a lot of time doing updates, +and the infrastructure bandwidth would be increased for no good reason. + +**Solution:** + +There are 2 or 3 or 4 possible solutions. + + + +The jar may may be being "re-signed" during the project's build. +Re-signing actually does work sometimes but seldom when "pack.gz" is +involved. Hence, one solution is for the project to stop re-signing the +bundle (which is difficult for some build system, but which is now +automatic for most cases at Eclipse.org). + + + + + +Pack200 (that produces the pack.gz file) does not work for each and +every possible piece of Java byte codes. It should, but it doesn't. So a +few solutions here: + + + + + +The best (or easiest) is for the project to specify at build-time not to +use pack200 with that particular bundle. + + + + + +Even better (but very difficult, and only worth if it is a very large +bundle), is that pack200 has options to specify to do the "packing" +slightly differently. For this example, as one use of the options, it +might work to tell pack200 not to pack the +"org/apache/zookeeper/server/upgrade/UpgradeMain.class". (BTW, I do not +even know if that is possible with Tycho. :) + + + + + +Another "quick fix" solution is to run a post build step to remove that +specific pack.gz file from the project's repository. This is not as +simple as deleting the pack.gz file, since it is specified in the +metadata files as "being available" but there are some simple p2 ant +tasks that can be used to remove it correctly (as an example, see the +[example mentioned in bug +492904](https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/miscToolsAndNotes/p2RemoveIU/p2RemoveIU.xml). + +## Unable to load repository + +The title is typically how the error message always begins and then the +error message names the repository. This is a frustrating error since +sometimes a contribution will make it through "validation" perhaps even +a "cached build" and then the "clean build" job will fail. This is +because, it most cases, someone really did remove the repository +specified in their aggrcon file before they updated their aggrcon file +(or, perhaps they removed it, thinking they would quickly replace it +with another repo at the same URL). + +**Solution:** + +Typically, you just need to start over and trigger the validation job +and let things run its course. It it happens twice in a row, best to +open a bug or contact the offending party since they may not know the +effect they are having or may not have a very good procedure for +creating and updating their repositories. Projects are supposed to leave +any old repositories around at least long enough for they themselves to +get a good aggregation build before removing the old one. There are ways +of doing this! And, yes, it usually does involve creating a new +repository **and then** updating your aggrcon file. + +## Cannot complete the install because one or more required items could not be found + +The title is typically how the error message always begins and then the +error message gets pretty cryptic. But, hidden in the cryptic part it +will be specific about what could not be found and what it is that +requires it. + +**Solution:** + +The solution typically involves several projects sorting out what +changed versions and how others should specify their requirements. A +typical "integration time" problem that is typically easy to solve once +the right projects sort it out. + +I partially wanted to mention this problem, because very occasionally +someone will say, "but I can see bungle xyz with version l.m.n on the +file system, why can't the aggregator find it". There reason is that it +does not matter (too much) what is on the file system, what matters is +what is in the content metadata or artifacts metadata. It is pretty rare +these days, but occasionally something goes wrong and the content +metadata says the repository has version "1.0.0" so it does not matter +that version "2.0.0" is on the file system, the "contract" on the meta +data is only for "1.0.0". This is typically a build or mirroring problem +and the project that owns that repository must fix it. + +## Cannot complete the install because of a conflicting dependency + +As above, the title is typically how the error message begins and then +the error message gets pretty cryptic. And, again, hidden in the cryptic +part it will be the specifics about what is conflicting. It is likely +harder to read, though, just because it is longer and involves several +threads of dependencies. These errors typically all boil down a +"singleton" being required, and the installer (p2) knows that multiple +versions can not be satisfied at runtime. + +**Solution:** + +The solution typically involves several projects sorting out what +changed versions and how others should specify their requirements. In +other words, a fairly typical "integration time" problem that is +typically easy to solve once the right projects sort it out. One +caution, though. Occasionally this is solved by someone specifying +"extra wide" dependency ranges so that it is closer to "any version of +that singleton is required". This is often not ideal if one project +provides one version from their own repository but then "picks up" +another version from someone else's repository during the aggregation +run (or, when a user installs from the Sim. Release repository). It is +better, usually, if all "solutions" match, no matter where a feature or +project is installed from. + +## A bundle comes from a different repository than what a project contributes + +There is no consistent error message for this case. In fact, it is +normal and "working as designed" that bundles can come from other +repositories. Or, even, a more extreme case, "imported packages" can +come from other bundles than what one contribution may have been +expecting. The fundamental reason is that p2 (via the CBI aggregator) +solves "all the constraints" pulling from "all the repositories" as +though, conceptually, they were all one large request to "install +everything" so anything -- from any repository -- is "fair game" if it +meets the constraints. As said, most of the time this is normal and p2 +(and the CBI aggregator) are working as designed. This is mentioned in +this "trouble shooting" section, though, because occasionally it will +cause an error of some sort and it is usually difficult to understand +why a different bundle or package was installed. The error might be +anything from the wrong version of the platform (or other Eclipse +project) being pulled in to functional error from having the wrong +version of a third-party package being pulled in. + +**Solution:** + +The exact solution will depend on the exact error, but in general the +solution takes two paths: one, for the producers of repositories, is to +make sure the repositories used in the aggrcon files point to a specific +set of bundles, intended only for the project contributing them, and +only for the release that is being created -- if projects have "overlap" +in including, say, parts of another Eclipse project, those contributing +must coordinate well so they each have the same versions in their +repositories; the second path is that the 'consumer' of the bundle or +package must specify their 'version range constraints' as narrow as +possible and still be appropriately wide. Most solutions will be fairly +straightforward, once it is remembered that when a contribution is +"pulled" for the Sim. Release repository, all the repositories from all +the other contributions are considered "fair game" from which to satisfy +the requirements of the contribution -- it is not only limited to that +one repository mentioned in the aggrcon. Obviously, if every project +contributed only bundles (and packages) from their own project's +namespace, then the problems mentioned in this bullet item would not +occur. Sometimes though, and for good reasons, several projects have the +same, or similar, packages in each of their repositories -- third party +packages being the most obvious case, but sometimes it makes sense for a +project (let's say, the Platform) to include in their repository some +core dependencies they have on other Eclipse projects (such as EMF and +ECF). + +# Additional Information + +- [SimRel/Simultaneous_Release_Policy_FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink") +- [CBI/p2repoAnalyzers/Repo_Reports](CBI/p2repoAnalyzers/Repo_Reports "wikilink") + +[Category:Coordinated](Category:Coordinated "wikilink") \ No newline at end of file diff --git a/wiki/SimRel/Simultaneous_Release_Plan.md b/wiki/SimRel/Simultaneous_Release_Plan.md new file mode 100644 index 0000000..6712241 --- /dev/null +++ b/wiki/SimRel/Simultaneous_Release_Plan.md @@ -0,0 +1,181 @@ +This document contains the boiler-plate information for every +[Simultaneous Release](../Simultaneous_Release.md) after Photon. + +### Requirements For Participation + +Projects that are part of the [Simultaneous +Release](../Simultaneous_Release.md) agree to abide by the +[requirements of the Eclipse Simultaneous +Release](SimRel/Simultaneous_Release_Requirements "wikilink"). + +### Milestones and Release Candidates + +The milestone dates are at roughly 2-3-week intervals. Any end-of-cycle +release candidate (RC) dates are typically one week apart. Each project +has their deliveries due at times offset from the end-date so that the +project dependencies can come together in a reasonable order. These +delivery times are based on the dependencies between projects. They are +labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and "+4" +coming last (only EPP packages). Projects themselves decide if they are ++0, +1, +2, or +3. The actual time-offset represented by these intervals +is mostly one day. The actual calendar can be seen on each release's +dedicated wiki (e.g. +[:Category:SimRel-2019-09](:Category:SimRel-2019-09 "wikilink")). +Projects are free to have their own schedules as long as they meet the +deliverables for the corresponding release cycle. + +Note that projects choose their own +n category based on major or +primary dependencies. There are many cases where a project might have to +deliver pieces of their code a little earlier, if some project depends +on it, or a little later if they have a stray dependency. These sorts of +deviations are left to the projects to work out, pair-wise, among +themselves. Feel free to bring up complicated cases for discussion. + +Given all these constraints, the exact dates for any particular release +cycle are pretty predictable. See the actual calendar for the important +details. That is, your stuff is due earlier than these table dates! +Projects need to deliver a week or two before these "end dates", +depending on their chosen, committed offset category (+0, +1, etc). +Also, to emphasize, the dates represent the last possible date to +contribute ... projects are encourage to provide "warm-up" builds a week +or two earlier, when possible, as this often helps expose issues that +other teams need discussion or that other teams need to react to, before +their final delivery. + +After RC2 is quiet period. There will be no further builds. That time is +reserved for final, in depth testing, and preparation for release. +Emergency rebuilds might be considered, by following the usual [Planning +Council Exception +Process](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements/Appendix#Planning_Council_Exception_Process), +but only for serious, blocking regressions that have a "cross-project" +impact. + +### Communication Channels + +#### Cross-Project Milestone & RC Status Reporting + +Only negative status needs to be reported. It is essential for many +aspect of the simultaneous release that communication be prompt and +clear, on many topics. One of the most important ones, is if someone is +not meeting some date or delivery. Put another way, we assume everyone +is on target and has delivered their stuff unless a note is sent to +cross-project list that you are delayed. Its better to be up front about +it, so everyone knows what to expect, rather than to hope things turn +out OK at the very last minute, since if you "miss" without saying +anything you are more likely to impact other people, and miss your +chance to be part of the release. + +#### Mailing Lists and Newsgroups + +Eclipse projects have three communication channels: a mailing list for +developers, a newsgroup for users, and Bugzilla. While each release is +not a "project" per se, it will use the same structure: + +##### Developer mailing list + +- [cross-projects-issues-dev](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev) - + mailing list for developers and releng (see + [archives](http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/threads.html)). + This is the list to use to discuss build issues, announce changes in + plans, slippage in deliverables, etc. + +##### Bugzilla + +If there is any doubt about where a bug belongs, it can always start in +the "Cross-Project" component. (Under Eclipse Foundation \> Community). +If it turns out to be a single project's responsibility, it can be moved +to that project. If it is a true cross-project bug, where several +projects need to act, then it can stay in the cross-project component. + +- [Search](https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse+Foundation&product=Community&component=Cross-Project&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=) + in Eclipse Foundation \> Community \> Cross-Project +- Open a new + [Cross-Project](https://bugs.eclipse.org/bugs/enter_bug.cgi?assigned_to=cross-project.inbox%40eclipse.org&product=Community&component=Cross-Project) + bug + +##### The Planning Council Mailing List + +Because there has been confusion in the past, we'll be explicit here +that the [planning council mailing list +(eclipse.org-planning-council)](https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council) +is for Planning Council business, not the release activities per se. +While they sometimes overlap, there is no need to cross post. While +anyone can request a subscription to the planning council list (for +openness and transparency) the expectation is that only Planning Council +members post to it. + +##### Conference Calls + +The [Planning Council](Planning_Council "wikilink") has regularly +scheduled calls for Planning Council business. See [conference +calls](Planning_Council#Call_and_Meeting_Schedule "wikilink"). + +There are no planned calls for each release, or for larger audiences, +but they can be arranged if required or desired (for example, if needed +for build coordination). + +### Builds and P2 repository + +#### Builds (Aggregation) + +This section, about assembling the repositories, is subject to change, +as improvements in the process are made. + +A number of utilities have been written to automate the assembly of the +different simultaneous releases. These are available in their own SCM +repository. If interested in this history, you can find more information +about the history and organization by looking at some of the old, +previous information on the [Contributing to Helios +Build](Helios/Contributing_to_Helios_Build "wikilink"), [Galileo +Build](Galileo/Build "wikilink"), [Ganymede +Build](Ganymede/Build "wikilink") and [Europa +Build](Europa/Build "wikilink") pages). + +Since 11/2016 we are using the [CBI +Aggregator](CBI/aggregator/manual "wikilink"). + +The [Contributing to Simultaneous +Build](Simrel/Contributing_to_Simrel_Aggregation_Build "wikilink") page +is where you go to learn how to add your project to the SimRel build +(aggregation). + +#### p2 Repository + +To obtain the latest published bits, use this URL: + +[`http://download.eclipse.org/releases/`](http://download.eclipse.org/releases/)` (e.g. 2019-06)` + +It contains the latest milestone, release candidate, eventually the +release itself. + +To obtain the latest working version, as we build up to a milestone or +release, you can test the staging repository: + +[`http://download.eclipse.org/staging/`](http://download.eclipse.org/staging/)` (e.g. 2019-06)` + +### Update Releases + +After Photon.0, the simultaneous release cadence moved from a one-year +release cycle to a 13-weeks cycle. The releases will occur at the end of +September, December, March and June each year. Instead of a one year +long ramp-up to a release, there will be rolling releases. + +See also: [Simultaneous Release Cycle +FAQ](https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ) + +#### Other considerations and rules + +Individual projects may have their own update releases at any time if +they need to, but all participants in the Simultaneous Release, are +expected to participate fully in each release. What new features are +added or what bugs are fixed is up to each project to decide, but each +project must, at least, continue to "fit in"; build, install and avoid +conflicts. To be explicit, new projects may join releases, and +participating projects may add new features or APIs (i.e. contribute +Minor Releases) if they would like to. Another important rule is that +new projects and even new features must be essentially complete, +including release review records, by RC1. Anything later than that must +also go through the Planning Council's formal [Exception +Process](SimRel/Simultaneous_Release_Requirements/Appendix#Planning_Council_Exception_Process "wikilink"). + +[Category:Coordinated](Category:Coordinated "wikilink") \ No newline at end of file diff --git a/wiki/SimRel/Simultaneous_Release_Requirements.md b/wiki/SimRel/Simultaneous_Release_Requirements.md new file mode 100644 index 0000000..7a76630 --- /dev/null +++ b/wiki/SimRel/Simultaneous_Release_Requirements.md @@ -0,0 +1,501 @@ +# The Eclipse Simultaneous Release Requirements + +Updated January 14, 2019 + +Authored and maintained by the [Eclipse Planning +Council](Planning_Council "wikilink") + +Contact: [Mélanie Bats](mailto:melanie.bats@obeo.fr) + +This document defines the rules and criteria for participating in the +Simultaneous Release. The simultaneous release occurs each year in June, +September, December and March. There are more criteria than when +releasing at other times. There are more requirements partially because +there are more projects releasing at once, so the workload needs to +streamlined and made uniform. But also, the extra criteria are included +by mutual agreement between projects (via their representatives to +Planning Council) so that as a whole, the release will be of better +quality, maintainability, and improved consumability. + +The spirit of this document is not be so much as a "contract" of what +has to be done to release, but instead a statement of what minimally is +necessary to make the release good, if not great! While each Project +does their individual things to make the release great, this document +describes how we, as a group, do that by our voluntary agreement to +participate and provide these minimum requirements. We are always open +to better documentation and more meaningful agreements, so please feel +free to make suggestions on how to make our release better from year to +year (preferably through your Planning Council representative). Changes +may be made to this document throughout the development cycle for +clarity or to improve reference links. + +To allow for some flexibility for special cases, exceptions to these +requirements are allowed, but to provide balance and foster good +communication, any exceptions to the items or deadlines must follow the +[Planning Council Exception +Process](SimRel/Simultaneous_Release_Requirements/Appendix#Planning_Council_Exception_Process "wikilink"). + +The requirements are divided into three categories: + +1. Mandatory requirements in order to participate in the simultaneous + release. Some of those are required to be completed **early in the + release cycle**. +2. Mandatory requirements to be part of the common software repository + and, consequently, the minimum requirements to be part of an EPP + package. +3. Optional requirements that improve adoption and demonstrate good + Eclipse Citizenship, following "the Eclipse Way". These are + requirements you do not have to fulfill, but are recommended, + encouraged, and the thing that you do have to do is to document if + and how you do them. + +## Mandatory Requirements for Participation + +The requirements and conditions stated in this section are the basic +minimum required for a project to claim they are part of the +Simultaneous Release. Some of those are required to be completed **early +in the release cycle**. + +### State intent early + +A project can join the Simultaneous Release at any release cycle during +the year. + +> Note that the list of projects that participate in the simultaneous +> release is determined by aggregation files in the [*aggregation* +> repository](https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/). +> Participating projects must keep their `aggrcon` files up-to-date. + +Every project team must designate one or more committers to represent +the interests of the project in matters related to the simultaneous +release. These representatives must subscribe to the +[cross-projects-issues-dev mailing +list](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev). + +#### How to announce your participation + +For projects that **did not** participate in the previous simultaneous +release, the project team's representative must state the project's +intent to do so via the [cross-projects-issues-dev mailing +list](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev) +before the **milestone 1 (M1)** date of the release. + +For projects that **did** participate in the previous simultaneous +release, the project team's representative must `touch` the project's +`aggrcon` file by the **milestone 2 (M2)** date of the release to +indicate that the project wishes to continue participating and that they +project team is paying attention. + +A [release +record](https://www.eclipse.org/projects/handbook/#pmi-releases) for the +release that is to be contributed must exist before the **milestone 1 +(M1)** date. If a project team intends to contribute the same content as +was contributed in the previous release, then no new release record is +required. If new content (and, by extension, a new release) is to be +contributed, then a new release record must be created. The regular +[release review +process](https://www.eclipse.org/projects/handbook/#release-review) must +be followed. + +> Note that the 2018 edition of the Eclipse Development Process +> introduces a new notion of a [Progress +> Review](https://www.eclipse.org/projects/dev_process/#6_3_5_Progress_Review). +> Projects may push out releases for a full calendar year following a +> successful Release Review or a Progress Review. Note also that this +> does not excuse the project team from the obligations of the Eclipse +> IP Policy: all intellectual property must be fully vetted before it +> may be included in any release. + +#### Dropping off + +A project representative can declare the project team's intent to +drop-off the simultaneous release at any time by sending a note to the +[cross-projects-issues-dev mailing +list](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev). + +> Note that marking an `aggrcon` file as disabled is considered a +> temporary state. The `aggrcon` must be removed from the repository for +> any project that has decided to leave the simultaneous release. + +If you have any questions, please contact your PMC's Planning Council +Representative, or the [EMO](mailto:emo@eclipse.org). + +### Formal (standard format) plans, early (M1) + +All projects must have their project plan in the Eclipse Foundation +standard format (i.e. create a [release +record](https://www.eclipse.org/projects/handbook/#pmi-releases) in the +PMI for your project and add corresponding milestones in Bugzilla). +Committing to be in the Simultaneous Release means you commit to having +these plans available early: by M1 at the latest. Naturally, plans will +change as development continues, and we encourage teams to update them +periodically, such as every milestone, to reflect reality and progress, +but an initial version is required by at least M1 should be a clear +statement of what was planned, what was achieved, and what was deferred. +Every plan, for any release, should have some specific items covered, +such as *Target Environments* and *Compatibility with Previous Releases* +but we give some specific guidance here since these are so important to +adoption. In addition, we do ask for one extra "theme" item, that is +technically required only for the Simultaneous Release. What you plan, +is up to each project, we just want to be sure its clear for adopters +and downstream projects. + +#### Target Environments + +Exactly what platforms and runtimes a project supports is up to them and +their community, but it is required all projects document what platforms +they support, especially if they have native (non-Java) code and +especially if it is different than the [set of platforms supported by +the Eclipse Platform +itself](http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments). + +For additional information see - [Appendix: Target +Environments](SimRel/Simultaneous_Release_Requirements/Appendix#Target_Environments "wikilink") + +#### Compatibility with Previous Releases + +It should be part of every project's plan to have a section detailing +compatibility with previous releases. This should not only include +commitments to API and binary compatibility, but ideally would also +include plans for source compatibility, workspace compatibility, and +project "coexistence" compatibility. See the template in [standard plan +reference](Development_Resources/Project_Plan "wikilink") and for +examples, see the plans for the +\[\| +Eclipse Platform\] and the +\[\| +Web Tools Platform project\]. + +For additional information see - [Appendix: +Compatibility](SimRel/Simultaneous_Release_Requirements/Appendix#Compatibility_with_Previous_Releases "wikilink") + +### IP Documentation and Logs (RC1) + +Projects must have their IP logs approved (a normal Eclipse requirement) +but follow the earlier deadlines set by EMO and IP staff. The IP log +deadline is typically mid-week RC1. + +For additional information see - [Appendix: IP +Logs](SimRel/Simultaneous_Release_Requirements/Appendix#IP_Documentation_and_Logs_.28RC1.29 "wikilink") + +### Release Review and compliance to requirements documentation (RC2) + +The release review documentation must be complete by the date specified +by the EMO, which is earlier than it would be for other releases. +(Typically mid-week during RC2.) In addition to normal release plan +requirements, for a Simultaneous Release, Project Leads must document +their verification that the project complies with all extra requirements +of this Simultaneous Release document, as they apply to their project, +and document any exceptions, there in the release review documentation. +This is intended to be a few short sentences or paragraphs, not a +detailed checklist. + +For additional information see - [Appendix: Release +Review](SimRel/Simultaneous_Release_Requirements/Appendix#Release_Review_and_compliance_to_requirements_documentation_.28RC3.29 "wikilink") + +## Mandatory Requirements for the Simultaneous Repository and EPP + +The requirements in this section were historically called "the must do" +items -- they are a "must" not for the release, but must be met for a +project to be on the common, central repository (e.g. /releases/oxygen). +The common repo is for end users to discover easily and therefore (per +EPP Policy) are the minimum requirements to be included in EPP Packages. +The criteria in this section are designed to make sure projects work +relatively well, and work well together and can be installed together. +This is especially required for adopters who may be using these projects +in complicated, interwoven ways so each piece of the puzzle must fit +together well and be dependable and be maintainable, as well as being on +time and IP clean. + +### Integrate Early and Often + +First-time participants are expected to be in an aggregation build by +M1, at the latest. Then, once in, always in. This firstly means by +agreeing to be in the simultaneous release. But, even more than that, it +is assumed that once you are in one Simultaneous Release, you will +continue to be, so the following year, it is assumed you will be in M1. + +**Note:** There is an implicit "opt-in" assumed when we start a new +development stream. That is, projects will be left enabled when we start +a new release cycle. But if projects appear to not be active, the +Planning Council will first try to contact the Project and their PMC. If +no response and no release record in place by M2, then they will be +disabled or removed. + +Put another way, being part of the Simultaneous Release is not a "one +time" activity, covering only the release part of the development cycle. +Instead, it is a commitment to stay "simultaneous" on an on-going basis. +Once in, if a project decides to not be part of future simultaneous +releases, they need to communicate that widely, and as early as +possible, since it could affect adopters or downstream projects. + +While part of the mechanics of [contributing to the +build](Simrel/Contributing_to_Simrel_Aggregation_Build#The_best_format_and_process_for_contributing_to_Sim._Release "wikilink"), +it is required that any contribution to the Simultaneous Release +repository be done by a unique change to the aggrcon file. There are two +ways to do this. First, your contribution repository can point to a +simple repository where you know for sure there is only one version of +your contribution available. Second, your contribution repository can be +a composite repository but then you name exactly which versions to +include. That is you need to specify all 4 version fields. You can, of +course, do both methods, simple repository and name exact versions if +you want the safety of that redundancy. + +### Communication + +At least one person from each project in a Simultaneous Release must +subscribe to [cross-project mailing +list](https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev), +since that is the primary communication channel for issues related to +the Simultaneous Release. Also, at least one person from each project +must subscribe to cross-project Bugzilla inbox (add +cross-project.inbox@eclipse.org to the "Add users to my watch list" box +at the bottom of your [Bugzilla email +preferences](https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email) +page), as that is the primary Bugzilla components for bugs that are +truly cross-project, or bugs which are not known to be in one particular +component. + +Your representative to the Planning Council, either from PMC or +Strategic Member, must attend Planning Council meetings and represent +you there. Presumably, of course, after meeting or communicating with +you and the other projects they represent, so they can fairly bring +forward concerns and vote on issues that affect all projects, if +required. Put another way, by committing to be in the Simultaneous +Release, you agree to abide by all the Planning Council decisions and +rules, so be sure your representative understands your project and your +situation. + +A build-team member or release engineer from each project must be "on +call" during the aggregation or integration periods to make sure any +issues can be addressed quickly. + +### Required Bundle forms and formats + +#### Version Numbering ([tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +Projects must use 4-part version numbers following the common semantics +described in the [Eclipse version +numbering](Version_Numbering "wikilink") document. + +#### OSGi bundle format + +All plug-ins (bundles) must use the true bundle form. That is, provide a +manifest.mf file, and not rely on the plugin.xml file being 'translated' +into a manifest.mf file at initial startup. With that, empty plugin.xml +files in the presence of a manifest.mf file should not be included in a +bundle. (For some old history, see .) + +#### Execution Environment ([partially tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +All plug-ins (that contain Java code) must correctly specify their +[Bundle Required Execution Environment +(BREE)](Execution_Environments "wikilink"). Resource-only bundles do not +need a BREE since it doesn't matter which version of Java they are used +with. + +- The maximum BREE up to and including the 2022-06 release is Java 11. +- Starting in 2022-09, BREE up to and including Java 17 +- Starting in 2024-06, BREE up to and including Java 21 (assuming Java + 21 remains the LTS release and it is released in Sept 2023 as + currently planned) +- and going forward the first Eclipse SimRel release to allow an LTS + will be 6-9 months later. + +#### Signing ([tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +Projects must use [signed plugins and features using the Eclipse +certificate](JAR_Signing "wikilink"). + +\[added 12/2015, for Neon\]. Note: If a jar is already signed by the +Eclipse certificate, then it must not be re-signed by projects for the +release train. + +#### Jarred Bundles + +Projects must use jarred plug-ins (with unpack=false) unless there are +technical reasons not to (i.e. require the directory form). + +#### License text consistency ([tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +Use standard forms of license documents so they are displayed in the +most usable, and concise way during install and update. It is a normal +requirement to use a standard [Eclipse Foundation "about" +template](http://www.eclipse.org/legal/epl/about.php), but where those +templates are edited by each project, care must be taken to be sure they +are edited in similar ways. That is, substantial differences are fine, +if required, but we need to avoid minor differences based on case, +dates, and formatting. Note that the Eclipse Foundation's license or +user agreement files may change from year to year (such as, see ). Since +Indigo, it is easier to point to a "symbolic" representation of the +license, that is inserted at build time, so it will be accurate with +less manual updates from each project (see ). + +### Re-use and share common third party code (partially [tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +Any third-party plug-ins that are common between projects must be +consumed via [Orbit](http://www.eclipse.org/orbit/). The Simultaneous +Release must not have duplicate third-party libraries (note that this +only applies to versions of the libraries; thus if project A requires +foo.jar 1.6 and project B uses foo.jar 1.7, that's normally ok, +different service versions a little less ok, such as 1.7.1 vs 1.7.2 +(those should be explained, if required), and a qualifier-only +difference is definitely not ok). + +Note: the "partially tested", for this case, means there is a report of +"Non Unique Versions used in repository" which can catch issues of not +using common bundles. See [current +report](http://build.eclipse.org/simrel/kepler/reporeports/reports/nonUniqueVersions.txt) +for an example. + +### Provide optimized p2 repository ([partially tested](#Testing_of_Simultaneous_Release_Repository "wikilink")) + +Projects must provide their own project p2 repository for their own +project and updates. Projects must [optimize their p2 +repositories](http://help.eclipse.org/2021-03/topic/org.eclipse.platform.doc.isv/guide/p2_repositorytasks.htm) +to reduce bandwidth utilization and provide a better install and update +experience for users. + +In addition, they must provide their artifacts and metadata in a +specified format and method to allow at least parts of their repository +to be aggregated and mirrored to a common repository. The [current +process](Simrel/Contributing_to_Simrel_Aggregation_Build "wikilink") may +be modified throughout the year, if improvements can be made. + +Feature "includes" must be strict, that is "include" an exact version of +that other feature. This is required so installs and builds can be +repeatable independent of the exact day of the install or the exact +repos enabled. This is the way things are, and have been for years, and +this statement is just making it explicit since technically it is +possible for people to use some p2 publishers that don't have this +predictability or repeatability (which can certainly be appropriate in +some contexts, just not the Simultaneous Release repository). While +there may, in the future, be new mechanisms that allow some "line up +collection" to be specified, it will be something new, not changing the +meaning of feature "includes" element via p2 metadata. + +For similar reasons, the repositories produced and contributed must use +p2 publishers that produce greedy='false' in the content metadata for +runtime-optional dependencies. See and the [p2 Publisher +wiki](http://wiki.eclipse.org/Equinox/p2/Publisher) for some history and +details on this issue of greedy vs. non-greedy requirements. But in +brief, to have a runtime-optional dependency be non-greedy is important +for several reasons, especially in an IDE environment. First it gives +ultimate control over what is installed to the user, based on their +feature selection, instead of depending on what happens to be available +from the repositories they are pointing to at that moment it time. It +also makes it much easier for adopters to be able to predict (and +maintain) what their users have installed. In fact, if something is +runtime-optional, but pulled into an install because someone did not +specify greedy='false' meta-data, there is no way an adopter can provide +a patch feature to one of their customers if that optional bundle causes +a bug. + +Everyone's p2 repositories must make use the of p2.mirrorsURL property. +For "how to" information, see [p2.mirrorsURL +wiki](Equinox/p2/p2.mirrorsURL "wikilink"). Note: this is not really a +"Simultaneous Release Requirement" but is required of any p2 repository +on Eclipse Foundation infrastructure, and is just documented here to +help spread the word and educate newcomers. + +Similar to p2.mirrorsURL attribute, a well behaved, well optimized p2 +repository should contain a p2.index file. This is especially important +for "composite repos" and prevents unnecessary "round trips" to server +looking for files. See for history and for how-to instructions, see the +[p2 wiki](Equinox/p2/p2_index "wikilink"). Again, this is not so much a +"Simultaneous Release Requirement" but is recommended of any p2 +repository on Eclipse Foundation infrastructure, and is just documented +here to help spread the word and educate newcomers. + +### Branding + +Each major project (as determined by participating PMCs) must have an +'About' dialog icon with hover text that displays the provider name. +Every plug-in and feature must specify a descriptive provider-name (for +features), or Bundle-Vendor header (for plug-ins), as determined by the +project's PMC (e.g. "Eclipse Modeling Project" rather than +"Eclipse.org"). Also, Projects should contribute to the welcome page +when appropriate. + +### Do No Harm + +Projects must work together in any combination of any install. Put +another way, this means that users can install any subset of the +projects participating in Simultaneous Release, and each of the +installed projects will work as well as if it had been installed +independently. If such a problem is identified, the affected projects +must track down and fix the problem, to be in the simultaneous release +repository. + +### Document Update Policy + +It is required that participating projects document whether or not they +support updating from one release to the next. For example, from Neon +(2016) to Oxygen (2017). \[The current implementation plan for tracking, +details TBD (see ), is for there to be a field in the PMI Release Record +that must be checked "Yes" or "No".\] To meet this requirement in the +affirmative: + + +\- The project will accept bugs as valid if an update does not work, or +there is a functional problem after updating. + +\- The project will test such updates. + +\- The project will document, such as in a "Migration Guide" or "Release +Notes", any details about what does or does not work across yearly +updates. For example, a user's workspace may be "migrated" to the new +release and not be usable by the old release after the update (but +projects freshly checked out or imported would continue to work with +either). Or, perhaps there are some known cases where some preference +setting would be lost and have to be set again by the user. + +Please note, this requirement is about *documenting* a project's policy. +As of this writing (for Oxygen) it is possible for a project to simply +document "No, updates from previous releases are not supported". In the +future, after more experience is gained, it is anticipated that it will +be required to support "continuous updates" even across each boundaries. +The only reason we do not make it required at this point in time is that +we are not sure we understand all the implications. Accordingly, has +been opened to document "requirements or issues" that participating +projects are aware of or find in support of this effort. + +## Optional Requirements + +The items in this category are, in a sense, optional. That is, what, +exactly, is done by a project is optional, but it is required for +projects to **document** what they do. These are often "best practices" +that many projects have found essential at driving good adoption, plus +the items sometimes speak to the quality of the project (quality as an +Eclipse "good citizen", as opposed to their code quality or +architecture). But, their importance is not as universally relevant to +all projects and their adopters, hence it is only required that each +project document what they do for these items, but exactly what they do +is up to the best judgment of the project and their community. + +Please see the appendix for a detailed list of these items: [Appendix: +Required for good +adoption](SimRel/Simultaneous_Release_Requirements/Appendix#Required_for_good_adoption "wikilink") + +# Additional Information + +- [Planning Council Exception + Process](SimRel/Simultaneous_Release_Requirements/Appendix#Planning_Council_Exception_Process "wikilink") +- [Simultaneous Release Policy + FAQ](SimRel/Simultaneous_Release_Policy_FAQ "wikilink") +- [Testing of Simultaneous Release + Repository](SimRel/Simultaneous_Release_Requirements/Appendix#Testing_of_Simultaneous_Release_Repository "wikilink") + + + + +[Category:Coordinated](Category:Coordinated "wikilink") +[Category:SimRel](Category:SimRel "wikilink") +[Juno](Category:Juno "wikilink") [Kepler](Category:Kepler "wikilink") +[Luna](Category:Luna "wikilink") [Mars](Category:Mars "wikilink") +[Neon](Category:Neon "wikilink") [Oxygen](Category:Oxygen "wikilink") +[Photon](Category:Photon "wikilink") +[SimRel-2018-09](Category:SimRel-2018-09 "wikilink") +[SimRel-2018-12](Category:SimRel-2018-12 "wikilink") +[SimRel-2019-03](Category:SimRel-2019-03 "wikilink") +[SimRel-2019-06](Category:SimRel-2019-06 "wikilink") \ No newline at end of file diff --git a/wiki/SimRel/Simultaneous_Release_Roles.md b/wiki/SimRel/Simultaneous_Release_Roles.md new file mode 100644 index 0000000..f5095b2 --- /dev/null +++ b/wiki/SimRel/Simultaneous_Release_Roles.md @@ -0,0 +1,166 @@ +## Simultaneous Release Roles + +Many tasks and activities must take place to produce our [Simultaneous +Release](../Simultaneous_Release.md), and the [Planning +Council](../Planning_Council.md) is responsible for many of those +tasks and activities. + +This document is to list some of those tasks and activities and group +them according to "roles" that various people play. Of course, the same +person may fill more than one role and sometimes a role can be shared by +more than one person. The important thing about this listing of roles is +to make sure that all areas are covered (i.e., assigned to someone), and +if someone is no longer able to perform a role, then someone else must +be found that can pickup their "job" with a clear understanding of +what's expected. + +This document will (likely) be be updated frequently, as we learn or +think of things we have to do but that have never been written down. +Also it will be updated as conditions change both within a release and +across releases. + +Also, please note, at this point in time, this is the first draft of +this document so it may contain many errors and omissions. Greatest +appreciation to you who find them. The goal of this document is not to +invent something new, of what we would wish to have, but just to +document what tasks we do or have done before. + +### Planning Council + +- Creates a schedule for the releases. Projects of course can have + additional releases ... but all participants are expected to deliver + and test the the quaterly releases. + + + +- Establish, by consensual agreement, the criteria required to be part + of the release. For example, see [Requirements For + Participation](SimRel/Simultaneous_Release_Requirements.md). + + + +- Determine the name of the release. + + + +- In addition to participating in meetings, the Planning Council must + also find people (from the PMCs or Strategic members they represent) + to carry out the tasks of the Simultaneous Release. + + + +- Delegation : Planning Council representatives are expected to + participate in each Planning Council meeting, but may send a + delegate if they can not attend a meeting. The delegate should be + able to participate in discussions and decisions on behalf of the + representative (that is, not just take note for the representative). + If a PC member finds they need to delegate 3 consecutive meetings, + they should strongly consider finding a new representative. If a + member does not attend and does not designate a delegate for 3 + consecutive meetings, they will be moved to the "inactive list". + Note: from an Eclipse Foundation (process) point of view, + participating on the Planning Council is a privilege of membership, + not an obligation ... but, naturally, to not exercise that privilege + leaves your project or member company unrepresented in decisions + about the Simultaneous Release. + + + +- Also see [Planning_Council](Planning_Council.md). + +### Planning Council Chair + +- Schedule and Lead meetings as required. +- Make sure the council operates fairly, according dev. process, and + at the same time making sure that the releases stay relevant to + users, and adopters, and are of the expected quality, etc. +- Make sure the schedule stays on track, and if not take corrective + action. +- Finds people to solve specific problems, or to fill required roles. +- Leads the planning council to consensus on the release criteria, + name, etc. + +### Build Producer + +- Historically there's always been an innovator in Eclipse who + produces a "build system" that Projects can input to, and when run + produces an update site, basically, that allows a common place for + all Eclipse Users to find the functionality they are looking for, + instead of having to search all over eclipse and find all the bits + and pieces that they require. + + + +- The Build Producer creates and maintains that system, not only for + the release but also for the subsequent simultaneous releases. So + this is a fairly long term commitment. + + + +- The Build Producer must also document the system, both in terms of + what projects need to do (and not do) but also document well enough + that someone could "reproduce" the build on their own hardware, + especially for testing purposes. + +### Build Meister + +- Helps people "get in to" the build, if there are questions or + issues. +- Helps diagnosis problems if people have trouble ... at least, be the + first point of contact. +- Keeps the builds running smoothly day to day. +- Makes sure that if someone breaks the build, that they attend to it + relatively quickly, or else communicates with them directly. +- Runs scripts to "move" the build from one location to another, such + as form build machine to staging area, and then later from staging + to releases area. +- Runs scripts to do any "final" preparation work that's required, + such perhaps to run pack200 on all the jars. (This is specific, + pack200 task is no longer required, since current builder mirrors + the pack.gz files directly, but will leave the line item for the + general case). + +### Build Testers + +- Creates scripts to run on a build to be sure various criteria are + met, for example, that all jars are signed (and if not, open bugs + against those who have not signed their jars). +- And many more tests that can be automated (e.g. check if execution + environment specified, check if different versions of third party + bundles used, etc). +- Run scripts to collect interesting statistics on the release ... how + many bites, how many projects, how many downloads. + +### Webmasters + +- Webmasters help by telling how and when to update and how to cause + least impact to Eclipse mirroring system. + +### Related Activity + +There are some related activities which, while related, are independent +of the roles of the [Planning Council](Planning_Council .md) and +the [Simultaneous Release](../Simultaneous_Release.md). + +#### EMO + +[This page](Simultaneous_Release_Roles_EMO.md) +describes EMO's role in the [Simultaneous +Release](../Simultaneous_Release.md). + +#### EPP Packages + +EPP produces packages of all-in-one downloads to make it easier for +users in the community to get started. + +While EPP of course uses the contents of the Simultaneous release, their +processes, criteria, and packages are their own. + +#### Eclipse Foundation Download pages + +The Eclipse Foundation can provide download pages meant to feature the +contents of the simultaneous release, sometimes even, perhaps providing +web page wizards, etc, to make it easier for users to get started. +Again, while this uses the content of the Simultaneous Release, their +process, efforts, goals, etc., are their own and not strictly related to +the Planning Council or Simultaneous Release. diff --git a/wiki/SimRel/Simultaneous_Release_Roles_EMO.md b/wiki/SimRel/Simultaneous_Release_Roles_EMO.md new file mode 100644 index 0000000..f8bc3d1 --- /dev/null +++ b/wiki/SimRel/Simultaneous_Release_Roles_EMO.md @@ -0,0 +1,22 @@ +## Eclipse Simultaneous Release: What the EMO Does + +*For Kepler, [EMO](mailto:emo@eclipse.org) = Wayne* + +### Release Logistics + +- Determines timeline for Release activities +- Creates list of participating projects +- Determines if each project has met the criteria for participation in + the Simultaneous Release +- Communicates review date +- Communicates review deadlines + - Documentation submission deadline + - IP Log submission deadline +- Reviews draft docuware and works with project teams to finalize +- Uploads final docuware (reformatting as necessary) +- Announces review to Eclipse community +- Moderates review conference call (if call takes place) +- Determines outcome of review +- Communicates outcome of review to participants and Eclipse community + +*This page is moderated by the EMO.* \ No newline at end of file diff --git a/wiki/Simultaneous_Release.md b/wiki/Simultaneous_Release.md new file mode 100644 index 0000000..355eba5 --- /dev/null +++ b/wiki/Simultaneous_Release.md @@ -0,0 +1,511 @@ +The [Eclipse Foundation](https://wiki.eclipse.org/Foundation) and its community of +projects and contributors produce releases on a coordinated schedule +that are often referred to as *simultaneous release*, *coordinated +release* or *release train* of Eclipse. This page provides an index of +existing simultaneous releases from the current and previous years. + +Since the 2018-09 release, the cadence changed from one annual main +release plus 3 update/service releases to a 13-week cycle with rolling +releases. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release name

Platform version

Release

Links

2023-12 (Future release)

4.30

December 06, 2023

Wiki
+

2023-09 (Current +release)

4.29

September 13, 2023

Wiki
+Package +Download Page
+p2 +Repository

2023-06 (Last release)

4.28

June 14, 2023

Wiki
+Package +Download Page
+p2 +Repository

2023-03

4.27

March 15, 2023

Wiki
+Package +Download Page
+p2 +Repository

2022-12

4.26

December 07, 2022

Wiki
+Package +Download Page
+p2 +Repository

2022-09

4.25

September 14, 2022

Wiki
+Package +Download Page
+p2 +Repository

2022-06

4.24

June 15, 2022

Wiki
+Package +Download Page
+p2 +Repository

2022-03

4.23

March 16, 2022

Wiki
+Package +Download Page
+p2 +Repository

2021-12

4.22

December 08, 2021

Wiki
+Package +Download Page
+p2 +Repository

2021-09

4.21

September 15, 2021

Wiki
+Package +Download Page
+p2 +Repository

2021-06

4.20

June 16, 2021

Wiki
+Package +Download Page
+p2 +Repository

2021-03

4.19

March 17, 2021

Wiki
+Package +Download Page
+p2 +Repository

2020-12

4.18

December 16, 2020

Wiki
+Package +Download Page
+p2 +Repository

2020-09

4.17

September 16, 2020

Wiki
+Package +Download Page
+p2 +Repository

2020-06

4.16

June 17, 2020

Wiki
+Package +Download Page
+p2 +Repository

2020-03

4.15

March 18, 2020

Wiki
+Package +Download Page
+p2 +Repository

2019-12

4.14

December 18, 2019

Wiki
+Package +Download Page
+p2 +Repository

2019-09

4.13

September 18, 2019

Wiki
+Package +Download Page
+p2 +Repository

2019-06

4.12

June 19, 2019

Wiki / Plan
+Package +Download Page
+p2 +Repository

2019-03

4.11

March 20, 2019

Wiki / Plan
+Package +Download Page
+p2 +Repository

2018-12

4.10

December 19, 2018

Wiki / Plan
+Package +Download Page
+p2 +Repository

2018-09

4.9

September 19, 2018

Wiki / Plan
+Package +Download Page
+p2 +Repository
+

+ +Before the 2018-09 release, each main release typically occurred in +June, with follow-up update releases in September (\*.1), December +(\*.2), and March (\*.3). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release name

Platform version

Main release

.1

.2

.3

Links

Photon

4.8

June 27, 2018

None

None

None

Web Site
+Wiki / Plan
+Main Download +Page
+p2 +Repository
+

Oxygen

4.7

June 28, 2017

September 27, 2017

December 20, 2017

March 21, 2018

Web Site
+Wiki / Plan
+Package +Download Page
+p2 +Repository
+

Neon

4.6

June 22, 2016

September 28, 2016

December 21, 2016

March 23, 2017

Web Site
+Wiki / Plan
+Package +Download Page
+p2 +Repository
+

+ +Before Neon, each release train had two service releases in September +(SR1) and February (SR2): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Release name

Platform version

Main release

SR1

SR2

Links

Mars

4.5

June 24, 2015

September 22, 2015

February 24, 2016

Web Site
+Wiki
+Package +Download Page
+p2 +Repository
+

Luna

4.4

June 25, 2014

September 23, 2014

February 25, 2015

Web Site
+Wiki
+Package +Download Page
+p2 +Repository

Kepler

4.3

June 26, 2013

September 27, 2013

February 28, 2014

Web Site
+Wiki
+Package +Download Page
+p2 +Repository

Juno

4.2 (3.8)

June 27, 2012

September 28, 2012

March 1, 2013

Web Site
+Wiki
+Package +Download Page
+p2 +Repository

Indigo

3.7

June 22, 2011

September 23, 2011

February 24, 2012

Web Site
+Wiki
+Download +Page
+Repository

Helios

3.6

June 23, 2010

September 24, 2010

February 25, 2011

Web Site
+Wiki
+Download +Page
+Repository

Galileo

3.5

June 24, 2009

September 25, 2009

February 26, 2010

Web Site
+Wiki
+Download +Page

Ganymede

3.4

June 25, 2008

September 24, 2008

February 25, 2009

Web Site
+Wiki
+Download +Page

Europa

3.3

June 27, 2007

September 28, 2007

February 29, 2008

Web Site
+Wiki
+Download +Page

Callisto

3.2

June 26, 2006

N/A

N/A

Web Site Wiki

+ +## More Information + +- [Overview of the Simultaneous Release + Process](SimRel/Overview.md) for projects