mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
Subject: [TOPIC 12/12] Overflow discussion
Date: Mon, 2 Oct 2023 11:22:49 -0400	[thread overview]
Message-ID: <ZRrgSZTlZd4SXfrP@nand.local> (raw)
In-Reply-To: <ZRregi3JJXFs4Msb@nand.local>

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

      parent reply	other threads:[~2023-10-02 15:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 15:15 Notes from the Git Contributor's Summit, 2023 Taylor Blau
2023-10-02 15:17 ` [TOPIC 0/12] Welcome / Conservancy Update Taylor Blau
2023-10-02 15:17 ` [TOPIC 1/12] Next-gen reference backends Taylor Blau
2023-10-02 15:18 ` [TOPIC 02/12] Libification Goals and Progress Taylor Blau
2023-10-02 15:18 ` [TOPIC 3/12] Designing a Makefile for multiple libraries Taylor Blau
2023-10-02 15:19 ` [TOPIC 4/12] Scaling Git from a forge's perspective Taylor Blau
2023-10-02 15:19 ` [TOPIC 5/12] Replacing Git LFS using multiple promisor remotes Taylor Blau
2023-10-02 15:20 ` [TOPIC 6/12] Clarifying backwards compatibility and when we break it Taylor Blau
2023-10-02 15:21 ` [TOPIC 7/12] Authentication to new hosts without setup Taylor Blau
2023-10-02 15:21 ` [TOPIC 8/12] Update on jj, including at Google Taylor Blau
2023-10-02 15:21 ` [TOPIC 9/12] Code churn and cleanups Taylor Blau
2023-10-02 15:22 ` [TOPIC 10/12] Project management practices Taylor Blau
2023-10-02 15:22 ` [TOPIC 11/12] Improving new contributor on-boarding Taylor Blau
2023-10-02 15:22 ` Taylor Blau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRrgSZTlZd4SXfrP@nand.local \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).