Skip to end of banner
Go to start of banner

02-16-2022 TSC Meeting Minutes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Meeting Recording

Meeting Chat File

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


LF Staff: LJ Illuzzi

Agenda

Minutes/Updates

Upcoming LFN Events-

  • 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 issue 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.

Action Items


Future Agenda Items


  • No labels