Skip to main content
Jump to: navigation, search

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

m (June 11, 2020)
m (spelling)
Line 47: Line 47:
 
** works out better communication strategy
 
** works out better communication strategy
 
** no more piggyback use
 
** no more piggyback use
** 3rd party licence
+
** 3rd party license
** no type b due dilligence
+
** no type b due diligence
 
** "clearly defined" (CD) has license information
 
** "clearly defined" (CD) has license information
 
** reduced engagement with IP team
 
** reduced engagement with IP team
Line 66: Line 66:
 
** can I use the tool
 
** can I use the tool
 
* Gunnar
 
* Gunnar
** should project capture the output of the tool?
+
** should the project capture the output of the tool?
 
* Wane
 
* Wane
 
** good idea!
 
** good idea!
Line 120: Line 120:
 
** how to you know it is a "works with"?
 
** how to you know it is a "works with"?
 
* Wane
 
* Wane
** some people use "works with" as workaround
+
** some people use "works with" as a workaround
 
* Kai
 
* Kai
 
** why don't do we need CQs for 3rd party?
 
** why don't do we need CQs for 3rd party?
Line 146: Line 146:
 
** ideally, the tool could automatically figure it out
 
** ideally, the tool could automatically figure it out
 
* Gunnar
 
* Gunnar
** IP team running the tool assumes IP team understands the project structure
+
** IP team running the tool assumes the IP team understands the project structure
 
** they should not have a deep technical understanding of the team
 
** they should not have a deep technical understanding of the team
 
** part of this work has to be done by the project
 
** part of this work has to be done by the project
 
* Wane
 
* Wane
 
** he missed a yarn dependency -* knowing his tool
 
** he missed a yarn dependency -* knowing his tool
** we rely on project understanding the dependency
+
** We rely on project understanding the dependency
 
** we still need an IP log
 
** we still need an IP log
 
* Kai
 
* Kai
Line 180: Line 180:
 
** the release version what we care about
 
** the release version what we care about
 
** engage IP team as early as possible
 
** engage IP team as early as possible
** CD adds unknown libs** 4 weaks later it may know the answer
+
** CD adds unknown libs** 4 weeks later it may know the answer
 
* Gunnar
 
* Gunnar
 
** we also use IPzilla
 
** we also use IPzilla
Line 196: Line 196:
 
** lsp4J
 
** lsp4J
 
* Gunnr
 
* Gunnr
** we had incubting problems before
+
** we had incubating problems before
 
** feature must be branded with incubating
 
** feature must be branded with incubating
 
** EPP needs to declare that
 
** EPP needs to declare that
Line 202: Line 202:
 
** why is it still incubating??
 
** why is it still incubating??
 
* Jonah
 
* Jonah
** lsp4J does not habe stable APIs
+
** lsp4J does not have stable APIs
** we won't have stabe APIs
+
** we won't have stable APIs
 
* Gunnar
 
* Gunnar
** challange stable APIs
+
** challenge stable APIs
 
** projects understand the requirement
 
** projects understand the requirement
** API is a framework to support adopers
+
** API is a framework to support adopters
** we need to clarify the wording -* have a sence for adoption support
+
** we need to clarify the wording -* have a sense for adoption support
 
** every project defines its own rules
 
** every project defines its own rules
 
* Wane
 
* Wane
** PMC can define what stable mean
+
** PMC can define what stable means
** instead: dont screw your adopters
+
** Instead: don't screw your adopters
 
* Jonah
 
* Jonah
 
** get lsp4j to graduate
 
** get lsp4j to graduate
 
* Alex
 
* Alex
** what is the benifit of marking as incubating
+
** what is the benefit of marking as incubating
** for end user visible no need to label icubading
+
** for the end user visible no need to label incubating
 
* Wane
 
* Wane
** will take to the IP adviser commity
+
** will take to the IP adviser community
 
* Gunnar
 
* Gunnar
** incubarion could contain IP problems
+
** incubation could contain IP problems
 
* Wane
 
* Wane
** incubatin means
+
** leaning process
** leaning proess
+
** codebase is unstable
** codbase is unstable
+
 
** ideal: lear and after one release graduate
 
** ideal: lear and after one release graduate
** used to be some benefits ins taying in incubation
+
** used to be some benefits ins trying in incubation
 
* Dani
 
* Dani
 
** makes sense to drop incubation
 
** makes sense to drop incubation
 
* Gunnar
 
* Gunnar
 
** for transparency it may be helpful -* some companies care
 
** for transparency it may be helpful -* some companies care
** we need motivation to move out of incubarion
+
** we need the motivation to move out of incubation
 
* Jonah
 
* Jonah
 
** reality that is not the case
 
** reality that is not the case
 
* Gunnar
 
* Gunnar
** wrong discussion** we are not github
+
** wrong discussion** we are not Github
** what is the benefit of incubarion
+
** what is the benefit of incubation
 
* Dani
 
* Dani
 
** it is punishing the package
 
** it is punishing the package
 
* Wane
 
* Wane
** the package owners have motivation to push the incubating projects
+
** the package owners have the motivation to push the incubating projects
** upstram care about it
+
** upstream care about it
** as consmer I want the API to be stable
+
** as consumer I want the API to be stable
 
* Gunnar
 
* Gunnar
 
** no need in the download name
 
** no need in the download name
Line 249: Line 248:
 
* Jonah
 
* Jonah
 
** we are changing file names at the moment
 
** we are changing file names at the moment
** the filame is `-incubarion` is current state
+
** the filename is `-incubation` is the current state
 
* Wane
 
* Wane
 
** don't change the file names
 
** don't change the file names
Line 260: Line 259:
 
==== May 14, 2020 ====
 
==== May 14, 2020 ====
 
* EMO Update
 
* EMO Update
** Wayne asked one more time for feedback to the IP tool.
+
** 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 265:
  
 
* 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 which Denis was unable to get to work in our Bugzilla instance.
+
*** 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 house keeping the committers is a good idea.
+
** 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 287:
 
* 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 298:
  
 
* 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 in to PMI as early as possible. The IP team will use the dates to prioritize their work.
+
** 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 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.

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