Skip to main content
Jump to: navigation, search

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

m (Incubation)
m
 
(11 intermediate revisions by 3 users not shown)
Line 11: Line 11:
 
=== Backlog ===
 
=== Backlog ===
 
(Please add agenda items/topics for discussion here.)
 
(Please add agenda items/topics for discussion here.)
* The [https://git.eclipse.org/r/#/c/163123/ majority] of EPP packages are currently slated to contain incubating components in IDE 2020-06. There is a [https://www.eclipse.org/lists/epp-dev/msg05760.html 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 ===
 
=== Action Items ===
 
* none
 
* none
 +
  
 
=== Past Meetings ===
 
=== Past Meetings ===
==== June 11, 2020 ====
 
  
===== Participants =====
+
==== October 8, 2020 ====
  
 +
Note that the meeting started late because of Zoom now requiring a moderator passcode.
  
* Gunnar  Wagenknecht
+
* No specific agenda items
* Michael Scharf
+
* Topics started with a discussion on Eclipse Forum vs. GitHub Discussions.See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567232
* Martin Lippert
+
* Jonah Graham
+
* Kai Hudalla
+
* Wayne Beaton
+
* Mikael Barbero
+
* Alexander Kurakov
+
* Jeff Jhonston
+
* Dani Megert
+
* Dimitry Kornilov
+
* Torkind
+
* Jay Jay Billings
+
  
===== IP =====
+
==== 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]
  
* 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
 
  
 +
==== July 9, 2020 ====
  
==== Incubation ====
+
* We'll cancel the August meeting (summer break)
 +
* No other topics; meeting ended early
  
  
* Jonah
+
==== June 11, 2020 ====
** do we need to incubate every EPP package
+
 
** number of incubating
+
* EMO Update
** lsp4J
+
** Reminding projects that a release review required only once per year; starting to push back on projects requesting too often
* Gunnr
+
** Working on a better communication strategy
** we had incubting problems before
+
** Reminder that piggyback are not used anymore
** feature must be branded with incubating
+
 
 +
* 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
 
** EPP needs to declare that
* Wane
+
** One challenge is stable APIs; API is a framework to support adopters; Every project defines its own rules
** why is it still incubating??
+
** PMC can define what stable means
* Jonah
+
** Wayne will take to the IP adviser community to discuss future of incubation
** lsp4J does not habe stable APIs
+
** 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 won't have stabe APIs
+
** We need the motivation to move out of incubation; The package owners have the motivation to push the incubating projects
* Gunnar
+
** No need to have "incubating" or "incubation" in the download/file name; just the about dialog and feature name is enough
** 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 community
 
  
 
==== 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 267: Line 99:
  
 
* Infrastructure Update
 
* Infrastructure Update
** New firewalls were put in place early May. They har redundant and part of the program to reduce single-point-of-failures.
+
** New firewalls were put in place in early May. They har redundant and part of the program to reduce single-point-of-failures.
** Thanks to a lot help we are clear for a long overdue Gerrit update. The sandbox is running and an upgrade is planned for after the 2020-06 release. Please prepare as Gerrit will come with a new UI/UX.
+
** Thanks to a lot of help we are clear for a long-overdue Gerrit update. The sandbox is running and an upgrade is planned for after the 2020-06 release. Please prepare as Gerrit will come with a new UI/UX.
 
** Jonah asked if we are on the latest version of Bugzilla. Denis confirmed we are on the latest official release.
 
** Jonah asked if we are on the latest version of Bugzilla. Denis confirmed we are on the latest official release.
*** There is an edit extension 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 289: Line 121:
 
* EMO Update
 
* EMO Update
 
** Wayne thanked for feedback to IP tooling received so far. It's helpful. Please provide more feedback if you can.
 
** Wayne thanked for feedback to IP tooling received so far. It's helpful. Please provide more feedback if you can.
** Next steps are to make a repository available and bring tooling to the Eclipse Dash project and make it available.
+
** The Next steps are to make a repository available and bring tooling to the Eclipse Dash project and make it available.
 
** As of today, CQs for known license sources of 3rd party content is no longer required.
 
** As of today, CQs for known license sources of 3rd party content is no longer required.
  
Line 300: Line 132:
  
 
* Anonymous contributions (Jonah)
 
* Anonymous contributions (Jonah)
** A GitHub account as contributor is ok, it can be traced back to an individual.
+
** A GitHub account as a contributor is ok, it can be traced back to an individual.
 
** An ECA must be signed in any case. This requires a real email address and this is sufficient.
 
** An ECA must be signed in any case. This requires a real email address and this is sufficient.
 
** EMO expectation to committers is to monitor and catch/report shenanigans.
 
** EMO expectation to committers is to monitor and catch/report shenanigans.
** The handbook wording needs an updated and will investigated separately.
+
** The handbook wording needs an updated and will be investigated separately.
  
 
* Parallel IP (Jonah)
 
* Parallel IP (Jonah)
 
** Wayne explained that Parallel IP is now the standard way of doing things at Eclipse.
 
** Wayne explained that Parallel IP is now the standard way of doing things at Eclipse.
** The code can go in early but a release needs to wait for full review.
+
** The code can go in early but a release needs to wait for a full review.
** It's important to put release records 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.
  
  

Latest revision as of 11:22, 8 October 2020


This page captures meeting notes of the Eclipse Architecture Council. Please add topics for the next call to the backlog, but not during a call!

Standing Agenda

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

Backlog

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

  • ...

Action Items

  • none


Past Meetings

October 8, 2020

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

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