Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Architecture Council/Meetings/Meeting Notes"

 
(93 intermediate revisions by 10 users not shown)
Line 4: Line 4:
 
Please add topics for the next call to the backlog, but '''<font color="red">not during a call!</font>'''
 
Please add topics for the next call to the backlog, but '''<font color="red">not during a call!</font>'''
  
 +
=== Standing Agenda ===
 +
* Update from EMO (Wayne/Gunnar)
 +
* Infrastructure Update (Denis)
 +
* Backlog
  
== Standing Agenda  ==
+
=== Backlog ===
 +
(Please add agenda items/topics for discussion here.)
 +
* Welcome new members.
 +
* New member candidates (Wayne)
 +
 
 +
=== Action Items ===
 +
* n/a
 +
 
 +
=== Upcoming Meetings ===
 +
 
 +
==== January 11, 2024 ====
 +
* PMI Requirement and GitHub Releases (Gunnar/Kai)
 +
** Gunnar reconfirmed that the EDP does not require the use of a particular technology/solution but defines requirements.
 +
** As such the use of PMI is to fulfill the documentation requirement.
 +
** This documentation requirement can also be fulfilled by GitHub releases.
 +
** Developers don't like typing information twice
 +
** Gunnar will get final confirmation from EMO.
 +
* Jay Jay shared the news of Amazon joining the Eclipse Foundation.
 +
 
 +
==== May 11, 2023 ====
 
* Update from EMO (Wayne/Gunnar)
 
* Update from EMO (Wayne/Gunnar)
 
* Infrastructure Update (Denis)
 
* Infrastructure Update (Denis)
 
* Backlog
 
* Backlog
  
== Backlog ==
+
=== Backlog ===
* Please add agenda items/topics for discussion here.
+
(Please add agenda items/topics for discussion here.)
 +
* Welcome new members.
 +
* New member candidates (Wayne)
 +
* Where will we migrate the Arch Council content to when the wiki is retired?
 +
 
 +
=== Action Items ===
 +
* n/a
 +
 
 +
=== Past Meetings ===
 +
 
 +
==== Apr. 13, 2023 ====
 +
 
 +
*Welcome new members
 +
** Heiko Klare
 +
*Update from EMO (Wayne/Gunnar)
 +
** Good call with committers today about using generative AI and large language models in our open source projects. The general consensus seems to be that we will just have to learn to live with it! Note that the DCO states that the submitter wrote the code. We will have to update various properties. The Council discussed this at some length.
 +
** With respect to the cyber resiliency act, EF has a team working on this. The timeline is 2024, and EF is trying to get ahead of it. Mike blog posts on this topic are popular right now. Wayne will share some links.
 +
*** https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resiliency-act-potential-impact-eclipse-foundation
 +
*** https://blogs.eclipse.org/post/mike-milinkovich/cyber-resilience-act-good-intentions-and-unintended-consequences
 +
*** https://blogs.eclipse.org/post/mike-milinkovich/product-liability-directive-more-bad-news-open-source
 +
** How do we handle stale committers? This depends on whether the project is a code project or a specification project. On spec projects, some number of committers may not be active, but their presence grants patent rights. On source code projects, project leads send emails every now and again asking if people want to still be a committer.
 +
** The move to IPLab from IPZilla seems to have gone well. Users appear to be happy. Some projects are integrating IP checks directly into their builds. EF is also looking at the OSS Review Toolkit (ORT) to dive deeper on dependencies, due diligence, etc.
 +
*Infrastructure Update (Denis)
 +
** None
 +
*Jay asked about whether or not we should get a Slack/Mattermost/Discord/Gitter/Matrix, etc. channel.
 +
 
 +
*Action Items
 +
** Wayne will share some links with relevant blog posts from Mike about the cyber resiliency act, etc. '''DONE''' (see above)
 +
** Wayne will dig into the license questions about transitive dependencies.
 +
** Jay will look into getting a Slack channel for the council.
 +
 
 +
==== Dec. 8, 2022 ====
 +
* GitHub Releases and Milestones as official location for projects to publish release intentions and releases. See in part https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1906
 +
** Role of PMI, lot's projects just pointing to GitHub info.
 +
** Need to ask: why is PMI showing this information, i.e. is it still necessary?
 +
** IP team uses upcoming release dates to prioritize queue
 +
** EMO will reflect on what's possible here (eg., just pull info from GitHub)
 +
 
 +
* 1.0 Versions of a project
 +
** Are they still special? Handbook talks a lot about it in context with Graduation Review
 +
** A Progress Review within last twelve months is sufficient
 +
** No extra PMC vote necessary for the first release, just check the project has done a progress review in the last twelve months
 +
** Specs are different, they still require a release review for every release
 +
 
 +
* ECA and GitHub email address don't match
 +
** Issue is know by EMO, hope to address that in the next year
 +
** If it's just a comma, just merge the PR.
 +
 
 +
==== Oct. 25, 2022 ====
 +
* Eclipse.org and project website; new proposal will be made in the coming weeks
 +
 
 +
==== July 14, 2022 ====
 +
* n/a
 +
* will skip the August call
 +
 
 +
==== June 9, 2022 ====
 +
* Wayne asked for feedback about IP policy changes
 +
* Q&A round IP policy changes
 +
 
 +
 
 +
==== May 12, 2022 ====
 +
* Infrastructure Update (Denis)
 +
* Feedback from moving off of Bugzilla/Gerrit stack is positive overall
 +
* Discussion about wish for some projects to be able to use Eclipse project PGP keys to sign in GitHub actions (eg having private keys registered as secrets on related GitHub repo).
 +
 
 +
 
 +
==== Apr. 14, 2022 ====
 +
* IP Policy Update (Mike)
 +
* Update from EMO (Wayne/Gunnar)
 +
* Infrastructure Update (Denis)
 +
* Backlog
 +
 
 +
 
 +
==== Mar. 10, 2022 ====
 +
* Wayne raises awareness that mentoring is not working
 +
** small number of mentors mentoring majority of projects
 +
** mentors don't tend to install themselves into the projects (eg., join project's mailing list)
 +
** It looks like it's easier for people to just contact EMO directly because they already have a relationship with EMO
 +
* Gunnar shared feedback that mentorship is pull not push, i.e. installing into projects seems like a new requirement
 +
* Ivar asked if there is some documentation/description of what's expected from mentors
 +
** looks like there isn't
 +
* Mickael raised the idea that mentorship should need to become optional because EMO is doing a good job at onboarding and helping projects.
 +
** As an alternative, Gunnar recommended to foster building relationships between projects and their PMC (eg., a welcome/intro email)
 +
* Another idea discusses was that EMO assesses during progress review if projects need help and request mentor
 +
 
 +
 
 +
==== Nov. 11, 2021 ====
 +
* Welcome Daimler to the AC
 +
* IT Update from Denis
 +
** Big connectivity improvements coming (10GBit), rate limiting will still be in place
 +
** Jenkins stability issues continue
 +
** Lot's of deprecation to legacy services (MediaWiki, Bugzilla, Forums); process to follow; no final shutdown date yet
 +
* Jens Raimann shared feedback from Community Day
 +
** Community (new projects) is struggling with CI - what is there, which one to use
 +
** Jonah: only two official options - GitHub actions and Jenkins
 +
 
 +
 
 +
==== Oct. 14, 2021 ====
 +
* No updates since Sept.
 +
* Mickael started to use IP tools and noticed that PMC approval is no longer mandatory for using a dependency.
 +
** Wayne confirmed this is the new flow.
 +
** PMC still involved in review process.
 +
** PMC can re-add requirement to review every single dependency if they want to.
 +
* Jonah gave an update to Jar signing that's coming to the Simultaneous release.
 +
** The important requirement is signing, the specific implementation should support common ways.
 +
** Jar signing is no longer the only option, GPG signing will be possible too.
 +
** Feedback via Planning Council rep.
 +
** Eclipse Foundation investigating web of trust with regards to GPG keys
 +
 
 +
 
 +
==== Sept. 9, 2021 ====
 +
* Welcome back after summer break!
 +
* EMO Update (Wayne)
 +
** EF is CVE issuing authority and Eclipse projects becoming more and more a target of security researchers, specifically runtime related projects
 +
** vulnerability submitted via Bugzilla with limited visibility scope; to be published after three months
 +
** trying to engage developers on vulnerability
 +
** OSS Review Toolkit - https://github.com/oss-review-toolkit
 +
** Rethinking the IP database
 +
*** still tracks review work and cryptography
 +
* GitLab maintainer permission delegation - see https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04400.html (Jonah)
 +
** Need to consult with IT team - Please open an issue (Issue opened https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/64)
 +
** Maybe it's possible to give developers broader permissions by default
 +
* EMO switch from Bugzilla to GitLab (Wayne)
 +
** Trying to do all of EMO interaction via GitLab.
 +
** Problem arise if a developer never signed up with GitLab yet. Needs discussion with IT team.
 +
** Committer id is used in GitLab, which is not great.
 +
* Progress review reviews (Wayne)
 +
** Going well, some unveiling IP issues, which are addressed along the way.
 +
 
 +
==== June 10, 2021 ====
 +
* EMO Update (Wayne)
 +
** Looking for opportunities to get EMO out of the way (eg, eliminate CQ approval requirement for PMC, eliminate IPzilla, etc.)
 +
** Expect to come up with more specific items to AC for feedback and review
 +
** Started initiating progress reviews with projects directly
 +
** Starting to capture OSS and IP information beyond source code (eg., images, binary files, docs, etc.) to make it easier for adopters
 +
** Looking at OpenChain: getting certified, become a leader in that area.
 +
** Also looking at [https://github.com/oss-review-toolkit/ort OSS Review Toolkit]
 +
* Q/A
 +
** Kay gave feedback that automated generation of NOTICE file is needed. Currently lots of manual work.
 +
 
 +
 
 +
==== Mar. 11, 2021 ====
 +
* 'Signed Off By' requirements (from cross platform list topic, https://bugs.eclipse.org/558653)
 +
** Work started at the Board to revitalize discussion. There is sufficient evidence out there that it should be possible to remove the requirement.
 +
** No ETA yet. Discussion requires convincing lawyers.
 +
** Architecture Council unanimously agrees that this needs to go
 +
 
 +
* ECA signing process from GitHub - what improvements to make in the workflow
 +
** bug open to allow signing with GitHub account only (https://bugs.eclipse.org/571711)
 +
** unrelated but worth to watch: make ECA work with dependabot (https://bugs.eclipse.org/570548)
 +
 
 +
* Permission handling in GitHub - trust vs. control
 +
** three teams created - committers, leads and collaborators
 +
** leads do not get full admin permissions; webmasters would like to stay in control to avoid mistakes and keep maintenance costs (level of paranoia)
 +
** automatic checks limited by gaps in GitHub API
 +
** process in place for requesting admin permissions
 +
 
 +
* Progress Reviews: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=571511 plans and ETA] for availability on PMI
 +
** prioritized for Q2/2021
 +
 
 +
* EMO moving from Bugzilla to GitLab
 +
** Experimenting with automatic reviews of third-party content via GitLab (purposely avoiding using the term "CQ") ([https://github.com/eclipse/dash-licenses/issues/51 here] and [https://gitlab.eclipse.org/eclipsefdn/iplab/emo/-/issues/2 here])
 +
 
 +
* [https://gitlab.eclipse.org/eclipsefdn/iplab/emo/-/issues/1 Eliminate release reviews] (except for specification projects)
 +
** Consider having EMO initiate annual progress reviews
 +
*** Give projects a one-month warning
 +
*** EMO validates IP Log, legal documentation
 +
*** PMC validates conformance to EDP, open source rules of engagement
 +
*** Architecture Council reviews results
 +
** Benefits
 +
*** Take the responsibility away from projects; one fewer thing to think about
 +
*** Spread the load
 +
*** Identify and terminate dead projects
 +
*** Identify and connect with projects that aren't engaged in the process
 +
** Concerns
 +
*** ~400 projects
 +
** Help/input of AC is needed - how can we help to improve the situation and reduce burden on committers as well as EMO (reviewing all 400 projects each year)
 +
 
 +
* CVE Policy
 +
** Security Team, EMO more aggressively create CVEs (with or without project team assistance)
 +
** Projects need to understand that they have to collaborate.
 +
** Work with reporter on CVE if projects don't participate
 +
** Involve AC when there is disagreement between reporter and project on CVE
 +
** Nuclear option if project is unwilling to participate and collaborate with community
 +
 
 +
==== Feb. 11, 2021 ====
 +
 
 +
* Infrastructure
 +
** Kubernetes cluster update not flawless, still monitoring and investigating
 +
** Mail server upgrade under way. Mailing lists should deliver more reliably now.
 +
** Gerrit upgrade pending.
 +
 
 +
* EMO Update
 +
** Confirmed that AC members are all up-to-date on IP policy updates
 +
** Dash license tool now available as Maven plug-in
 +
*** https://github.com/eclipse/dash-licenses
 +
** Moving away from IPzilla (not eta yet)
 +
 
 +
* Could Micro/Service Release skip the review process?
 +
** See [https://github.com/EclipseFdn/EFSP/issues/29 this] issue and [https://groups.google.com/g/microprofile/c/ZC-ZrPM80fQ this] MicroProfile googlemail discussion.
 +
** Any specification release (major, minor, service) can potentially include substantial new IP hence the requirement for a review.
 +
** Short answer: no, a new revision of the specification process is necessary
 +
*** new revision 1.3 would be necessary (requires Board review and approval)
 +
*** concept of Errata (https://github.com/EclipseFdn/EFSP/issues/32) but introducing a fourth thing is too much; potentially consolidating/categorizing with service release type preferred
 +
 
 +
 
 +
==== January 14, 2021 ====
 +
 
 +
* Mailing Lists
 +
** Some mail is currently lost. There is a plan to fix this but it potentially ruins the mailing list experience.
 +
** Please follow https://bugs.eclipse.org/541216
 +
 
 +
* Bringing single developer projects into projects
 +
** Experience shared from Jonah that it took a very long time to get a project into Eclipse and ultimately was a painful experience.
 +
** Value seems to be the challenging. Not everyone is looking for process. This may be a social issue rather than a technical one.
 +
** Examples: PyDev, Embedded CDT
 +
** There are successful single person projects. They came to Eclipse because the creator of those projects realized a value.
 +
** Working Groups are a model that could help here - setting up a working group to collect "money" from multiple members to sponsor development for such a single developer project.
 +
 
 +
* Feedback for Clearly Defined
 +
** Consider lowering the score required for ClearlyDefined (e.g. https://clearlydefined.io/definitions/maven/mavencentral/commons-codec/commons-codec/1.14 has score of 60 for license - another example is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=22912 which also has 60 score https://clearlydefined.io/definitions/maven/mavencentral/org.slf4j/slf4j-jdk14/1.7.30)
 +
*** The scores look like Effective: 60/100 Breakdown Consistency: 15/15 Declared: 30/30 Discovered: 0/25 SPDX: 15/15 License texts: 0/15
 +
** The low score effectively makes a lot of ''good'' libraries requiring a CQ.
 +
** Keep in mind that libraries with previously approved CQs should not require a new CQ (same version and bug-fix releases).
 +
 
 +
* Future of Orbit / Consuming Maven artifacts "on the fly"
 +
** See discussion here: https://www.eclipse.org/lists/orbit-dev/msg05422.html
 +
** Quality of OSGi metadata is a concern. Jonah raised his recent JAXB experience with the EPP. Potential for lots of errors if projects start distributing Maven artifacts of same version with different OSGi metadata
 +
** Orbit is slowing down projects (IP, process, work). Slowdown is especially noticeable in early/innovate phase. The new functionality is useful from that perspective.
 +
** Need to convince projects that there is a long term value (maintenance costs) in having proper metadata in Orbit.
 +
** Important point: Orbit is only relevant if you are ''consuming'' from a p2 repository.
 +
** Orbit is not a solution as long as there are bad practices/patterns:
 +
*** don't hard code versions in feature.xml
 +
*** if you have to do: update frequently
 +
*** provide alternate features for adopters ''without'' any third-party references
 +
*** don't use Require-Bundle, use useful imports
 +
** If upstream Maven artifact already provides proper metadata then it shouldn't be a problem consuming it as is.
 +
** Work with upstream improving the metadata where possible.
 +
** It's at the discretion of the projects and PMCs to decide. One possible recommendation could be to allow it for artifacts with good OSGi metadata already but don't allow "on-the-fly" generation.
 +
 
 +
==== November 12, 2020 ====
 +
 
 +
* Moment of silence for Dani Megert
 +
 
 +
* EMO Update
 +
** Lots of ideas coming out of EclipseCon!
 +
** Wayne demonstrated a GitLab prototype for a new IPZilla implementation. See http://gitlab.eclipse.org/eclipsefdn/iplab.
 +
** Denis pointed out that this is a great idea from an infra perspective since IpZilla has some special requirements on the infra side.
 +
 
 +
* EclipseCon Thoughts
 +
** Feeling that the conference was great.
 +
** Content was good.
 +
** Swapcard was nice.
 +
 
 +
* Infrastructure Update
 +
** Stood up a second Kubernetes cluster to better support services. This installation is also an OKD cluster.
 +
** Migrating projects to GitLab. Some subtle issues with migrating Bugzilla issues. Hopefully will migrate more projects off of Bugzilla to GitLab, etc. Some issues with GitLab, such as license selection options that are inconsistent with Eclipse policy.
 +
** Discussion of project migration to GitLab. Go into the EclipseFdn group to enter an issue. Migration issues must be entered here, not Bugzilla. EclipseFdn group is for the Foundation as a whole, and the Eclipse group is for projects specifically.
 +
** Discussed retirement of some products currently in use, like Bugzilla and Gerritt. No immediate plans are in place although it is desirable.
 +
 
 +
 
 +
==== 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]
 +
** 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 ====
 +
 
 +
* 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.
  
== Action Items  ==
+
* Parallel IP (Jonah)
* none
+
** 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.
  
== Past Meetings ==
 
  
=== January 9, 2020 ===
+
==== January 9, 2020 ====
 
* Welcome Noopur to the AC
 
* Welcome Noopur to the AC
* No other topics so the meeting early
+
* No other topics so end the meeting early
  
=== Archive ===
+
==== Archive ====
 
Older meeting notes can be found in [[Architecture Council/Meetings/Archive]].
 
Older meeting notes can be found in [[Architecture Council/Meetings/Archive]].
 
[[Category:Architecture_Council_Meeting_Minutes]]
 
[[Category:Architecture_Council_Meeting_Minutes]]

Latest revision as of 12:15, 11 January 2024


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

  • Welcome new members.
  • New member candidates (Wayne)

Action Items

  • n/a

Upcoming Meetings

January 11, 2024

  • PMI Requirement and GitHub Releases (Gunnar/Kai)
    • Gunnar reconfirmed that the EDP does not require the use of a particular technology/solution but defines requirements.
    • As such the use of PMI is to fulfill the documentation requirement.
    • This documentation requirement can also be fulfilled by GitHub releases.
    • Developers don't like typing information twice
    • Gunnar will get final confirmation from EMO.
  • Jay Jay shared the news of Amazon joining the Eclipse Foundation.

May 11, 2023

  • Update from EMO (Wayne/Gunnar)
  • Infrastructure Update (Denis)
  • Backlog

Backlog

(Please add agenda items/topics for discussion here.)

  • Welcome new members.
  • New member candidates (Wayne)
  • Where will we migrate the Arch Council content to when the wiki is retired?

Action Items

  • n/a

Past Meetings

Apr. 13, 2023

  • Welcome new members
    • Heiko Klare
  • Update from EMO (Wayne/Gunnar)
  • Infrastructure Update (Denis)
    • None
  • Jay asked about whether or not we should get a Slack/Mattermost/Discord/Gitter/Matrix, etc. channel.
  • Action Items
    • Wayne will share some links with relevant blog posts from Mike about the cyber resiliency act, etc. DONE (see above)
    • Wayne will dig into the license questions about transitive dependencies.
    • Jay will look into getting a Slack channel for the council.

Dec. 8, 2022

  • GitHub Releases and Milestones as official location for projects to publish release intentions and releases. See in part https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1906
    • Role of PMI, lot's projects just pointing to GitHub info.
    • Need to ask: why is PMI showing this information, i.e. is it still necessary?
    • IP team uses upcoming release dates to prioritize queue
    • EMO will reflect on what's possible here (eg., just pull info from GitHub)
  • 1.0 Versions of a project
    • Are they still special? Handbook talks a lot about it in context with Graduation Review
    • A Progress Review within last twelve months is sufficient
    • No extra PMC vote necessary for the first release, just check the project has done a progress review in the last twelve months
    • Specs are different, they still require a release review for every release
  • ECA and GitHub email address don't match
    • Issue is know by EMO, hope to address that in the next year
    • If it's just a comma, just merge the PR.

Oct. 25, 2022

  • Eclipse.org and project website; new proposal will be made in the coming weeks

July 14, 2022

  • n/a
  • will skip the August call

June 9, 2022

  • Wayne asked for feedback about IP policy changes
  • Q&A round IP policy changes


May 12, 2022

  • Infrastructure Update (Denis)
  • Feedback from moving off of Bugzilla/Gerrit stack is positive overall
  • Discussion about wish for some projects to be able to use Eclipse project PGP keys to sign in GitHub actions (eg having private keys registered as secrets on related GitHub repo).


Apr. 14, 2022

  • IP Policy Update (Mike)
  • Update from EMO (Wayne/Gunnar)
  • Infrastructure Update (Denis)
  • Backlog


Mar. 10, 2022

  • Wayne raises awareness that mentoring is not working
    • small number of mentors mentoring majority of projects
    • mentors don't tend to install themselves into the projects (eg., join project's mailing list)
    • It looks like it's easier for people to just contact EMO directly because they already have a relationship with EMO
  • Gunnar shared feedback that mentorship is pull not push, i.e. installing into projects seems like a new requirement
  • Ivar asked if there is some documentation/description of what's expected from mentors
    • looks like there isn't
  • Mickael raised the idea that mentorship should need to become optional because EMO is doing a good job at onboarding and helping projects.
    • As an alternative, Gunnar recommended to foster building relationships between projects and their PMC (eg., a welcome/intro email)
  • Another idea discusses was that EMO assesses during progress review if projects need help and request mentor


Nov. 11, 2021

  • Welcome Daimler to the AC
  • IT Update from Denis
    • Big connectivity improvements coming (10GBit), rate limiting will still be in place
    • Jenkins stability issues continue
    • Lot's of deprecation to legacy services (MediaWiki, Bugzilla, Forums); process to follow; no final shutdown date yet
  • Jens Raimann shared feedback from Community Day
    • Community (new projects) is struggling with CI - what is there, which one to use
    • Jonah: only two official options - GitHub actions and Jenkins


Oct. 14, 2021

  • No updates since Sept.
  • Mickael started to use IP tools and noticed that PMC approval is no longer mandatory for using a dependency.
    • Wayne confirmed this is the new flow.
    • PMC still involved in review process.
    • PMC can re-add requirement to review every single dependency if they want to.
  • Jonah gave an update to Jar signing that's coming to the Simultaneous release.
    • The important requirement is signing, the specific implementation should support common ways.
    • Jar signing is no longer the only option, GPG signing will be possible too.
    • Feedback via Planning Council rep.
    • Eclipse Foundation investigating web of trust with regards to GPG keys


Sept. 9, 2021

  • Welcome back after summer break!
  • EMO Update (Wayne)
    • EF is CVE issuing authority and Eclipse projects becoming more and more a target of security researchers, specifically runtime related projects
    • vulnerability submitted via Bugzilla with limited visibility scope; to be published after three months
    • trying to engage developers on vulnerability
    • OSS Review Toolkit - https://github.com/oss-review-toolkit
    • Rethinking the IP database
      • still tracks review work and cryptography
  • GitLab maintainer permission delegation - see https://www.eclipse.org/lists/eclipse.org-architecture-council/msg04400.html (Jonah)
  • EMO switch from Bugzilla to GitLab (Wayne)
    • Trying to do all of EMO interaction via GitLab.
    • Problem arise if a developer never signed up with GitLab yet. Needs discussion with IT team.
    • Committer id is used in GitLab, which is not great.
  • Progress review reviews (Wayne)
    • Going well, some unveiling IP issues, which are addressed along the way.

June 10, 2021

  • EMO Update (Wayne)
    • Looking for opportunities to get EMO out of the way (eg, eliminate CQ approval requirement for PMC, eliminate IPzilla, etc.)
    • Expect to come up with more specific items to AC for feedback and review
    • Started initiating progress reviews with projects directly
    • Starting to capture OSS and IP information beyond source code (eg., images, binary files, docs, etc.) to make it easier for adopters
    • Looking at OpenChain: getting certified, become a leader in that area.
    • Also looking at OSS Review Toolkit
  • Q/A
    • Kay gave feedback that automated generation of NOTICE file is needed. Currently lots of manual work.


Mar. 11, 2021

  • 'Signed Off By' requirements (from cross platform list topic, https://bugs.eclipse.org/558653)
    • Work started at the Board to revitalize discussion. There is sufficient evidence out there that it should be possible to remove the requirement.
    • No ETA yet. Discussion requires convincing lawyers.
    • Architecture Council unanimously agrees that this needs to go
  • Permission handling in GitHub - trust vs. control
    • three teams created - committers, leads and collaborators
    • leads do not get full admin permissions; webmasters would like to stay in control to avoid mistakes and keep maintenance costs (level of paranoia)
    • automatic checks limited by gaps in GitHub API
    • process in place for requesting admin permissions
  • Progress Reviews: plans and ETA for availability on PMI
    • prioritized for Q2/2021
  • EMO moving from Bugzilla to GitLab
    • Experimenting with automatic reviews of third-party content via GitLab (purposely avoiding using the term "CQ") (here and here)
  • Eliminate release reviews (except for specification projects)
    • Consider having EMO initiate annual progress reviews
      • Give projects a one-month warning
      • EMO validates IP Log, legal documentation
      • PMC validates conformance to EDP, open source rules of engagement
      • Architecture Council reviews results
    • Benefits
      • Take the responsibility away from projects; one fewer thing to think about
      • Spread the load
      • Identify and terminate dead projects
      • Identify and connect with projects that aren't engaged in the process
    • Concerns
      • ~400 projects
    • Help/input of AC is needed - how can we help to improve the situation and reduce burden on committers as well as EMO (reviewing all 400 projects each year)
  • CVE Policy
    • Security Team, EMO more aggressively create CVEs (with or without project team assistance)
    • Projects need to understand that they have to collaborate.
    • Work with reporter on CVE if projects don't participate
    • Involve AC when there is disagreement between reporter and project on CVE
    • Nuclear option if project is unwilling to participate and collaborate with community

Feb. 11, 2021

  • Infrastructure
    • Kubernetes cluster update not flawless, still monitoring and investigating
    • Mail server upgrade under way. Mailing lists should deliver more reliably now.
    • Gerrit upgrade pending.
  • EMO Update
  • Could Micro/Service Release skip the review process?
    • See this issue and this MicroProfile googlemail discussion.
    • Any specification release (major, minor, service) can potentially include substantial new IP hence the requirement for a review.
    • Short answer: no, a new revision of the specification process is necessary
      • new revision 1.3 would be necessary (requires Board review and approval)
      • concept of Errata (https://github.com/EclipseFdn/EFSP/issues/32) but introducing a fourth thing is too much; potentially consolidating/categorizing with service release type preferred


January 14, 2021

  • Mailing Lists
    • Some mail is currently lost. There is a plan to fix this but it potentially ruins the mailing list experience.
    • Please follow https://bugs.eclipse.org/541216
  • Bringing single developer projects into projects
    • Experience shared from Jonah that it took a very long time to get a project into Eclipse and ultimately was a painful experience.
    • Value seems to be the challenging. Not everyone is looking for process. This may be a social issue rather than a technical one.
    • Examples: PyDev, Embedded CDT
    • There are successful single person projects. They came to Eclipse because the creator of those projects realized a value.
    • Working Groups are a model that could help here - setting up a working group to collect "money" from multiple members to sponsor development for such a single developer project.
  • Future of Orbit / Consuming Maven artifacts "on the fly"
    • See discussion here: https://www.eclipse.org/lists/orbit-dev/msg05422.html
    • Quality of OSGi metadata is a concern. Jonah raised his recent JAXB experience with the EPP. Potential for lots of errors if projects start distributing Maven artifacts of same version with different OSGi metadata
    • Orbit is slowing down projects (IP, process, work). Slowdown is especially noticeable in early/innovate phase. The new functionality is useful from that perspective.
    • Need to convince projects that there is a long term value (maintenance costs) in having proper metadata in Orbit.
    • Important point: Orbit is only relevant if you are consuming from a p2 repository.
    • Orbit is not a solution as long as there are bad practices/patterns:
      • don't hard code versions in feature.xml
      • if you have to do: update frequently
      • provide alternate features for adopters without any third-party references
      • don't use Require-Bundle, use useful imports
    • If upstream Maven artifact already provides proper metadata then it shouldn't be a problem consuming it as is.
    • Work with upstream improving the metadata where possible.
    • It's at the discretion of the projects and PMCs to decide. One possible recommendation could be to allow it for artifacts with good OSGi metadata already but don't allow "on-the-fly" generation.

November 12, 2020

  • Moment of silence for Dani Megert
  • EMO Update
    • Lots of ideas coming out of EclipseCon!
    • Wayne demonstrated a GitLab prototype for a new IPZilla implementation. See http://gitlab.eclipse.org/eclipsefdn/iplab.
    • Denis pointed out that this is a great idea from an infra perspective since IpZilla has some special requirements on the infra side.
  • EclipseCon Thoughts
    • Feeling that the conference was great.
    • Content was good.
    • Swapcard was nice.
  • Infrastructure Update
    • Stood up a second Kubernetes cluster to better support services. This installation is also an OKD cluster.
    • Migrating projects to GitLab. Some subtle issues with migrating Bugzilla issues. Hopefully will migrate more projects off of Bugzilla to GitLab, etc. Some issues with GitLab, such as license selection options that are inconsistent with Eclipse policy.
    • Discussion of project migration to GitLab. Go into the EclipseFdn group to enter an issue. Migration issues must be entered here, not Bugzilla. EclipseFdn group is for the Foundation as a whole, and the Eclipse group is for projects specifically.
    • Discussed retirement of some products currently in use, like Bugzilla and Gerritt. No immediate plans are in place although it is desirable.


October 8, 2020

Note that the meeting started late because of Zoom now requiring a moderator passcode.

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.

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.

Back to the top