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

Revision as of 12:29, 11 June 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.)

• The majority of EPP packages are currently slated to contain incubating components in IDE 2020-06. There is a question about whether the downloadable file name must contain "incubating" or simply mention this in its description.
  • Argument for: our EPP packages are "opinionated" and aimed at end-users, the state of the included projects and technologies is paramount
  • Projects see leaving incubation as a cost without any obvious value

Action Items

• none

Past Meetings

June 11, 2020

Maybe we need a summary of that meeting -- I just tried to capture what has been said

Participants

• Gunnar Wagenknecht
• Michael Scharf
• Martin Lippert
• Jonah Graham
• Kai Hudalla
• Wayne Beaton
• Mikael Barbero
• Alexander Kurakov
• Jeff Jhonston
• Dani Megert
• Dimitry Kornilov
• Torkind
• Jay Jay Billings

IP

• Wane:
  • change: release review only required once a year
  • IP policy changes
  • how to document the changes
  • works out better communication strategy
  • no more piggyback use
  • 3rd party license
  • no type b due diligence
  • "clearly defined" (CD) has license information
  • reduced engagement with IP team
• Kai:
  • clearly defined is hard to use
• Wane:
  • hard to put numbers on things
  • use CD to just extract license info
  • tool to automate as much as possible
  • struggling how to capture this (how to use CD data)
• Kai:
  • unclear how to use it
  • no pointe in project handbook t the tool
• Wane
  • use the tool to capture the intent of the IP policy changes
• ALexander
  • can I use the tool
• Gunnar
  • should the project capture the output of the tool?
• Wane
  • good idea!
  • add dependency file with the output of the tool
  • IP log used for tracking -* we are no longer tracking
• Kai:
  • is it a good tool for tracking
  • want to see who is affected
• Wane
  • tries to put documentation about the tool
  • Gunar
  • can PMCs help
• Wane
  • once we have proper doc PMC can help out
• Kai:
  • as soon as anybody casts a vote in the PMC the IP team considers this consent?
  • have not seen any CQ be not approved
• Wane:
  • 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
• Gunnar:
  • occasionally +1 does not work
  • , therefore, we use in in the comments
• Wane
  • there are some problems with the tool
• Kai
  • can we agree that if any of the PMC hits OK then it is OK
• Wane
  • one member can approve it, if he can do it with confidence then it is OK
  • no "yes but.."
• Gunnar
  • technology we operate like this
• Kai
  • we were told to have a vote
• Wane
  • was true at one time when it was far more formal
  • change was not communicated
  • I need confidence that it meets the definition
• Torkind
  • Science does it similar to technology
• Gunnar
  • with a growing base of projects it becomes harder to be aware of all codebases
  • challenge: we as PMC trust project leads -* it is not always easy
  • "works with" is one part
  • I want separation
• Kai:
  • do we have knowledge about build dependencies
• Wane
  • would agree but layers don't
  • "works with" for testing JUnit -* who cares?
  • OS under apache -* chances are we have already information
• Kai:
  • how to you know it is a "works with"?
• Wane
  • some people use "works with" as a workaround
• Kai
  • why don't do we need CQs for 3rd party?
• Wane
  • ideally we run the tool 700 are fine and 3 have no license
  • IP team says OK if it is a "works with"
  • the more complete the coverage is the less engagement with IP team we need
  • we could start doing this now
• Kai
  • I want the IP team come to PMC and ask if it is a prereq of a "works with"
  • should be the standard way
  • Only in the few cases the IP team should ask
  • just approve any works with
• Wane
  • We need the PMC to clarify if it is a "works with"
• Wane
  • only if the content requires further review a CQ has to be created
• Kai
  • should the committer or the IP team run the tool?
• Wane
  • my team doing more work
• Kai
  • not sure
• Wane
  • ideally, the tool could automatically figure it out
• Gunnar
  • IP team running the tool assumes the IP team understands the project structure
  • they should not have a deep technical understanding of the team
  • part of this work has to be done by the project
• Wane
  • he missed a yarn dependency -* knowing his tool
  • We rely on project understanding the dependency
  • we still need an IP log
• Kai
  • list is what is generated by maven
  • is anybody validating the IP log
• Wane
  • I do and I run them too
  • but 1 week before the release** may be late
• Kai
  • if you run the tool on list of dependencies
  • we do not need any CQ anymore
• Alexander
  • we don't need the CQ as we run the tool
  • but the project has to run the tool to see the output
  • example: new JUnit version 1 week before the release
  • licensing is not fast for the latest version
• Wane
  • that is the case you need to engage the IP team with a CQ
  • CQ the ticket to investigate the source
  • 1 CQ for 700 npm dependencies
• Kai
  • spring new miner version every few months
  • still have to create CQs
• Wane
  • we need it**only* on releases
  • forget intermediate version
  • I don't care when a version is only used during development
  • the release version what we care about
  • engage IP team as early as possible
  • CD adds unknown libs** 4 weeks later it may know the answer
• Gunnar
  • we also use IPzilla
• Wane
  • IP team updates CD data
  • opportunity to reduce paperwork with CQ
  • opportunity on test and work only

Incubation

• Jonah
  • do we need to incubate every EPP package
  • number of incubating
  • lsp4J
• Gunnr
  • we had incubating problems before
  • feature must be branded with incubating
  • EPP needs to declare that
• Wane
  • why is it still incubating??
• Jonah
  • lsp4J does not have stable APIs
  • we won't have stable APIs
• Gunnar
  • challenge stable APIs
  • projects understand the requirement
  • API is a framework to support adopters
  • we need to clarify the wording -* have a sense for adoption support
  • every project defines its own rules
• Wane
  • PMC can define what stable means
  • Instead: don't screw your adopters
• Jonah
  • get lsp4j to graduate
• Alex
  • what is the benefit of marking as incubating
  • for the end user visible no need to label incubating
• Wane
  • will take to the IP adviser community
• Gunnar
  • incubation could contain IP problems
• Wane
  • leaning process
  • codebase is unstable
  • ideal: lear and after one release graduate
  • used to be some benefits ins trying in incubation
• Dani
  • makes sense to drop incubation
• Gunnar
  • for transparency it may be helpful -* some companies care
  • we need the motivation to move out of incubation
• Jonah
  • reality that is not the case
• Gunnar
  • wrong discussion** we are not Github
  • what is the benefit of incubation
• Dani
  • it is punishing the package
• Wane
  • the package owners have the motivation to push the incubating projects
  • upstream care about it
  • as consumer I want the API to be stable
• Gunnar
  • no need in the download name
  • enough in the about dialog
• Jonah
  • we are changing file names at the moment
  • the filename is `-incubation` is the current state
• Wane
  • don't change the file names
  • fix this by moving them out of incubation
  • keep the file name

Action item

• AC brings proposal on how we want to solve it and send it to IP advisor community

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.