Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Architecture Council/Meetings/Meeting Notes"
m (→June 11, 2020) |
m |
||
| (10 intermediate revisions by 3 users not shown) | |||
| Line 11: | Line 11: | ||
=== Backlog === | === Backlog === | ||
(Please add agenda items/topics for discussion here.) | (Please add agenda items/topics for discussion here.) | ||
| − | * | + | * ... |
| − | + | ||
| − | + | ||
=== Action Items === | === Action Items === | ||
* none | * none | ||
| + | |||
=== Past Meetings === | === Past Meetings === | ||
| − | |||
| − | |||
| − | |||
| + | ==== October 8, 2020 ==== | ||
| − | + | Note that the meeting started late because of Zoom now requiring a moderator passcode. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | = | + | * No specific agenda items |
| + | * Topics started with a discussion on Eclipse Forum vs. GitHub Discussions.See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567232 | ||
| + | ==== September 10, 2020 ==== | ||
| − | * | + | * No specific agenda items |
| − | ** | + | * Open discussion around the IP License Tool: [https://www.eclipse.org/projects/handbook/#ip-license-tool Link to Handbook Section] |
| − | ** IP | + | ** Tool works pretty good |
| − | ** | + | ** Project handbook got a major overhaul and talks about the new process. It's in Git and people should contribute to it: [https://git.eclipse.org/c/dash/org.eclipse.dash.handbook.git/ Link to Handbook Git Repository] |
| − | ** | + | ** Link to IP Tool in project handbook is not easy to spot right away |
| − | ** | + | ** Ivar produced a video introducing the tool: [https://youtu.be/SYHB9HIR7xo Link to video] |
| − | ** | + | |
| − | ** | + | |
| − | * | + | ==== July 9, 2020 ==== |
| − | ** reduced engagement with IP team | + | |
| − | + | * We'll cancel the August meeting (summer break) | |
| − | ** | + | * No other topics; meeting ended early |
| − | + | ||
| − | + | ||
| − | + | ==== June 11, 2020 ==== | |
| − | ** | + | |
| − | ** | + | * EMO Update |
| − | + | ** Reminding projects that a release review required only once per year; starting to push back on projects requesting too often | |
| − | + | ** Working on a better communication strategy | |
| − | + | ** Reminder that piggyback are not used anymore | |
| − | + | ||
| − | + | * General discussion about the IP tools | |
| − | + | ** Goal: reduced engagement with IP team | |
| − | + | ** Clearly Defined is used to just extract license info | |
| − | + | ** Tool to automate as much as possible | |
| − | ** should | + | ** The project handbook needs an update; it doesn't mention the IP tool currently |
| − | + | ** Projects should capture the output of the tool and version it | |
| − | + | ** PMCs should help with educating projects | |
| − | + | ||
| − | + | * PMC voting discussion - is it a mandatory thing? | |
| − | + | ||
| − | + | ||
| − | ** | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
** IP team needs to know it makes sense | ** IP team needs to know it makes sense | ||
| − | ** PMC can discuss on the CQ, but as soon as someone adds a +1 they jump in | + | ** PMC can discuss on the CQ, but as soon as someone adds a +1 they jump in and consider it consent, i.e. just one PMC vote is sufficient |
| − | + | ** There are some problems with IPzilla; occasionally +1 does not trigger the process correclty | |
| − | ** occasionally +1 does not | + | ** Kai asked if we canagree that if any of the PMC hits OK then it is OK |
| − | + | ** Wayne replied that one member can approve it, if he can do it with confidence then it is OK | |
| − | * | + | ** In the past more formal voting was required; this is no longer required. This change was not communicated properly. |
| − | + | ** With a growing base of projects it becomes harder from PMC to be aware of all codebases | |
| − | * Kai | + | *** we as PMC trust project leads |
| − | + | ||
| − | + | ||
| − | ** one member can approve it, if he can do it with confidence then it is OK | + | |
| − | ** no | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
** We need the PMC to clarify if it is a "works with" | ** We need the PMC to clarify if it is a "works with" | ||
| − | + | ** Also, only if the content requires further review a CQ has to be created | |
| − | ** only if the content requires further review a CQ has to be created | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | * Should the IP run the tool instead of committers? | |
| + | ** Concern that this is a lot more work for a small team | ||
| + | ** IP team running the tool assumes the IP team understands the project structure and all technologies | ||
| + | ** Thus, it makes more sense that this work has to be done by the projects | ||
| + | * Latency between new released and updates in IP database | ||
| + | ** spring new miner version every few months; still have to create CQs | ||
| + | ** Wayne: we need it **only* on releases; forget intermediate version | ||
| + | ** engage IP team as early as possible | ||
| − | * | + | * Incubation and EPP |
| − | + | ** We had incubating problems before | |
| − | ** | + | ** Feature must be branded with incubating |
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** | + | |
** EPP needs to declare that | ** EPP needs to declare that | ||
| − | + | ** One challenge is stable APIs; API is a framework to support adopters; Every project defines its own rules | |
| − | ** | + | ** PMC can define what stable means |
| − | + | ** Wayne will take to the IP adviser community to discuss future of incubation | |
| − | + | ** For transparency it may be helpful to keep this flag; projects are learning; there might be IP problems in the project; some companies care | |
| − | + | ** We need the motivation to move out of incubation; The package owners have the motivation to push the incubating projects | |
| − | + | ** No need to have "incubating" or "incubation" in the download/file name; just the about dialog and feature name is enough | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** PMC can define what stable | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** will take to the IP adviser | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** | + | |
| − | ** | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ** | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | |||
| − | |||
==== May 14, 2020 ==== | ==== May 14, 2020 ==== | ||
* EMO Update | * EMO Update | ||
| − | ** Wayne asked one more time for feedback | + | ** Wayne asked one more time for feedback on the IP tool. |
** The IP tool is now part of Dash in GitHub and pull-request are welcome. | ** The IP tool is now part of Dash in GitHub and pull-request are welcome. | ||
*** Jonah contributed Yarn support. | *** Jonah contributed Yarn support. | ||
| Line 266: | Line 99: | ||
* Infrastructure Update | * Infrastructure Update | ||
| − | ** New firewalls were put in place early May. They har redundant and part of the program to reduce single-point-of-failures. | + | ** New firewalls were put in place in early May. They har redundant and part of the program to reduce single-point-of-failures. |
| − | ** Thanks to a lot help we are clear for a long overdue Gerrit update. The sandbox is running and an upgrade is planned for after the 2020-06 release. Please prepare as Gerrit will come with a new UI/UX. | + | ** Thanks to a lot of help we are clear for a long-overdue Gerrit update. The sandbox is running and an upgrade is planned for after the 2020-06 release. Please prepare as Gerrit will come with a new UI/UX. |
** Jonah asked if we are on the latest version of Bugzilla. Denis confirmed we are on the latest official release. | ** Jonah asked if we are on the latest version of Bugzilla. Denis confirmed we are on the latest official release. | ||
| − | *** There is an edit extension | + | *** There is an edit extension that Denis was unable to get to work in our Bugzilla instance. |
** Setup of a production GitLab instance in Switzerland started. | ** Setup of a production GitLab instance in Switzerland started. | ||
* Removing Inactive Committers | * Removing Inactive Committers | ||
** The general feedback is that this should not be automated. | ** The general feedback is that this should not be automated. | ||
| − | ** However, having a regular reminder to project leads for | + | ** However, having a regular reminder to project leads for housekeeping the committers is a good idea. |
** The definition of "active" is blurry. Hence, it always has to be a manual process. | ** The definition of "active" is blurry. Hence, it always has to be a manual process. | ||
| Line 288: | Line 121: | ||
* EMO Update | * EMO Update | ||
** Wayne thanked for feedback to IP tooling received so far. It's helpful. Please provide more feedback if you can. | ** Wayne thanked for feedback to IP tooling received so far. It's helpful. Please provide more feedback if you can. | ||
| − | ** Next steps are to make a repository available and bring tooling to the Eclipse Dash project and make it available. | + | ** The Next steps are to make a repository available and bring tooling to the Eclipse Dash project and make it available. |
** As of today, CQs for known license sources of 3rd party content is no longer required. | ** As of today, CQs for known license sources of 3rd party content is no longer required. | ||
| Line 299: | Line 132: | ||
* Anonymous contributions (Jonah) | * Anonymous contributions (Jonah) | ||
| − | ** A GitHub account as contributor is ok, it can be traced back to an individual. | + | ** A GitHub account as a contributor is ok, it can be traced back to an individual. |
** An ECA must be signed in any case. This requires a real email address and this is sufficient. | ** An ECA must be signed in any case. This requires a real email address and this is sufficient. | ||
** EMO expectation to committers is to monitor and catch/report shenanigans. | ** EMO expectation to committers is to monitor and catch/report shenanigans. | ||
| − | ** The handbook wording needs an updated and will investigated separately. | + | ** The handbook wording needs an updated and will be investigated separately. |
* Parallel IP (Jonah) | * Parallel IP (Jonah) | ||
** Wayne explained that Parallel IP is now the standard way of doing things at Eclipse. | ** Wayne explained that Parallel IP is now the standard way of doing things at Eclipse. | ||
| − | ** The code can go in early but a release needs to wait for full review. | + | ** The code can go in early but a release needs to wait for a full review. |
| − | ** It's important to put release records | + | ** It's important to put release records into PMI as early as possible. The IP team will use the dates to prioritize their work. |
Revision as of 11:22, 8 October 2020
This page captures meeting notes of the Eclipse Architecture Council.
Please add topics for the next call to the backlog, but not during a call!
Standing Agenda
- Update from EMO (Wayne/Gunnar)
- Infrastructure Update (Denis)
- Backlog
Backlog
(Please add agenda items/topics for discussion here.)
- ...
Action Items
- none
Past Meetings
October 8, 2020
Note that the meeting started late because of Zoom now requiring a moderator passcode.
- No specific agenda items
- Topics started with a discussion on Eclipse Forum vs. GitHub Discussions.See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567232
September 10, 2020
- No specific agenda items
- Open discussion around the IP License Tool: Link to Handbook Section
- Tool works pretty good
- Project handbook got a major overhaul and talks about the new process. It's in Git and people should contribute to it: Link to Handbook Git Repository
- Link to IP Tool in project handbook is not easy to spot right away
- Ivar produced a video introducing the tool: Link to video
July 9, 2020
- We'll cancel the August meeting (summer break)
- No other topics; meeting ended early
June 11, 2020
- EMO Update
- Reminding projects that a release review required only once per year; starting to push back on projects requesting too often
- Working on a better communication strategy
- Reminder that piggyback are not used anymore
- General discussion about the IP tools
- Goal: reduced engagement with IP team
- Clearly Defined is used to just extract license info
- Tool to automate as much as possible
- The project handbook needs an update; it doesn't mention the IP tool currently
- Projects should capture the output of the tool and version it
- PMCs should help with educating projects
- PMC voting discussion - is it a mandatory thing?
- IP team needs to know it makes sense
- PMC can discuss on the CQ, but as soon as someone adds a +1 they jump in and consider it consent, i.e. just one PMC vote is sufficient
- There are some problems with IPzilla; occasionally +1 does not trigger the process correclty
- Kai asked if we canagree that if any of the PMC hits OK then it is OK
- Wayne replied that one member can approve it, if he can do it with confidence then it is OK
- In the past more formal voting was required; this is no longer required. This change was not communicated properly.
- With a growing base of projects it becomes harder from PMC to be aware of all codebases
- we as PMC trust project leads
- We need the PMC to clarify if it is a "works with"
- Also, only if the content requires further review a CQ has to be created
- Should the IP run the tool instead of committers?
- Concern that this is a lot more work for a small team
- IP team running the tool assumes the IP team understands the project structure and all technologies
- Thus, it makes more sense that this work has to be done by the projects
- Latency between new released and updates in IP database
- spring new miner version every few months; still have to create CQs
- Wayne: we need it **only* on releases; forget intermediate version
- engage IP team as early as possible
- Incubation and EPP
- We had incubating problems before
- Feature must be branded with incubating
- EPP needs to declare that
- One challenge is stable APIs; API is a framework to support adopters; Every project defines its own rules
- PMC can define what stable means
- Wayne will take to the IP adviser community to discuss future of incubation
- For transparency it may be helpful to keep this flag; projects are learning; there might be IP problems in the project; some companies care
- We need the motivation to move out of incubation; The package owners have the motivation to push the incubating projects
- No need to have "incubating" or "incubation" in the download/file name; just the about dialog and feature name is enough
May 14, 2020
- EMO Update
- Wayne asked one more time for feedback on the IP tool.
- The IP tool is now part of Dash in GitHub and pull-request are welcome.
- Jonah contributed Yarn support.
- There are a few interesting project proposals coming up and mentors wanted.
- Infrastructure Update
- New firewalls were put in place in early May. They har redundant and part of the program to reduce single-point-of-failures.
- Thanks to a lot of help we are clear for a long-overdue Gerrit update. The sandbox is running and an upgrade is planned for after the 2020-06 release. Please prepare as Gerrit will come with a new UI/UX.
- Jonah asked if we are on the latest version of Bugzilla. Denis confirmed we are on the latest official release.
- There is an edit extension that Denis was unable to get to work in our Bugzilla instance.
- Setup of a production GitLab instance in Switzerland started.
- Removing Inactive Committers
- The general feedback is that this should not be automated.
- However, having a regular reminder to project leads for housekeeping the committers is a good idea.
- The definition of "active" is blurry. Hence, it always has to be a manual process.
- Mailing List Search
- Searching the mailing list was possible using Google Custom Search
- Seems to be broken - Jonah will open a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=563173)
March 12, 2020
- Infrastructure Update
- New servers ready to go to replace servers that failed last month. ETA next week.
- Better hardware and 10 GBit technology will make things much better in the backend.
- EMO Update
- Wayne thanked for feedback to IP tooling received so far. It's helpful. Please provide more feedback if you can.
- The Next steps are to make a repository available and bring tooling to the Eclipse Dash project and make it available.
- As of today, CQs for known license sources of 3rd party content is no longer required.
- 3rd-party Mailing Lists
- Emily made us aware of an ask to send committer nomination emails to mailing lists outside Eclipse.org. While the PMI cannot do it easily, there is a workaround by subscribing the external mailing list to the Eclipse.org mailing list.
- New candidates for Architecture Council Membership (Wayne)
- We need to recruit/include members that are not yet known and work in Eclipse projects for a very long time already but with no intersection with others.
- Gunnar proposed a mentorship/outreach program/sessions where one AC member starts a conversation with potential candidates, explains the role of the AC, the work, etc. The goal is to get to know each other and invite new members to the AC.
- Anonymous contributions (Jonah)
- A GitHub account as a contributor is ok, it can be traced back to an individual.
- An ECA must be signed in any case. This requires a real email address and this is sufficient.
- EMO expectation to committers is to monitor and catch/report shenanigans.
- The handbook wording needs an updated and will be investigated separately.
- Parallel IP (Jonah)
- Wayne explained that Parallel IP is now the standard way of doing things at Eclipse.
- The code can go in early but a release needs to wait for a full review.
- It's important to put release records into PMI as early as possible. The IP team will use the dates to prioritize their work.
January 9, 2020
- Welcome Noopur to the AC
- No other topics so end the meeting early
Archive
Older meeting notes can be found in Architecture Council/Meetings/Archive.