Skip to main content
Jump to: navigation, search

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

m (Backlog)
Line 21: Line 21:
  
 
=== Past Meetings ===
 
=== Past Meetings ===
 +
 +
==== January 14, 2020 ====
 +
 +
* Mailing Lists
 +
** Some mail is currently lost. There is a plan to fix this but it potentially ruins the mailing list experience.
 +
** Please follow https://bugs.eclipse.org/541216
 +
 +
* Bringing single developer projects into projects
 +
** Experience shared from Jonah that it took a very long time to get a project into Eclipse and ultimately failed.
 +
** Value seems to be the challenging. Not everyone is looking for process. This may be a social issue rather than a technical one.
 +
** Examples: PyDev, Embedded CDT
 +
** There are successful single person projects. They came to Eclipse because the creator of those projects realized a value.
 +
** Working Groups are a model that could help here - setting up a working group to collect "money" from multiple members to sponsor development for such a single developer project.
 +
 +
* Feedback for Clearly Defined
 +
** Consider lowering the score required for ClearlyDefined (e.g. https://clearlydefined.io/definitions/maven/mavencentral/commons-codec/commons-codec/1.14 has score of 60 for license - another example is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=22912 which also has 60 score https://clearlydefined.io/definitions/maven/mavencentral/org.slf4j/slf4j-jdk14/1.7.30)
 +
** The scores look like Effective: 60/100 Breakdown Consistency: 15/15 Declared: 30/30 Discovered: 0/25 SPDX: 15/15 License texts: 0/15 <-- Added by Jonah
 +
 +
* Future of Orbit / Consuming Maven artifacts "on the fly"
 +
** See discussion here: https://www.eclipse.org/lists/orbit-dev/msg05422.html
 +
** Quality of OSGi metadata is a concern. Jonah raised his recent JAXB experience with the EPP. Potential for lots of errors if projects start distributing Maven artifacts of same version with different OSGi metadata
 +
** Orbit is slowing down projects (IP, process, work). Slowdown is especially noticeable in early/innovate phase. The new functionality is useful from that perspective.
 +
** Need to convince projects that there is a long term value (maintenance costs) in having proper metadata in Orbit.
 +
** Important point: Orbit is only relevant if you are consuming from a p2 repository.
 +
** Orbit is not a solution as long as there are bad practises/patterns:
 +
*** don't hard code versions in feature.xml
 +
*** if you have to do: update frequently
 +
*** don't use Require-Bundle, use useful imports
 +
  
 
==== November 12, 2020 ====
 
==== November 12, 2020 ====
Line 41: Line 70:
 
** Discussion of project migration to GitLab. Go into the EclipseFdn group to enter an issue. Migration issues must be entered here, not Bugzilla. EclipseFdn group is for the Foundation as a whole, and the Eclipse group is for projects specifically.
 
** Discussion of project migration to GitLab. Go into the EclipseFdn group to enter an issue. Migration issues must be entered here, not Bugzilla. EclipseFdn group is for the Foundation as a whole, and the Eclipse group is for projects specifically.
 
** Discussed retirement of some products currently in use, like Bugzilla and Gerritt. No immediate plans are in place although it is desirable.
 
** Discussed retirement of some products currently in use, like Bugzilla and Gerritt. No immediate plans are in place although it is desirable.
 +
  
 
==== October 8, 2020 ====
 
==== October 8, 2020 ====

Revision as of 12:58, 14 January 2021


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

January 14, 2020

  • Mailing Lists
    • Some mail is currently lost. There is a plan to fix this but it potentially ruins the mailing list experience.
    • Please follow https://bugs.eclipse.org/541216
  • Bringing single developer projects into projects
    • Experience shared from Jonah that it took a very long time to get a project into Eclipse and ultimately failed.
    • Value seems to be the challenging. Not everyone is looking for process. This may be a social issue rather than a technical one.
    • Examples: PyDev, Embedded CDT
    • There are successful single person projects. They came to Eclipse because the creator of those projects realized a value.
    • Working Groups are a model that could help here - setting up a working group to collect "money" from multiple members to sponsor development for such a single developer project.
  • Future of Orbit / Consuming Maven artifacts "on the fly"
    • See discussion here: https://www.eclipse.org/lists/orbit-dev/msg05422.html
    • Quality of OSGi metadata is a concern. Jonah raised his recent JAXB experience with the EPP. Potential for lots of errors if projects start distributing Maven artifacts of same version with different OSGi metadata
    • Orbit is slowing down projects (IP, process, work). Slowdown is especially noticeable in early/innovate phase. The new functionality is useful from that perspective.
    • Need to convince projects that there is a long term value (maintenance costs) in having proper metadata in Orbit.
    • Important point: Orbit is only relevant if you are consuming from a p2 repository.
    • Orbit is not a solution as long as there are bad practises/patterns:
      • don't hard code versions in feature.xml
      • if you have to do: update frequently
      • don't use Require-Bundle, use useful imports


November 12, 2020

  • Moment of silence for Dani Megert
  • EMO Update
    • Lots of ideas coming out of EclipseCon!
    • Wayne demonstrated a GitLab prototype for a new IPZilla implementation. See http://gitlab.eclipse.org/eclipsefdn/iplab.
    • Denis pointed out that this is a great idea from an infra perspective since IpZilla has some special requirements on the infra side.
  • EclipseCon Thoughts
    • Feeling that the conference was great.
    • Content was good.
    • Swapcard was nice.
  • Infrastructure Update
    • Stood up a second Kubernetes cluster to better support services. This installation is also an OKD cluster.
    • Migrating projects to GitLab. Some subtle issues with migrating Bugzilla issues. Hopefully will migrate more projects off of Bugzilla to GitLab, etc. Some issues with GitLab, such as license selection options that are inconsistent with Eclipse policy.
    • Discussion of project migration to GitLab. Go into the EclipseFdn group to enter an issue. Migration issues must be entered here, not Bugzilla. EclipseFdn group is for the Foundation as a whole, and the Eclipse group is for projects specifically.
    • Discussed retirement of some products currently in use, like Bugzilla and Gerritt. No immediate plans are in place although it is desirable.


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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.