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"
(→Backlog) |
|||
Line 19: | Line 19: | ||
=== Past Meetings === | === Past Meetings === | ||
+ | ==== June 11, 2020 ==== | ||
+ | |||
+ | ===== 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 requierd once a year | ||
+ | ** ip policiy changes | ||
+ | ** how to document the changes | ||
+ | ** works out better communication strategy | ||
+ | ** no more piggy back use | ||
+ | ** 3rd party licence | ||
+ | ** no type b due dilligence | ||
+ | ** "clearly defined" (CD) has linecne infromation | ||
+ | ** reduced engagement with IP team | ||
+ | * Kai: | ||
+ | ** clearly defined is hard to use | ||
+ | * Wane: | ||
+ | ** hard to put nubmer on things | ||
+ | ** use CD to just extract linence 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 intend of the IP polocy changes | ||
+ | * ALexander | ||
+ | ** can I use the tool | ||
+ | * Gunnar | ||
+ | ** should projects capture outupt of the tool? | ||
+ | * Wane | ||
+ | ** good idea! | ||
+ | ** add dependency file with output of tool | ||
+ | ** IP log used for tracking -* we are no longer tracking | ||
+ | * Kai: | ||
+ | ** is it a good tool for trackiong | ||
+ | ** 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 cast a vote in the PMC the IP team considers this consent? | ||
+ | ** have not seen any CQ to be not apporoved | ||
+ | * Wane: | ||
+ | ** IP tream needs to know it makes sense | ||
+ | ** PMC can discusse on th CQ, but as soon as someone adds a +1 they jump in | ||
+ | * Gunnar: | ||
+ | ** occationally +1 does not work | ||
+ | ** there fore 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 menber can approve it, if he can doe 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 growing base of projects it becomes harder to be aware of all code bases | ||
+ | ** challange: we as PMC trust project leads -* it is not always eady | ||
+ | ** "works with" is one part | ||
+ | ** I want separation | ||
+ | * Kai: | ||
+ | ** do we have knowledge about build dependencies | ||
+ | * Wane | ||
+ | ** wpould agree -* loyers dont | ||
+ | ** "works with" for testing junit -* who cares? | ||
+ | ** OS under appache -* chances are we have already information | ||
+ | * Kai: | ||
+ | ** how to know it is a works with? | ||
+ | * Wane | ||
+ | ** some people use "works with" as workaound | ||
+ | * Kai | ||
+ | ** why don't do we need CQs for 3rd party? | ||
+ | * Wane | ||
+ | ** ideally we run the tool 700 ar fine and 3 have no licence | ||
+ | ** 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 committer of IP team run the tool? | ||
+ | * Wane | ||
+ | ** my team doing more work | ||
+ | * Kai | ||
+ | ** not sure | ||
+ | * Wane | ||
+ | ** ideally, tool could automatically figure it out | ||
+ | * Gunnar | ||
+ | ** IP team running the tool assumes IP team understands the project sturcture | ||
+ | ** they should not have deep technical understanding of the team | ||
+ | ** part of this work has to be done by the project | ||
+ | * Wane | ||
+ | ** he missed a yarn dependecncy -* knowing his tool | ||
+ | ** we rely on project understanding the dpendency | ||
+ | ** we still need a IP log | ||
+ | * Kai | ||
+ | ** list is what is generated by maven | ||
+ | ** is anybody validating the IP log | ||
+ | * Wane | ||
+ | ** I do and I run the 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 project has to run the tool to see the output | ||
+ | ** example: new junit version 1 week before the release | ||
+ | ** licesing 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 monts | ||
+ | ** still have to create CQs | ||
+ | * Wane | ||
+ | ** we need it**only* on releases | ||
+ | ** forget intermediate version | ||
+ | ** I don't care when 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 weaks later it may know the awnser | ||
+ | * Gunnar | ||
+ | ** we also use IPzilla | ||
+ | * Wane | ||
+ | ** IP team updates CD data | ||
+ | ** opportunity to reduce paperwork with CQ | ||
+ | ** opportunity on test and work onlu | ||
+ | |||
+ | |||
+ | ==== Incubation ==== | ||
+ | |||
+ | |||
+ | * Jonah | ||
+ | ** do we need to incubate every EPP package | ||
+ | ** number of incubating | ||
+ | ** lsp4J | ||
+ | * Gunnr | ||
+ | ** we had incubting problems before | ||
+ | ** feature must be branded with incubating | ||
+ | ** EPP needs to declare that | ||
+ | * Wane | ||
+ | ** why is it still incubating?? | ||
+ | * Jonah | ||
+ | ** lsp4J does not habe stable APIs | ||
+ | ** we won't have stabe APIs | ||
+ | * Gunnar | ||
+ | ** challange stable APIs | ||
+ | ** projects understand the requirement | ||
+ | ** API is a framework to support adopers | ||
+ | ** we need to clarify the wording -* have a sence for adoption support | ||
+ | ** every project defines its own rules | ||
+ | * Wane | ||
+ | ** PMC can define what stable mean | ||
+ | ** instead: dont screw your adopters | ||
+ | * Jonah | ||
+ | ** get lsp4j to graduate | ||
+ | * Alex | ||
+ | ** what is the benifit of marking as incubating | ||
+ | ** for end user visible no need to label icubading | ||
+ | * Wane | ||
+ | ** will take to the IP adviser commity | ||
+ | * Gunnar | ||
+ | ** incubarion could contain IP problems | ||
+ | * Wane | ||
+ | ** incubatin means | ||
+ | ** leaning proess | ||
+ | ** codbase is unstable | ||
+ | ** ideal: lear and after one release graduate | ||
+ | ** used to be some benefits ins taying in incubation | ||
+ | * Dani | ||
+ | ** makes sense to drop incubation | ||
+ | * Gunnar | ||
+ | ** for transparency it may be helpful -* some companies care | ||
+ | ** we need motivation to move out of incubarion | ||
+ | * Jonah | ||
+ | ** reality that is not the case | ||
+ | * Gunnar | ||
+ | ** wrong discussion** we are not github | ||
+ | ** what is the benefit of incubarion | ||
+ | * Dani | ||
+ | ** it is punishing the package | ||
+ | * Wane | ||
+ | ** the package owners have motivation to push the incubating projects | ||
+ | ** upstram care about it | ||
+ | ** as consmer 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 filame is `-incubarion` is 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 commity | ||
+ | |||
+ | |||
==== May 14, 2020 ==== | ==== May 14, 2020 ==== |
Revision as of 12:16, 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
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 requierd once a year
- ip policiy changes
- how to document the changes
- works out better communication strategy
- no more piggy back use
- 3rd party licence
- no type b due dilligence
- "clearly defined" (CD) has linecne infromation
- reduced engagement with IP team
- Kai:
- clearly defined is hard to use
- Wane:
- hard to put nubmer on things
- use CD to just extract linence 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 intend of the IP polocy changes
- ALexander
- can I use the tool
- Gunnar
- should projects capture outupt of the tool?
- Wane
- good idea!
- add dependency file with output of tool
- IP log used for tracking -* we are no longer tracking
- Kai:
- is it a good tool for trackiong
- 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 cast a vote in the PMC the IP team considers this consent?
- have not seen any CQ to be not apporoved
- Wane:
- IP tream needs to know it makes sense
- PMC can discusse on th CQ, but as soon as someone adds a +1 they jump in
- Gunnar:
- occationally +1 does not work
- there fore 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 menber can approve it, if he can doe 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 growing base of projects it becomes harder to be aware of all code bases
- challange: we as PMC trust project leads -* it is not always eady
- "works with" is one part
- I want separation
- Kai:
- do we have knowledge about build dependencies
- Wane
- wpould agree -* loyers dont
- "works with" for testing junit -* who cares?
- OS under appache -* chances are we have already information
- Kai:
- how to know it is a works with?
- Wane
- some people use "works with" as workaound
- Kai
- why don't do we need CQs for 3rd party?
- Wane
- ideally we run the tool 700 ar fine and 3 have no licence
- 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 committer of IP team run the tool?
- Wane
- my team doing more work
- Kai
- not sure
- Wane
- ideally, tool could automatically figure it out
- Gunnar
- IP team running the tool assumes IP team understands the project sturcture
- they should not have deep technical understanding of the team
- part of this work has to be done by the project
- Wane
- he missed a yarn dependecncy -* knowing his tool
- we rely on project understanding the dpendency
- we still need a IP log
- Kai
- list is what is generated by maven
- is anybody validating the IP log
- Wane
- I do and I run the 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 project has to run the tool to see the output
- example: new junit version 1 week before the release
- licesing 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 monts
- still have to create CQs
- Wane
- we need it**only* on releases
- forget intermediate version
- I don't care when 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 weaks later it may know the awnser
- Gunnar
- we also use IPzilla
- Wane
- IP team updates CD data
- opportunity to reduce paperwork with CQ
- opportunity on test and work onlu
Incubation
- Jonah
- do we need to incubate every EPP package
- number of incubating
- lsp4J
- Gunnr
- we had incubting problems before
- feature must be branded with incubating
- EPP needs to declare that
- Wane
- why is it still incubating??
- Jonah
- lsp4J does not habe stable APIs
- we won't have stabe APIs
- Gunnar
- challange stable APIs
- projects understand the requirement
- API is a framework to support adopers
- we need to clarify the wording -* have a sence for adoption support
- every project defines its own rules
- Wane
- PMC can define what stable mean
- instead: dont screw your adopters
- Jonah
- get lsp4j to graduate
- Alex
- what is the benifit of marking as incubating
- for end user visible no need to label icubading
- Wane
- will take to the IP adviser commity
- Gunnar
- incubarion could contain IP problems
- Wane
- incubatin means
- leaning proess
- codbase is unstable
- ideal: lear and after one release graduate
- used to be some benefits ins taying in incubation
- Dani
- makes sense to drop incubation
- Gunnar
- for transparency it may be helpful -* some companies care
- we need motivation to move out of incubarion
- Jonah
- reality that is not the case
- Gunnar
- wrong discussion** we are not github
- what is the benefit of incubarion
- Dani
- it is punishing the package
- Wane
- the package owners have motivation to push the incubating projects
- upstram care about it
- as consmer 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 filame is `-incubarion` is 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 commity
May 14, 2020
- EMO Update
- Wayne asked one more time for feedback to 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 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.
- 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 which 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 house keeping 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.
- 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 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 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 full review.
- It's important to put release records in to 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.