[TOPIC 12/12] Overflow discussion

[Taylor Blau <me@ttaylorr.com>]

* trackers - bug, review, etc
   * "whose turn" for patches
* (Minh): Multi-pack index and when you repack a large number of packs, you can
  rewrite pack index partially on things that have been changed but can't do
  with bitmap? Is this assumption correct
   * (Taylor): yes: bitmaps get rewritten from scratch to what pack they belong
     but it's close to an incremental approach as long as there is an existing
     bitmap.
* Back to project management practices that Junio mentioned, we seem to not shy
  away from discussing what kind of tool will help us: Bug tracker, etc but have
  more trouble with what practice to put in place to enforce it. Ex: with a
  public Bug Tracker, who responds to user issues, what does priority mean, etc.
  Wonder if people who are motivated to solve by making a small group to define
  this, bring back a proposal to the list.
   * (Josh) As Junio mentioned lot of patches getting ignored - and mostly
     directed to our day job, can we get cross company commitment to
     review/volunteer/run a bug tracker to explicitly help community
   * (Emily) Can view this as a donation, "donating project management
     headcount".
   * (Jonathan) In the linux kernel there's a "Contribution maturity model"
     document. Common definition on what it means to be doing your part, allows
     companies to assess themselves.
   * (Taylor) Open Source donation was something that happened recently
   * (Emily) The Linux Foundation sponsors work to measure contribution: which
     company contributes how many patches/reviews
   * (Pono) Can help here to define qualitative metrics. Tools: CHAOSS that
     plugs into repository. Can work with someone to outlay this.
   * (Phillip) It's easier to find reviewers in some areas than others.
     Different companies have different areas of interest.
   * (Emily) Yeah, we've noticed this at Google. Example: Submodule
   * (Josh) Specific people to volunteer and how we recognize that volunteering
     effort in a smaller group. How about a Git reviewer conspiracy to honor
     people.
   * (Jonathan Nider) Make a small group and Jonathan can volunteer in it and
     Taylor is happy to help too.. (4 people volunteered - jrn, nasamuffin,
     keanen, ttaylorr)
* (Terry) semver was brought up in the compatibility discussion
   * I'd recommend looking at the Eclipse project's practices. It's Java based,
     has very clear language-based definition of what an API or ABI break is.
     But they also have a notion of "public" versus "public-internal" --
     public-internal interfaces can be things that are known to be unstable, and
     when you use them you know you'll be doing work to keep working on top of
     it. They also built a bunch of tools for checking when you break API/ABI.
     This was very successful.
   * Teams at Google building a web service don't have to deal with nearly as
   	 much of that - you can roll forward and back quickly - but that's not the
   	 case for things running on people's desktops, where you need to take a more
   	 principled approach to API evolution.
* (Emily) library API stability (or lack thereof)
* (Minh) Reg SHA256 migration - Git forges
   * First-mover topic - once one forge moves, others will have to scramble.
     Should we coordinate?
   * (Patrick) Gitaly supports SHA256, unofficially already works in importing
     code to GitLab. But we need to adapt a lot of the frontend to support it.
   * (Taylor) GitHub is in an earlier state but is also interested in picking
     this stuff up.
* (Emily) Backward compatibility discussion - Library API Stability
   * Put off version over version API guarantees
   * From talking with the LLVM team at Google, learned the LLVM project adopts
     similar attitude towards API backward compatibility. SHould be an active
     contributor to not break your API.
   * (Jonathan Nieder) Maintaining C++ compatibility is hard, fully expressive
     API in C isn't easy. So it's a nice dividing line there. In Git it's all in
     C, annotations/signals where people can distinguish between "#include this
     header for a stable API, #include this other header for
     use-at-your-own-risk shifting foundation".
   * (Terry) LLVM is for static analysis, but the Git project should probably
     provide a higher level of API guarantee as these 2 projects are at
     different levels.
   * (Jeff Hostetler) Is there a roadmap with milestones around things like "at
     this point, you can work with multiple independent object database
     objects"?
      * (Emily) Yes, that's part of the holy grail of what we're trying to
        accomplish, and it's needed for submodules.
   * (Pono) licensing? Okay with current license, not a concern for Google but
     its a concern for other people using it.
      * (Jonathan) License as part of the interface, as soon as we have
        potential callers for whom GPL is not suitable this conversation will be
        easier. "Shall we relicense this subsystem to support this caller?"