* 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?"
