Page Comparison

Meeting Administration

•  Linux Foundation Anti-trust Policy
•  Agenda Bashing
•  Attendance/Quorum (1013/15)
  
•  Approval of previous meeting minutes

• Minutes of last week's meeting are APPROVED.

•  Continue Release process discussions, Goals and Management
  
  •  Proposed milestones (https://wiki.anuket.io/x/QD1D)  UPDATE
    
  •  Interaction opportunities and end-goals/customers

•   Anuket IP (intellectual property) policies

•  gitlab/gitlab CI migration
  
  •  Follow-up on Questions regarding:
    • Moving to Gitlab.com will reduce the project's hosting costs (?$$?),
    • leverage Gitlab's SLA (what is the SLA?), and
    • allow them to take advantage of features released monthly (can we control new features we adopt during a Release?).

• What is the SLA?
  The GitLab.com SLA target is >= 99.95% availability
  https://about.gitlab.com/handbook/engineering/infrastructure/performance-indicators/#gitlabcom-availability

  To achieve this target, problems that affect everyone on the platform will
  be swiftly dealt with by our SRE team.

  Details on GitLab.com Service Level Availability and how it is calculated
  can be found here:
  https://about.gitlab.com/handbook/engineering/monitoring/#gitlabcom-service-level-availability

• Can Anuket stay on same version during a release (6-months) or control
  new features we adopt?
  For GItLab.com SaaS, version upgrades occur automatically behind the
  scenes. We use CI/CD to release fixes/improvements and enable access to new
  features as quickly as possible for users of our SaaS service. New versions
  are tested and go through a QA process before being deployed to GitLab.com
  to ensure quality and backward compatibility. In other words, version
  upgrades on GitLab.com should not break any functionality in terms of web
  interface, command line interaction, or API functionality.

•  

  Status Updates

  •  Linux Foundation Lab (Portland) hardware upgrade status
  •  LF IT/Infra update: (Aric Gardner, Trevor Bramwell)

•  AOB