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

Compare with Current View Page History

« Previous Version 19 Current »

Attendees

Edward Ting (Lenovo)

Prabhjot Singh Sethi (ATS)

Joseph Gasparakis (Intel)

Randy Bias (Juniper)

Darien Hirotsu  (Redapt / SDN E)

Jim St. Leger

Anda Nicolae  (Lenovo)

Sukhdev Kapur (Juniper)

Valentin Sinitsyn (Yandex)

Thanh Ha (zxiiro) (LF)

Daniel Pono Takamori (LF)

Ian Rae (CloudOps)

Casey Cain (LF)

Send regrets: VMB (Juniper)

Agenda

  • Review action items from 2019-02-28 Meeting notes
  • TC election results
  • TSC chair election (https://wiki.tungsten.io/x/p4Bo)
  • CLA automation update
  • TSC priority brainstorming (see 2019 TSC Priorities)
    • Particularly release cycle: 9 months will not be nearly fast enough for downstream commercial distributions like Juniper's Contrail
    • Related: do we think the TF community is in the distribution business or not?  It directly affects how we think about the build/release process
  • ARB member replacement from Nachi Ueno to Shivayogi Ugaji (added by Sukhdev)
  • Interns - there are three candidates who have sent emails to the community (added by Sukhdev)
    • VMB: The GSoC team is tracking this stuff in an invite-only spreadsheet; ping Valentine if you want access
  • Opt-in Anonymous Demographics Diagnostics for TF?
  • doc group meeting

Minutes

  • Docs meeting setup for Wednesday 8:30 PST
  • CLAs sent over
  • TSC priority brainstorming
    • another week for feedback
    • need better technical feedback
    • docs and workflow for new devs
      • how can I do this as a new dev?
    • need docs before anything else to grow new devs/ community

    • From Randy Bias:
    1. ease of use, devstack like experience, expand into kubernetes/ other products
    2. better metrics on community involvement, more deliberate upstream contributions/ communication
    3. streamline governance, ARB
    4. build release process
  • GSOC approved! GSoC 2019
  • need to have some technical writers for documentation team
    • whether from Juniper or elsewhere, probably need some directed effort
  • different tiers of documentation
    • markdown in github for devs
    • don't tie docs to master
    • point people to releases for better docs
  • ARB member replacement
    • replacing with another Juniper dev Shivayogi
  • Need to rewrite main tungsten.io page with up to date
  • Interns:
    • Expectations codified
    • still in proposal phase
  • Diagnostics:
    • don't know who the community is
    • built-in anonymous usage statistics
    • opt-out
    • thoughts:
      • RLB: can we add something to the GUI that prompts people to opt-in?
      • Casey: ability to opt-out at any time; what are the GDPR issues?
      • Casey: Brandon Wick and Jill Lovato feedback on how to incentivize participation?
      • how to get more visibility into community through code?
      • "usually negative reaction to putting this kind of code into code base"
      • will probably need to be opt-in, could incentivize?
      • need to rope in some marketing/ community management folks into the conversation
      • RLB: easiest way to do the opt-out is with a button in the GUI that has some boilerplate language explaining what, why, and how to opt-out in the future; button turns a different color when you are sending regular diagnostics
  • Build Release Timeline:
    • how long should be the timeline be, ie 6 vs 9 months
    • goals in release? maybe just build a stable release?
    • nightly, weekly, monthly (unstable, testing, stable/LTS)
    • first need to move build release away from Juniper
    • sidenote: what is the upgrade path
      • sort of a rolling release for the LTS
      • no guarantees for upgrades on nightly/ testing
      • sanity testing for nightlies
    • some testing takes on the order of a month in order to test on 10k nodes
    • concerns over the engineering force required for testing
      • RLB: once automated and setup, should be streamlined
      • JG: might need a couple senior engineers to keep it running
    • since most users are devs, can probably integrate tests as the projects grows
    • need some goals to aim for and some docs so everyone is on the same page
    • need more robust tagging than pointing to commit hashes
      • branches/ tagging/ on whatever release cycle is chosen
      • branches for nightly/ weekly/ stable and tags for releases


Action Items

  • No labels