Skip to main content
Jump to: navigation, search

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

(Backlog)
(Past Meetings)
Line 54: Line 54:
 
** engage IP team as early as possible
 
** engage IP team as early as possible
  
==== Incubation ====
+
* Incubation and EPP
 
+
** We had incubating problems before
 
+
** Feature must be branded with incubating
* 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
 
** 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??
+
* 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
 
** PMC can define what stable means
** Instead: don't screw your adopters
+
** Wayne will take to the IP adviser community to discuss future of incubation
* Jonah
+
** For transparency it may be helpful to keep this flag; projects are learning; there might be IP problems in the project; some companies care
** get lsp4j to graduate
+
** We need the motivation to move out of incubation; The package owners have the motivation to push the incubating projects
* Alex
+
** No need to have "incubating" or "incubation" in the download/file name; just the about dialog and feature name is enough
** 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 ====
 
==== May 14, 2020 ====

Revision as of 11:09, 9 July 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

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