Page Comparison

TSC Meeting Zoom link

Meeting Recording

Meeting Chat File

Attendees & Representation. Please add your name to the attendance table below.

...

...

• LF Antitrust Policy

• Meeting note taker

• Welcome to new attendees

• Upcoming Events

  • CFP for Cloud Native eBPF Day Europe (CFP deadline February 21st)

• General Topics (cover as needed)

  • Use Cases

  • Roadmap

  • Project structure

    • Governance

      • Dave's list of topics:
        • Which parts of governance are per-repo vs independent of repo?  "governance" repo for repo-independent governance?  (comparable from FOSS Governance project: http://fossgovernance.org)
        • Licenses under which contributions can be accepted
        • Code of Conduct and reporting process
          • Linux Foundation Code of Conduct
        • Security vulnerability reporting process (comparables: governance/security-response-policies.md at main · confidential-computing/governance (github.com), ebpf-for-windows/SECURITY.md at master · microsoft/ebpf-for-windows (github.com))
          • LFx Security- https://docs.linuxfoundation.org/lfx/security/overview
        • Process for adding repos under github.com/l3af-project
        • Process for selecting maintainers of each repo
        • DCO (fyi: CLA vs. DCO: What's the difference? | Opensource.com)
          • EasyCLA- https://docs.linuxfoundation.org/lfx/easycla
        • Diversity & inclusion policies (comparable: governance/diversity-and-inclusion-policies.md at main · confidential-computing/governance (github.com))
          • Link to Linux Foundation Diversity & Inclusivity initiatives
        • Issue triage process - covered by Code of Conduct and Diversity & Inclusivity
        • Jason's list
          • Review feedback on https://github.com/l3af-project/l3afd/pull/16
          • Review feedback on https://github.com/l3af-project/l3af-arch/pull/10

    • Technical Steering Committee

...

• 2022 LFN Cross-Community Strategic Collaboration Event March 14-15

• 2022 LFN Developer & Testing Forum June

  • In Person (and virtual) in Porto Portugal, June 13 - 16
  • Registration is open: Registration Page
• CFP for Cloud Native eBPF Day Europe (CFP deadline February 21st)
• Governance:
  • Do we need a contributing file per repo or can we have 1 for everting
    • Do we need a governance repo?
      • Vicky: Governance repo. It's easier to find things if they are all in one place.
      • Dave: CCC has a governance repo
      • Jason: Governance repo can contain "all the standard stuff" no need for duplication of common items
      • Vicky: Inheritance from the governance repo and a contrib.md in each repo
  • Technical charter
    • Governance repo can allow more licenses than what each repo does now
      • Repos use different license's now
      • Any OSI license should be considered (we don't ay that now)
        • MIT, BSD, etc.
        • Allows the TSC to make this decision.
          • Must be noted in minutes and documented in repo
        • KAran - current wording is fine. Don't need to add list of licenses
        • Dave: bullet 1 says that license must be GPL only (XP root code)
          • Would have to use the clause and TSC vote to override the current list to use MIT
        • Karan: Change of wording is approved, but not implemented yet.
        • Louis: Will dig the change out of legal
        • Karan: after change then list will be 'recommended' license
        • Dave: Argue that we don't recommend GPL
          • Danie: Agree
        • Dave: IANL, eBPF programs are usable on multiple platforms?
          • If it is GPL then it is not usable on Windows
          • Would have to write a new XDP root with a permissive license
        • Karan: How to avoid GPL?
          • Dependency mapping on 3rd party then the code has to be GPL
        • Vicky: Create governance repo and have dialog there.
          • How do these things integrate with the kernel. Aggregation or dependence
        • Karan: There are ways to avoid GPL by avoiding certain code or functions
      • Adding repos under GitHub L3AF
        • Requires TSC vote
          • Louis: Voting seems reasonable
        • Code of conduct and reporting
          • Contrib 4.0, vote to use the latest contrib covenant.
            • Vicky: There are fields that have to be filled in. Can't merely point to it.
              • Document in issue
          • Dave: And reporting process - some documented way to report an issue.
            • What if you have an issue about a person that you have to report to?
              • Have a subset of people to report to.
            • Louis: HAve guidance from LF on this
          • Security vulnerability reporting
            • Dangerous to post in GitHub because people may be using it
              • Need reporting in private
              • File issue and discuss in future meetings
            • Louis: Important to set up L3AF on the security on LFX
              • LFX Bots that scan code for vulnerabilities
                • Get L3AF on the tools
              • Jason: IS there a security issues in the LFX tool?
            • Louis: Take the question to IT group.
            • Dave: Link above has process for inbound and outbound reporting
              • Who gets to find out about vulnerabilities and when?
            • Vicky: Often goes to a security group then a public announcement (once issue has been mitigated)
            • Eric: Bluebracket built into LFX security. Checks for governance issues
            • Dave: LF doesn't have best practices here. Ask Vicky.
            • Vicky: We need issues on this one.
          • Karan: Waht does file issues mean?
            • Vicky: In governance repo (once it is created)
          • Louis: Most existing projects have stuff that we can start with
            • Dig out best practices that apply to L3AF
            • Add our own customized guidance as well
          • Dave: OpenSSF had this in their org charter - not completed
            • Funnel our feedback back through them
          • Vicky: All this should be in issues in the tried and true OSS way.
            • I can certainly help with this.
        • Process for selecting Maintainers
          • New repo - (eBPF package) does TSC approve initial maints?
            • After that can maintainers elect other maintainers?
            • Vicky: Look at other projs and open issues.
          • EasyCLA - Turned on DCO
            • Put link to say we have followed it
            • File issue in governance repo
            • Louis: DCO term is supposed to mean dev cert of origin or CLA type agreement.
              • Doesn't define the agreement
              • Could use EasycLA instead of DCO
                • It's lightweight and meets requirement
              • CLA needs each corp or person signing off, corp manager, etc.
                • More heavyweight than DCO
                • Theoretically no problem, but, sometimes it's a problem
            • Vicky/Dave DCO preferred
        • Diversity policies
          • Policy: recommend - LF has 2 trainings. Open source maints and presenters
          • Eric: Should be a broader LF component so that people don't have to take the course multiple times
          • Dave: It is alrady shared and proj independent
      • Jason - L3AF package repo
        • Not using public is probably better
        • Public implies accept anything
        • suggest initial instead
        • Karan: Start with initial version and require committee for further changes
        • Dave: public one mentioned that you are not okay using your private repo
          • Reccomend that people are using their own vetted version
            • Public seems to indicate otherwise
        • Karan: How secure is this going to be?
          • Ways in which this can be achieved. Never reached an agreement about 'public'
          • Need to start with something. Let's have initial version and iterate from there.
          • Have we agreed on this approach or need further discussion
          • Vicky: Defer to package repo group. TSC shouldn't have to do this.

...