Notes from the Git Contributor's Summit, 2024

It was great to see folks at the Contributor's Summit today during Git Merge!

The notes are available (as read-only) in Google Docs, too, for folks who prefer to view them there are the following link:

    https://docs.google.com/document/d/1IZvW1_pnkrMMWnBmZO2MbT4QCjIPJBWNJg_shYqSnrE/edit

At the Contributor's Summit, we discussed the following topics:

  - Rust (Kyle)
  - Top-level lib/ directory (Patrick)
  - Structured Error Handling (brian)
  - Platform Support Policy (Emily)
  - SHA-256 / Git 3.0 (Patrick)
  - Git / Conservancy Stuff (Taylor)
  - How to attract new contributors? + Community Discord (Jonathan N. /
      Calvin Wan)
  - Modern Build System (Patrick)
  - Bundle-URI on fetch / resumable clone (Toon)
  - Project Tracking (Emily / Patrick)
  - git-scm.com state of the site (Johannes)

I'll send the broken-out notes for each topic in a response to this message for posterity, and so folks can continue the discussion on the list.

Like in previous years, if you have any feedback on how the Contributor's Summit went please feel free to share it with me here, or off-list.

I hope to see everybody in person next year!

Thanks, Taylor

Rust =====

(moderator: Kyle; notetaker: Taylor)

* Kyle: Rust code in the Git project; do we want it? Why would we want
  it?
* Elijah: Anybody other than Randall that objects to it?
* Peff: I don't object, but what does it mean for existing developers?
  Will non-Rust developers need to start learning?
* Emily: The avenue for introducing Rust is replacing low-level C
  libraries that are complicated and un-maintainable.
* Peff: What's low-level? Peff considers strbuf to be low-level, but
  Emily considers merge-ort.
* Kyle: Anything dealing with untrusted inputs would be a good spot to
  start.
* Patrick: Instead: take a system like reftables that is already
  self-contained.
* Jonathan: Another nice thing: if someone is on a platform without good
  Rust support, then they could stll use Git without reftables.
* brian: Rust is optional, can we add small new features and performance
  improvements that replace existing code, but it's not required.
* Emily: are we then carrying parallel versions of the same thing? What
  does that mean for the C version?
* Taylor: I don't want to double our vulnerable surface area.
* Patrick: Right, either you go all in or don't.
* Taylor: I don't want to give too much stock to a small number of
  people/platforms and hold the project hostage.
* Emily: old versions aren't going away.
* Patrick: Those could be maintenance releases.
* Do we need to support an older maint version in pure C
* Backport security fixes? Would issues be in both implementations?
* Do we want to encourage those without Rust support to maintain a
  friendly fork C version
* Johannes: Transpile C to Rust?
* Elijah: Does that presume we're not using Rust libraries, or are those
  transpile-targets as well.
* brian: We are going to have to use 'std', the question is what
  versions of Rust are we going to support? Can't be the latest version,
  since it only lives for six weeks.
* Taylor: vague idea of why we would want to use rust, but what are the
  concrete benefits of moving to rust?
   * brian: increased parallelization, can't write unsafe code,
     incremental parsing of objects. When it fails, you get a panic
     instead of a segfault.
   * Patrick: clear ownership semantics, was a huge problem with the
     memory leak work that they have been doing, it's not clear who owns
     what at what time.
   * Jonathan: 3 things; (a) user-facing benefit of memory safety, (b)
     productivity benefit to ourselves to have better architecture makes
     it easier to make changes, (c) would attract new contributors to
     the project.
   * Kyle: that's what I was going to say on (c), writing C is daunting.
   * Patrick: I'm in the opposite camp, I'm scared of Rust!
* Why not move over to the gitoxide project? Probably not realistic
  within the next 10 years, though Sebastian is doing great work.
* Taylor: great, what's the transition plan?
* Patrick: can't start until libification makes progress.
* Elijah: what about a low-enough level function that we can start with?
* Patrick: Still not work-able, there are too many global variables that
  we need to contend with.
* Taylor: IMO better to port to rust first from an implementation that
  we know, then libify in a language that has better support for
  refactoring.
* Jonathan: likes what Patrick was saying about having modularization
  make this easier. The other obstacle is that if we want to use any
  Rust at all, we need to have a POLICY on how we use Rust.
* brian: C shared library built in Rust, or top-level build with cargo?
* Have had experience with a previous C-to-rust migration! C FFI to call
  into Rust from C until everything is ported over.
* Patrick: modularization should be the first step, otherwise we're
  going to have the same architecture that we have now. If we inherit it
  now, it'll never get fixed.
* Mark: need Git to continue to be relevant in 10 years, making this
  kind of change is part of that
* Maintainability is something we can invest in.
* Emily: governance can help corporate contributors behave better. Say
  "your contributions have to meet this standard"
* Patrick: meanwhile I don't want to push away drive-by contributors
* Elijah: if someone wants to contribute a specific component in Rust,
  such as a replacement builtin, they need to call C, what happens to
  infrastructure such as option parsing?
* Emily: I really like the idea of starting with reftable
* Patrick: I was going to make a Rust implementation of reftable anyway

On September 20, 2024 10:18 AM, Taylor Blau wrote:

To be honest, I do not fundamentally object to Rust. My problem is that the Rust team is not supporting including NonStop as a platform. I would love to be able to do the port, but it is not up to me - it is up to Rust's permission (or lack of in this case) to support NonStop, and I do not see this changing in my life-time. Depending on a piece of technology where control of where it runs is outside of git's control is not responsible, in my view. It restricts where git can run, and excludes platforms that currently use a critical piece of infrastructure (git). I have tens of thousands of people in my community who depend on git on a daily basis, and simply kicking them off because of a decision, or lack of decision, that some unrelated dependency controls should be (unfortunately does not appear to be for git) a showstopper.

I am just the vocal one who is paying attention to the issue.

Sincerely, Randall

Hi Randall,

This ended up being pretty long, so I apologize in advance for 'not having the time to make it shorter' (if you'll permit a small amount of plagiarism there). These are just my thoughts on this topic that have been cooking for a long time. I've been following this conversation closely, and for the first time, I thought I might have something small to add. Unfortunately, it's taken a lot of words to say it!

<rsbecker@nexbridge.com> writes:

I don't think anybody (or at least, I hope nobody) thinks so; this is absolutely a conversation we can and should (and I believe do) have in good faith :-)

I've not contributed to this conversation much so far -- not out of lack of interest, but out of respect:

1. While I've been using Git for many, many years, I'm a pretty new face
   on this list. I'm still working on making a good first impression :-)

2. I know absolutely _nothing_ about NonStop, but I do know what it's
   like to feel like you're a member of an invisible set of users. There
   are significant aspects of my $DAYJOB where that is absolutely the
   case, so I want to leave room for what I know that I don't know. I
   know your customers are important, and (I think I know) you
   supporting your customers requires the tools being used to be
   supported.

3. I don't even know _that_ much about Git's implementation compared to
   the experts on this list, so I feel ill-equipped to judge personally
   whether Rust is a good fit for the project to begin with -- thus I
   don't feel I have much to contribute to that conversation over what
   the experts have already said.

Putting my own cards on the table -- I'd be in favor of introducing Rust into Git's codebase for many of the reasons cited elsewhere. Based on my naive understanding of the codebase and the types of bug fixes I've seen come in during my time paying attention to this list, it does seem like rustc would add the value for which it was designed. I say this not to 'upvote' the idea of including Rust, but to be transparent about the context from which I'm speaking.

So, in good faith, here goes :-)

Is this just regarding the GCC dependency I've seen you reference elsewhere[1] or is there something else? I just want to make all the cards are on the table here -- particularly I want to make sure you're not referencing some licensing incompatibility or project policy that could be (even) more challenging than porting GCC to NonStop. An uneducated search of rustc's book[2] for 'gcc' didn't yield anything immediately interesting, but there are call-outs for not supporting platforms that introduce license incompatibilities or 'onerous legal terms'.

If not, is this about (what I assume to be the) 'tier 3' platform support policy mentioned at [2]? In some respects, it seems like this is similar to the status of NonStop as a supported platform in the Git project already, though I suppose that's also a main topic of conversation for the 'supported platform' thread elsewhere. It does seem in line with what you already do, though, which is to provide patches to Git when something merges that breaks tests on NonStop. It seems it would be similar in a Rust world, though patches would 'just' be sent to the Rust maintainers instead. (I say that knowing that it would be an entirely foreign codebase and set of concerns for submitting correct patches -- so the two are not at all similar in effort, just in behavior.)

I think this is going to be true of any platform that the Git project chooses to continue to build upon, isn't it? Any platform-specific bugs in the various C compilers used are not in this project's control, either, nor OpenSSL, cURL, PCRE, gettext, etc., etc. that are already essential to Git's main functions when it's being used by a human (i.e., not as part of a larger automated system).

Any added dependency will run the risk of not being buildable on every platform out there -- even if it's included in the standard library, potentially -- and I don't believe it's a sustainable practice to never add any dependencies.

I'd like to understand this a little better.

First, from the original notes:

which I mention only to supply the obvious counterpoint. I believe you've said in the past (sorry that I can't find the specific link) that you'd like to see Git continue to receive improvements and enhancements that you can forward onto your customers. This is great! I understand this perfectly. I have the very same desire for my users (which number in the 3-4k range). I look forward to every performance improvement and revamped workflow with bated breath -- wondering how/when it can be incorporated into our system to give our folks the best experience they can possibly have as direct users of Git in a heavily automated system.

It stands to reason that your users wouldn't see such improvements if incompatible technologies like Rust are adopted into the codebase and those features were written using this incompatible technology. This is understandably a frustrating prospect! Previously, you would have been able to get even more value out of all the open-source effort (and your own effort as a maintainer keeping it compatible) -- and now it's not really feasible. I do understand this sentiment. (Regardless of how much I understand it, if this is not _your_ sentiment, please let me know!)

Here's where I'm struggling a bit. From what I see, I understand two contradictory points:

1. To continue building Git on every platform where it builds today, the
   project must either

   a) not add any new incompatible dependencies or
   b) put any such dependencies behind a feature flag (e.g. NO_CURL) so
      that Git may continue to be built without that dependency.

   Great, no harm -- no foul. But...

2. If you continue building without that dependency, you don't get that
   feature, so the original purpose of enhancing Git -- to pass that
   benefit on to users -- is lost.

So it would seem that this leaves us with only option (a) to not add any new incompatible dependencies -- which is what I understand you've been proposing. Certainly reasonable. But then how do you build cool new stuff? Well, build it yourself, I guess.

There's been a _lot_ of cool new stuff lately. This is great! But this does seem to be spearheaded by the work (and thus funding) of companies like GitLab, Microsoft, and Google (and these are just the ones I recognize either by contributor name or by email domain). I'm incredibly thankful for the work and expertise these folks add to the project on an ongoing basis.

I worry though that the 'cool new stuff' seems to require such investment. It is _hard_ to write correct, safe C. I worry that this difficulty will eventually translate to significant, safe contributions coming only from those with the resources to create them and not from a more diverse pool of contributors. As grateful as I am to large companies who fund Git contributions, I don't think those companies, given the choice in and of themselves, would think twice about dropping support for a platform they don't use -- and that is probably a much smaller set than 'does the platform have GCC'. I don't think this is a danger today or tomorrow, but it _is_ a danger of not having a diverse group of contributors -- and that is the danger posed by not allowing yourself to use any of the 'cool new stuff' _other_ people have written.

--

I don't have a satisfying response to what to do for NonStop in a world where Rust enters the Git codebase. I really don't, and that frustrates me for you. I hope that there's a solution out there (maybe from your vendors, maybe from the storied halls of GCC maintainers, who knows), but I'll echo (more earnestly this time):

Nobody has the power to 'kick users off' a project such as Git -- not even if everyone somehow miraculously agreed to port the entire thing to something hot off the presses at /r/programminglanguages :-) Ultimately, your systems will continue to function regardless of what happens upstream. Of course I can't speak to support contracts, but I assume neither can anyone on this list.

That said, I also don't know how a project can continue to thrive without the (occasional, thoughtful, and deliberate) introduction of new technologies, new contributors excited and emboldened by those technologies, and new ideas from those contributors.

Change is essential to growth. Like I mentioned at the outset, I'll let the true experts on this list speak to whether _this_ change is essential for growth, but I hope I've at least made some points that were worth reading.

[1]: https://lore.kernel.org/git/007c01da4420$10a7b700$31f72500$@nexbridge.com/ [2]: https://doc.rust-lang.org/rustc/target-tier-policy.html

On September 22, 2024 10:26 PM, Sean Allred wrote:

the time

These are

been

might have

absolutely a

interest,

into Git's

during

the value for

Rust, but to be

elsewhere[1] or is

here --

than porting

yield

supporting

terms'.

The GCC dependency, which does not currently exist in git, is independent of Rust. Rust has its own rules and runtime. The issue here is that the Rust team gets to decide what platforms can participate, NOT the platform maintainers. No matter what my intent, or resources, I cannot get the Rust team to "Allow" a port. In many ways, this is egregious and is a policy issue entirely on Rust, not us. We want to do a Rust port but are simply not allowed/approved. It is their policy.

policy

status of

suppose that's

elsewhere. It

patches to

be

maintainers

and set of

similar in effort,

This is not a tier 3 policy with regards to Rust. It is exclusionary.
 

chooses to

C

cURL, PCRE,

it's being

platform

and I don't

I agree that it is not a good policy to never add new dependencies. However, Dependencies must be reasonable and give the platforms a chance, at least, to adapt. We cannot in the case of Rust. The problem is not actually that we can do without new features that are in Rust but not C. The problem is when there are CVEs. Suppose a severe CVE happens that is fixed in a Rust component but referenced by a C component or somehow intertwined. The fix to the CVE becomes unavailable and git gets thrown off the platform. That is the reality of how insidious CVEs are when it meets corporate policy. I am primarily trying to protect from that.

If git was a toy or an experiment, this would not be an issue. But git is core Infrastructure for managing and deploying customer facing functionality now, more than any other single piece of code on any platform. It my hope that the git team will finally and eventually understand this, and act accordingly.

If the component in Rust is a toy or non-core, like Git LFS in GO, it can sometimes be worked around. Git LFS was something we wanted to port, but it turns out to be irrelevant as restrictions in Cloud GitHub and BitBucket make it pretty much worthless looking into the future.

Telling 10-20000 users that their core bit of infrastructure is insecure and not fixable is not a tenable position. However, it is hard to defend the community when the git team is hell-bent on this particular decision. What do you need to understand here? It is a small community with a large number of users in key financial institutions that have a very conservative adoption policy and an even more conservative hardware vendors.

said in

Git continue to

desire for

performance

experience they can

What I should have said was that I have no problem with git adding new portable dependencies. Rust is fundamentally unportable given the policy restrictions Imposed by that team.

incompatible

were

frustrating

of all

compatible) -

(Regardless of how

contradictory

new

proposing.

it

seem to be

Microsoft,

name or

folks add

It is

eventually translate to

to create

to large

the

'does the

it _is_ a

danger posed

have

where Rust

hope that

storied

time):

Again, it is not the gcc dependency. We have been coping with c99 and will have c11 shortly. It is Rust itself that is exclusionary. It might be easier to write new functionality in Rust - it is easier in Java, Perl, and Python too. Why Rust? Because someone wants it, not because you cannot implement the functionality.

I do not see giving up on git is an option, but if that is what ultimately happens, I think it will be embarrassing and expensive in the extreme for large numbers of users. Considering that 90% of all financial transactions quietly and without fanfare touch NonStop hardware at some point, the impact should be obvious but not initially apparent.

if

hot

will

speak

the

new

from

true experts

hope I've at

Hi Randall

On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:

I'm hearing that there is a fundamental incompatibility between some aspect of the NonStop platform and rust's requirements for supported platforms. Does that mean it is likely that rust will never be available on NonStop?

In that scenario there is nothing preventing a different fix being implemented for an older version of git running on a platform that does not support rust. It's likely that such a fix would need to come from the community using that platform rather than upstream which would represent an additional cost for users that have previously been relying on the upstream to provide security updates.

I'm struggling to understand why such a conservative community needs access to the latest version of git. I'd have thought that key financial institutions should be able to fund someone to backport security updates to their critical systems.

It may be true in theory that anything one can write in rust could be written in C instead but in I'm not sure it is true in practice. In previous discussions multi-threading has been mentioned as an example of something that is sufficiently difficult to get right in C that contributors are not willing to implement whereas they would be happy to do so in rust.

I believe that those advocating for using rust are doing so because they believe it will benefit both contributors and users. The problem we have to wrestle with is whether those benefits outweigh the cost to the relatively small proportion of users who do not have access to rust on their platform.

Best Wishes

Phillip

On September 24, 2024 11:30 AM, Phillip Wood wrote:

I do not know whether Rust will never be available. The policy is that the Rust maintainers must sanction and approve any ports. I have tried to get approval and have not been able to do so. It is not for a lack of trying. To me, this is a serious problem because there is no "community" concept for Rust. It is either sanctioned or denied, regardless of the desire of someone to port the code.

This means that the community is responsible separate for CVE security fixes. I have a major problem with that. It means that there will be separate NIST and Mitre reports for security issues for the same case. The code will then forever deviate and git will no longer be one product. It also means that customers can no longer consider the official git to be available on NonStop but will have to come from an unsanctioned community edition that will lag behind all security fixes associated with Rust code.

The community does not need access to the latest version. It *does* need access to security fixes made in response to CVE reports. As above, being able to backport security fixes means that git is no longer officially the same, nor can be verified as legitimate once this is done.

My position, as a professional product manager, is that such changes should not be approved.

I would be very happy to have Rust on the platform. I do not control the situation even if I have the skill to do the port. This is entirely unfair, in my opinion, to the community maintainers, (me for one) who are going to end up doing far more work for free than anyone else.

I am sorry to disagree, but I cannot see any way around the problem that makes sense. I have been the NonStop maintainer since 2016, and feel like I am being now being thrown under a bus outside of any of my control. If there is a way to solve this, without this becoming my full time (for free) job, I would consider it. (Note that the git license (GPL) requires me to contribute my changes, so it is being done for free even if I find a way to charge for it.) Honestly, is that reasonable?

<rsbecker@nexbridge.com> writes:

I do not see a proposal for "NonStop" in a pull request filed against rust-lang/rust[2] per the process laid out by [1]; can you point me to where you submitted this request?

[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html [2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop

On September 27, 2024 5:38 AM, Sean Allred wrote:

trying.

I will investigate where this went.

On September 27, 2024 8:24 AM, I wrote:

I have taken this up with the platform vendor. Any request of this sort needs to come from them, in my opinion, even if I do the port.

I will advise the list if I get anywhere.

Top-level lib/ directory ========================

(moderator: Patrick, notetaker: brian)

* Patrick: Difficult to find stuff (README, etc); top-level directory is
  cluttered
* J6t: Clarifies that this is the C and H files
* Emily: Originally the plan was to move libified files into lib once
  libified
* Jonathan:
   * Discussion has been present on the list before (in Git 2.0
     discussion)
   * Bikehedding on the list (more difficult to blame)
   * Differences of opinion about lib and include and naming
   * Blame problems, but this is an opportunity to fix that
   * Heart of it: has nonzero costs, needs to have enough benefit to
     offset it
* Elijah: git apply doesn't handle directory rename
* Patrick: Bikeshedding not a problem; can be handled
* brian: Not really hearing an objection
* Peff: Not a problem for him, but not a really big objection
* Kyle: Not sure the value here
* Jonathan: I really love what Patrick said about "I can handle
  bikeshedding", I think it's great if you can guide a discussion
  on-list toward a decision on what we want for source layout, how we
  structure code, etc. Exciting!
* Taylor: improves things, makes it more maintainable/discoverable, but
  takes time away from other things like security/performance bugs.
  Should be done with a healthy balance.

Structured Error Handling =========================

(moderator: brian, notetaker: jrnieder)

* brian: idea for structured error handling!
   * Very little needed - pointer to error string, uint64_t error code,
     and ??  (third thing I didn't hear). Return it on the stack. Rust
     does this kind of thing all the time.
   * Having that structured return value lets a caller decide what to do
     with it
     - print a message, decide whether to exit or recover, etc.
* Patrick: a few requirements
   * want to attach arbitrary metadata to an error (e.g. "I had a
     conflict between that file and that file for this revision").
     Especially useful on the server side.
   * avoid having to parse error messages. Gitaly runs into this. Can
     imagine setting an envvar to get json or some other parsable format
     instead of human-consumable error messages.
* brian: sounds doable. GitHub also has the same hassle with parsing
  error messages.
* Peff: in your proposal, low-level code produces the error struct which
  is consumed at a higher level. Sometimes, though, you have many errors
  that are related.
   * "I couldn't merge these files because I couldn't open this file,
     because of this errno".
* One thing we've considered is having a callback to decide what to do
   * - print the error, collect into a tree of errors, etc.
   * The point is to keep what's happening in the generators of errors
     as simple as possible - I have this type of error and maybe some
     kind of context strings. That context could be owned by the caller,
     the callee can be responsible for copying it, etc. Inversion of
     control.
* Patrick: I like the way Go does things, can wrap errors or append
  messages, return up the stack until someone handles the error. Why are
  we afraid of allocations?
   * Peff: What do you do when the allocation fails?
   * Patrick: can handle allocation failure by having a special error
     that has a statically allocated string.
   * Peff: sounds good, getting rid of die() on alloc failure is okay
   * brian: Rust panics on out-of-memory anyway
   * Peff: there are two different cases - small allocations are "you're
     in trouble anyway", big allocation of user-supplied length is
     something else
   * Carlos: Rust has a "try to allocate memory", relatively new
* Calvin: how do you propagate up the call stack?
   * Peff: in my proposal, every function would take an error context
     struct, call the callback when there's an error, and keep the
     integer function returns. In brian's proposal, we instead return
     the struct.
   * Emily: Are we comfortable with the amount of churn that generates
     in the codebase?
   * Patrick: my inspiration is Subversion in that respect. It has nice
     error handling in C, they're a role model for me in how to do a
     library. It has nice error types that aren't a hassle to use.
   * J6t: if you compile in C++ and use exceptions, the problem has been
     solved 25 years ago.
   * brian: allocating strings for errors and then freeing them is a
     hassle in C. Versus Rust where that's handled automatically.
   * Emily: so it sounds like this is temporary pain
* Jonathan: I like Patrick's description of requirements. One thing that
  would make me more comfortable with the churn is when we get benefit
  even from partial conversion
   * E.g. could say we get structured error messages for the call sites
     that have been converted and not from others. And when I go on a
     debugging quest and wish I had a machine-readable structured error
     message, I can send a patch to convert more call sites
   * Peff: Refs code uses its own strbuf based error handling which is
     worse in every way than the options we've been discussing. :) That
     can be a good playground to try things out.
   * Patrick: +1, seems like a good place to start.

Platform Support Policy =======================

(moderator: Emily; notetaker: Calvin)

* Emily: if you want Git to support your platform, you have to provide
  your tests (e.g. provide your own CI test runner)
   * Should we be more explicit about, for example, the version of C
     that one must support.
* Brian: less-common architectures (e.g. MIPS) sometimes can catch
  problems (e.g. unaligned access) that are not a good practice anyway
   * qemu based CI is so slow
   * netbsd, openbsd, freebsd, probably solaris are up to date with
     modern standards, probably supportable
   * I'm more comfortable with "you have to have threading and POSIX
     2008" than with "you have to provide a CI runner"
* Peff: I'm not sure what people have been counting on
   * Do we have a way to find out what people are using?
   * "Take a little risk, see who screams" has worked okay in the past
     but takes a while
   * Rust is probably a big change
* Patrick: keep in mind that we're at the core of the whole operating
  system, part of the bootstrapping path
   * Emily: yes and no - Git is not just the client, but Git is a
     standard. You can use older versions of Git and clone things from
     GitHub. If we still support the same protocols, I don't think
     needing native git.git CLI support to run on your platform is as
     compelling as new Git being able to support these older standards.
   * brian: OpenBSD doesn't like the GPL, has a project for getting
     trees called "got", it's in C and supportable. It can be a valid
     bootstrapping tool.
   * Patrick: The user experience there is a little closer to CVS. But
     it's still an option.
* Jrnieder: looking from user perspective, Git is the tool people are
  used to for day to day development
   * Emily: There's a difference between using "a git" vs using the
     latest version.
   * Jnieder: telling users to use an older version might result in
     users asking questions on the mailing list about those older
     versions, it's also not free.
   * Peff: to be fair, HP Nonstop support hasn't been a matter of
     "please support me for free" - the maintainer there has been active
     in helping test and debug things. The question here is not about
     whether to continue that but rather about whether we're willing to
     increase the platform dependencies when it breaks such a use case.
   * Peff: Are we okay with dropping NO_PTHREADS support?
   * Brian: POSIX 2008 shouldn't be that controversial. Neither C11
     should be.  We shouldn't take it too far like POSIX 2024, but we
     have to set "some" standards.
   * Emily: So next week when we come home we update the "minimum
     requirements" on the mailing list, and everybody upvotes?
   * Jonathan: we live in the real world - the spirit of "let's require
     POSIX 2008" sounds right, but real-world considerations should
     matter more than the exact text of the standard
   * Peff: example: Android is missing pthread_setcanceltype, which
     leads to Git on Android using NO_PTHREADS
   * brian: it can be enough to pretend to support (compatibility shim)
* Calvin: is there a threshold % of users for "unimportant enough to
  break"?
* Jrnieder: it depends on the platform. Do the requirements that a given
  platform imposes push us in a good direction in general as a project?
   * For example, Windows is a very non-POSIXy platform, but it has
     nudged us toward thinking about subprocesses in a different way,
     and I think that's been really healthy
   * brian: As another example, Plan 9 is really difficult to support,
     it won't pass the test suite
   * z/OS patches originally came in and were gross. I saw a patch come
     in recently that was more acceptable.

SHA-256 / Git 3.0 =================

(moderator: Patrick, notetaker: Taylor)

* Patrick: some of you may have seen some patches from a few months ago
  to start thinking about this, and we now have a "deprecations" doc of
  things that we plan to get rid of.
   * One thing going away is grafts
   * Another thing is git pack-redundant
* Patrick: SHA-256 will become the default object hash, but is
  contingent on major platforms supporting SHA-256.
* Emily: this helps us too, because it provides some motivation that
  this is going to happen.
* Patrick: having it in the 3.0 document makes it easier to push at
  large organizations.
* Jonathan: with partial clones if I understand correctly users were
  already trying it and complained to GitHub about it not being turned
  on.
   * Taylor: not really…
   * Peff: I was embarrassed, so I wrote the bitmap support for
     filtering objects
   * Taylor: yeah, and turning it on was easier, but didn't require
     updating database columns, etc. so the transition period here would
     be much more expensive.
   * brian: "can you put it in the customer feedback repo" is something
     customers can ask for
* Jonathan: could use interop as a way for Git to default to sha256 with
  the only harm to end users being that clones and fetches get slower
  until servers support it
* brian: not planning on working on it unless their employer pays for
  them to do it.
* Mark: customers wanting to start with SHA256 so they don't have to
  migrate later
* Patrick: GitLab never really wanted SHA-256 until it was done on the
  Gitaly side.
* brian: has definitely seen it on StackOverflow as something that
  customers want. Not a huge selling point right now, but will become a
  humongous selling point at some point (beyond >2030).
* Peff: if the proposal is to make SHA-256 the default, then we need to
  be developing with it now, and we're not because there is no interop.
* Taylor: we should do it via interop, (a) because GitHub could not host
  it, but (b) because we would introduce the same lack of testing just
  with the interop code, not the SHA-256 code. So it must be done via
  interop.
* Patrick: OK, but why do we care about SHA-256 locally if they're using
  SHA-1 on the remote? The remote could be compromised
* Jonathan: You can verify things locally. This is the core idea of
  distributed version control.
* Patrick: Oh, I see.
* brian: Signatures work with both hash functions, you can sign with
  both.
* Peff: It does not feel right to me to set the user default until we
  the project are using it, and that the interop code is a part of that
  story.  (back to Git 3.0, we combined the SHA-256 and Git 3.0
  discussions into one)
* Peff: I have a proposal for Git 3.0, maybe this has been discussed?
  Can we get rid of some of the older protocols (dumb HTTP)?
* Patrick: Lots of esoteric things, like show-branch, which apparently
  nobody uses.
* Elijah: not just removals, but changing defaults, etc.
* Emily: are we interested in non-backwards compatible changes, like
  adding multi-Author fields to commits?
* Peff: I think that's a bad example, it can be done without breaking
  compatibility, but it was decided to not to do it. You're welcome to
  resurrect the discussion.
* Patrick: … but it's a different question of whether or not that would
  end up in the document.
* brian: multi-signatures
* Jonathan: Two questions I'm hearing:
   * Should we include things that haven't been implemented yet?
     Probably not.
   * What do we think about this major version as a way to break
     interoperability with older versions of Git?
* Patrick: I would not be in favor of breaking something, at least in
  cases where we can add a protocol extension and/or new capabilities.
  Intentionally breaking interoperability with an older version does not
  seem like the right way to go.
* brian: I agree, but for the dumb HTTP protocol, C git uses it, Eric
  Wong is really into it (lore.kernel.org supports it), etc.
* Emily: Bundle URIs and resumable clones, could in theoretically work
  for resumable clones, but we don't have client-side support.
* Peff: Pretty sure that this isn't the case.
* Mark: can I ask a "dumb" question? What would it take to get a
  schedule for 3.0?
   * Patrick: Junio says not too often, maybe only breaking releases
     every 5-10 years, which means 3.0 would come in 1-2 years.
   * Peff: 1-2 years is what is in my mind.
   * Taylor: I think that whatever answer we come to agreement here will
     not be satisfying for you.
   * Taylor: the items on that document aren't a checkbox list of things
     to do before Git 3.0, but isn't a "let's get all of these things
     done and then we'll release Git 3.0".
      * More that we'll all wake up one day, realize that we've done all
        or enough of what would go into Git 3.0, then remove a bunch of
        code, and ship it.
* Jonathan: collecting breaking changes and aggregating them so users
  can prepare for them together is helpful, but it's not the only way
  that breaking changes will happen, especially if there is something
  that needs to go away.
* Patrick: I want three things from this document:
   * Reminder / documented intent.
   * User feedback to hear things like "this is important to me, what is
     (if any) the replacement?"
   * ???
* brian: changing the default branch name?
   * Taylor: I would be in favor of doing it sooner
   * (some discussion)
   * Taylor: We should consider doing it for git.git as well.
* Peff: we might write a bunch of those patches, move them into 'next'.
  Could we have a Git 3.0 pseudo-maintainer.
* Jonathan: I have a naive question: why wouldn't it look like turning
  on a single Makefile variable?
* Emily: and then we go and delete the code inside of the #ifdefs
* Taylor: whoever is the maintainer at that point in time could consider
  a double-wide release cycle, where we delete that code, implement new
  things, and then at the end of that cycle the artifact is called Git
  3.0.
* Peff: very few people run "next"
   * Jonathan: True. Could imagine some % of GitHub Actions runners
     automatically running "next", that's the kind of thing that gets a
     more representative workload.
* Toon: do we want to have maintenance releases?
* Emily: if we're dropping support for earlier versions, we should just
  do it.
* Taylor: we should probably have a few supported release tracks that we
  designate as LTS releases.
* Patrick: For security issues only, probably for a period of 1-2 years.
* Peff: Should we write this up as a plan for the person who actually
  does release engineering?
   * Taylor: I can write up that plan, and be the point person for the
     LTS releases.
   * Jonathan: the Linux kernel has dedicated maintainers for LTS
     releases, which seems to work well.
* brian: we can certainly tell that to Junio, but it's also ultimately
  their decision.

Taylor Blau <me@ttaylorr.com> writes:

Please discuss these on list. Removal of http walker (both for fetching and pushing) you have my blessing ;-)

You remove show-branch and you will stop seeing "What's cooking" ("git show-branch master $branch1 $branch2 ..." is used as a way to find the commits on each topic branch in flight, instead of running "git log master..$branch" N times).

Yes.

Good.

Yes.

Not exactly (see my recent comment on feature.git3 on the list---we need a good transition plan and early adopter opt-in mechanism).

Git and Software Freedom Conservancy ====================================

(moderator: Taylor; notetaker: Patrick)

* Taylor: Sent out new mail to the list with SFC activities.
   * https://lore.kernel.org/git/Zusxcweod1O88h7j@nand.local/T/#t
      * LOTS_OF_MONEY spam alert
   * Generally have more money in our account than we know what to do
     with.
   * SFC consists of 4 persons: Junio, Taylor, Ævar, Christian
* Taylor: Trademark discussion
   * Enforcing the trademark is untenable because there are so many
     projects out there using "Git". We cannot go after those to defend
     our trademark, and would also not be in the spirit of the Git
     project.
* Taylor: Money
   * We've got a large amount of money for an OSS project with few
     expenses, $90k USD.
   * Heroku is our biggest expense at $60 USD/mo.
   * What can we do with this money?
* Chris: Mentor Outreachy this year, we'll likely have to sponsor them.
   * $8,000 USD/student. GitHub can probably cover one or two such
     students.
   * GitLab sponsored last year, but getting funding was taking a very
     long time on their side. John probably doesn't want to repeat the
     process again due to the hassle.
* Jonathan: Git gets money due to GSoC, too. These kinds of mentoring
  projects are things where it's easy for donors to justify giving.
* Chris: We do get money indeed due to the GSoC mentoring.
* Chris: We have tried to sponsor travels for GSoC students in the past
  to come to Git Merge. Was quite easy to do that with our funds. Covid
  restricted that somewhat.
   * Students used to have problems acquiring a visa, creating a catch
     22 because we had to book the flight up front, but it wasn't yet
     clear whether they'd get the visa. BUt without the flight, they
     wouldn't get the visa, either.
* Peff: THe wasted money on that is probably small enough compared to
  how much funds we have, so the risk is comparatively small.
* Jonathan: Do we have a rough estimate around how big yearly influx
  minus expenses is?
* Taylor: The exact year is $93k USD. It's hard to tell exactly due to
  changes in reporting by SFC. Last year it was roughly $89k USD, so
  only up ~$4k.  Typically we have a yearly income of around $10k-$20k
  USD/yr.
* Peff: if you want something, would be relatively easy to run a
  fundraising campaign for Git
* brian: I'm sure that we can easily raise additional money via
  individual contributors, too.
* Jonathan: If we have the money for it, I think it might be relatively
  easy to justify hiring a full-time community manager for the Git
  project, for example.
* Peff: 90k is a high amount of money to do small things, but it's not
  really enough to actually sponsor full positions for an extended
  period of time.
* brian: True. Nobody is going to work for you without insurance, so it
  indeed isn't all that much money indeed.
* Jonathan: Edward Thomson also mentioned that libgit2 passed on some
  money to other projects that can use it better
* Emily: also wanting to spend money on contracting on particular
  projects
* Brian: there are people who do contractor work like this. I just don't
  know whether we can find somebody who is willing to accept taht little
  money.
* Emily: Developers are expensive, tech writers are a lot cheaper. Would
  that be a viable option? They could for example rewrite lots of our
  documentation.
* Johannes: We could delete obsolete documentation!
* Patrick: I tried to do this on the GitLab side, but it never really
  worked out. They didn't want to join the Git mailing list.
* Emily: Same.
* Mark: There would be some concern about having tech writers interact
  with the mailing list flow.
* Peff: Ævar is not active on the PLC anymore for a long time. Should he
  be removed?
* Taylor: We've been talking about that in the PLC. There are two
  options:
   * EIther remove him without replacement, such that we have three
     people on it. That would also make it less awkward when it comes to
     voting ties.
   * If we replace him, it would almost happen to have to come from
     someone who isn't affiliated with a large forge / company. We
     already have representation from GitHub, Git Lab, and Google, so
     would want an OSS contributor not affiliated with a major company.
   * Ideally I would like him to come back, but haven't been able to
     hear from him whether or not he is interested in doing so.
* Michael: The trademark was originally owned by GitHub?
* Peff: The git-scm.com web site was originally owned by Scott, was then
  moved over to SFC. The SFC applied for the Git trademark, came to an
  agreement with GitHub about details of how it would relate to the
  GitHub trademark.
* Michael: Is there any obligation of Conservancy to GitHub that the
  trademark is enforced?
* Peff: No.
* Michael: Background is that the proposal was to stop enforcing it. SO
  the question is whether we have to due to an agreement.
* Johannes: You lose the trademark if you don't enforce it in many
  different countries, so we either have to or don't and may thus lose
  it.
* Chris: We mostly enforce it by privately emailing e.g. website owners
  that use Git in a way we don't agree with. So we do enforce it as
  necessary, even if it only happens very infrequently. Some companies
  do not register a trademark that's conflicting, but they still try to
    use it.
* Jonathan: I think it would not be a good choice to not be assertive
  about the trademark at all. On the other hand, filing lawsuits against
  low-harm cases doesn't seem like a great use of time and money. So I
  feel like the current balance is sensible.
* Peff: SFC's lawyers might disagree with that assessment.
* Taylor: They want to see some new version of the trademark where we
  e.g. only enforce our trademark on the logo.
* Chris: We raised the question a couple years ago of what to do about
  the trademark, and folks basically agreed with the current way of how
  we handle it.
* Brian: Debian has a trademark policy that might be sensible to have a
  look at for inspiration. It e.g. says that you have to communicate
  truthfully.
* Peff: We have similar stuff like that in our policy. The problem is
  that back when writing it we had another company that was trying to
  use the trademark for a "shitty" reimplementation of GIt, and we
  didn't want that. We don't really care for "git-foo". Dashed commands
  are explicitly allowed. GitOxide is e.g. technically against the
  trademark policy due to being CamelCased, but we are fine with it.
* Taylor: We cannot do that, we have to consistently enforce the
  trademark. It needs to be very strictly defined what is and is not
  okay.
* brian: it needs to be definitive whether you're doing the "good" or
  "bad" thing.
* Jonathan: It might be interesting to tie this to compatibility with
  the Git test suite. SO if you pass it you are allowed to use it,
  otherwise not.
* Jonathan: So IIUC, we have questions for the SFC lawyers because we
  canot really answer a lot of the questions?
* Chris/Taylor: We can do that.
   * Taylor: We will talk offline to figure out who does what.

How to attract new contributors? + Community Discord =====================================================

(moderator: Jonathan N + Calvin Wan, notetaker: Emily)

* jonathan: we talk about this a lot 🙂 let's avoid the common pitfall
  of catering to the tiktokkers and the youths (hypothesizing about
  "current generation"):
* but, our contributor base isn't representative of our user base
* and our current contributor base doesn't reflect exactly the skills
  needed to improve git - like interface design is not our strong suit.
  how to attract people who are better at our weak spots?
   * taylor: this weakness is an existential problem for Git. jj,
     gitbutler, gitkraken, etc
   * mark: +1
   * peff: one size doesn't fit all, us deciding not to include a GUI is
     understandable, but workflow improvements like jj's are pretty
     interesting
   * jonathan: ex. in hg there's someone very involved in UX review. we
     don't have someone like that
* missing other disciplines - tech writing, product management, UX
  research, etc.
   * common problem in open source but would be cool if we could get
     good at attracting/retaining these people - and cool for the
     not-eng-discipline people
   * patrick: we could adopt a style guide or guideline but we still
     wouldn't be good at enforcement
   * john: people need to know what they can contribute to - cf. project
     tracking discussion later on
* jonathan: instead of trying to guess - can we think generally, how do
  we make work easier to approach? how can we lower the barrier to
  entry?
* patrick: someone is writing third-party rewrite of gitglossary. huge
  improvement over what we have, well made, but the person didn't want
  to come back to contribute. was afraid of the community giving
  pushback
   * patrick was willing to handhold this potential contributor, but it
     didn't seem like enough to make this person comfortable
* jonathan: related to community discord server - what does it mean to
  function better as a community?
* calvin: the entry point doesn't need to be discord, but we should pick
  some entry point that lets users contribute other than mailing list
  participation
   * and need to be able to navigate new contributions comfortably
* brian: how to write text that's accessible to non-native english
  speakers, for example? the mailing list isn't great for these kinds of
  changes.
* discord is proprietary, that is sometimes an issue
* moderation on discord is an issue - having an unmoderated discord will
  actually drive away contributors. that means actual dedicated
  moderation
   * balancing between sufficient moderation (list) and ease of use
     (discord)
* patrick: new contributors sending changes but the changes being
  ignored
* brian: git-send-email is a barrier, but so are PRs/MRs in some cases
* jonathan: the localization example is a good one - the translation
  layer is in github, uses a very typical dev workflow, and that's
  working well. there's a strong community there. are there other places
  we can do something similar?
* peff: can we do that with documentation?
   * jonathan: can we have a documentation maintainer? hypothetically:
     we hire a tech writer, and that tech writer acts as the
     documentation maintainer only. curating existing docs, making sure
     docs changes get good reviews, how to attract new tech writer
     contributors, etc
   * peff: can we manage documentation as a subproject that doesn't use
     the mailing list, and make tech writers' lives easier?
      * how to negotiate that with code changes that require doc changes
        is trickier, we'd have to figure out how to do it, but doable
      * jonathan: readthedocs
* jonathan: we don't advertise well that we can accept contributions in
  a different way if people are committed to the improvement
   * peff: sometimes a mentor can "translate" a contribution. Individual
     contributors are already interested in mentoring, do we need
     more/different mentoring?
   * mentoring list isn't working well yet - maybe it's too faceless?
     should we get a list of individuals who want to mentor?
   * taylor: should we literally put photos of the people on the
     mentoring list up somewhere? "here are real humans, they will reply
     to you on git-mentoring@"?
   * jonathan: in-person meetups help with this. emailing is
     transactional, but e.g. python meetups are interactive
* patrick: we had the git berlin meetup a few months ago, lot of people
  came, we did lightning talks and user conversations. it worked well -
  let's use that model more
   * taylor: hey, we can help spend money on that
   * brian: those are cool but for example, houston linux users group is
     quite small. meetups like this can be helpful, but it's not the
     only source.
   * peff: it doesn't really scale up. python users group are
     user-to-user, doesn't necessarily draw python project contributors.
   * nasamuffin: Gerrit has a community meeting once/month, should we
     use discord for f2f video meetups?
   * peff: if people want to do big group meetups great. we could also
     use it for 1:1 meetups that way, and advertise that it's an option

Taylor Blau <me@ttaylorr.com> writes:

Would money solve these, e.g., by hiring somebody?

The issue would be how to find somebody good ("known to be good with past track record" would be a bonus) and ensure that the community trusts the choice they make and the output they produce, in the areas like UI design or tech writing, that we know are not our strong points. Would we be able to give them enough freedom to produce their best product, yet be able to stop them if needed when their output turns out not so good as we hoped initially? Are we equipped to fairly evaluate their output?

It is not "discord" per-se, but lowering the barrier to entry would mean you'll get more people with different background and different idea of what is normal to deal with.

Paraphrase.  More patches written, not enough are reviewed.

There needs to be a mechanism to ensure the technical correctness of the result to replace the public reviewing on the mailing list for the above model to work.

Sounds like a good way to make it easier to link names with faces.

Taylor Blau <me@ttaylorr.com> writes:

I guess I would fall into the "youths" category ;)

I started contributing about a year ago although most of my activity was during the GSoC'23 period.

I don't know if we get new contributors complaining about our workflow being centered on the mailing list but I personally find the list really intuitive to work with.

Even if we do eventually move towards a more "user-friendly" interface _for_ new contributors, they may still need to read through history for certain changes they maybe working on, ON the list.

I do remember the time when I first contributed and was anxious about the reply but I guess even if someone else doesn't review a particular patch, Junio gets around to it eventually (which is not ideal, we want more reviewers...) so they are not completely lost... everytime.

Although it would be great if there was some kind of an interface to say that this patch is a new contribution to anyone going through the messages similar to what Calvin said above. So that if the patch were simple enough then maybe some of the newer contributors may also have a go at reviewing the patch.

I think the main barrier is the configuration of git-send-email rather sending the patches themselves. Since most people have gmail accounts, the setup becomes a pain because of the two-factor-auth and creating app passwords and for someone who is mailing a minor change, this indeed feels like a lot of effort not worth the time or energy.

I think having mentors would be great thing.  Even if it is not 1:1.

Another thing that would be great is having a list of things on which a new contributor could work on. GitGitGadget's issues used to do this by tagging the appropriate issues "good-first-issue" but I guess it is not properly maintained anymore.

I know there is also searching for "#leftoverbits" or "low hanging fruit" on the list but the "good-first-issue" tagged issues on GitGitGadget are probably more new-contributor-friendly than whole email threads.

I think we hit on this topic last year too in the virtual contributor's summit and I agree that having a regular meetup would be great and something I personally would very much look forward to. This would also help put faces to names.

Not exactly a regular community meeting but Review Club was kind of a large step towards this I guess. I was exactly in one review club meeting and it sadly got shutdown right after that :').

Kousik Sanagavarapu <five231003@gmail.com> writes:

True.

Yes, even with these search terms, finding an issue to work on from the mailing list archive would not be suited for an absolute newbie for four reasons.

 * Anybody can write "low hanging fruit" in their message.  Such a
   label added by somebody without understanding the issue would
   lead readers in a wrong direction.  These phrases need to be
   reserved for a case where the person who adds _know_ they can
   solve it themselves fairly easily if they dedicated time on it
   for a few days but deliberately chooses to leave it on the table
   unsolved.

 * "#leftoverbits" is just that---a direction we could explore in
   the future, and the journey that goes in the direction is limited
   to a short and trivial one.

 * Both labels are opinions of the author at the time of writing.
   It may turn out that what was thought of as a "low hanging fruit"
   is not all that easy, and it may turn out that what was labeled
   with "#leftoverbits" would not lead to a productive direction
   after somebody actually tries.

 * And the list archive by its nature will show hits for ideas
   marked with "#leftoverbits" and/or "low hanging fruit" that have
   already been fully explored, and those who completed the task may
   not reference to the original message that inspired them in the
   References: header, so the archive search cannot show that the
   task is completed already.

We could improve the situation for all of the above four downsides by making it a collective habit to follow-up these messages with "#leftoverbits" or "low hanging fruit" in it, if the situation changes, but your "whole email threads" comment still applies.

Unless we make a habit of sending a separate message with such markings in which we summarize the discussion, that is.

#leftoverbit. Perhaps one of the how-to documents that describe the project workflow (i.e. my first contribution, how to review patches, etc.) can mention the best-current-practice to encourage such use of these tags? Something like

 - When you mention a good idea that is not squarely inside the
   theme of the current discussion, instead of adding "#leftoverbit"
   mark in the message, write a separate message as a follow-up to
   the message and summarize the issues and idea in such a way that
   people who later looks for a message with such a mark can grok
   the idea by the message alone, while still allowing them to learn
   more about the backstory by going back in the discussion thread.

 - After you find "#leftoverbit" message and worked on it (either
   you produced a patch series, or you failed and know why the idea
   described in the #leftoverbit message does not work), make sure
   you mention the original "#leftoverbit" message's message-id in
   such a way that a person who found the "#leftoverbit" message can
   find your message.  Sending your patch series as a reply to such
   a message would be the easiest way to achieve it.

or somesuch, perhaps.

Anybody motivated enough can take initiative to reignite the Review Club; you do not need permissions from past hosts to do so.

Quite honestly, I sometimes failed to find much value in the review these meetings produced, and I suspect it was not due to lack of preparation on participants' side, but was largely due to the fact that the face-to-face meetings cannot go to sufficient depth in technical conversion in a single sitting.

It might have been more productive format if it weren't "let's critique this series on the fly". For example, it could instead have been "There is an excellent reviewer-contributor exchange thread on the list. Let's read these exchanges together and learn how to effectively convey the idea from the original author's side, and idea for improvements from the reviewer's side". I dunno.

There however was a lot of value in the mere fact that people had a face-to-face discussion on something, anything, that was related to the project.

Thanks.

Junio C Hamano <gitster@pobox.com> writes:

Correction.  "is limited" -> "is not limited".

Correction.  "conversion" -> "conversation".

On Sun, Sep 22, 2024 at 12:15:22PM GMT, Junio C Hamano wrote:

I can chime up and offer bugspray bot integration for the list. This is a new tool I've been developing for integrating the mailing list with bugzilla. I've been using it on the tools mailing list over the past year with reasonable success.

It works something like this:

- a mailing list thread can be turned into a bugzilla entry by saying a
  trigger phrase like "bugspray track" or "bugspray tag <person>". This
  converts the entire existing thread into a bugzilla bug entry and makes the
  bot follow the conversation, adding any new mailing list messages to the
  bug. This is a two-way bridge, so someone can add things like large debug
  dumps or other files to the bug and have a notification about that go to the
  thread participants. Here's an example of a bug created from a thread using
  the "bugbot assign to me" trigger phrase:
  https://bugzilla.kernel.org/show_bug.cgi?id=219230

- the opposite also works: a bug created in bugzilla becomes a mailing list
  thread. Here's an example:
  https://bugzilla.kernel.org/show_bug.cgi?id=218821
  and here's a thread it created:
  https://lore.kernel.org/linux-mmc/20240922-b218821c6-a6dc79e2a03f@bugzilla.kernel.org/T/#t

- git commits are also able to close bugs via the Closes: trailer. E.g. here's
  one example:
  https://bugzilla.kernel.org/show_bug.cgi?id=217359

The bugspray bot integration is significantly different from Bugzilla's native email support. The goal was specifically to not require bug participants from creating a bugzilla account in order to be able to participate in the discussion.

Bugs can, of course, be easily queried, assigned, and tagged with keywords that can be filtered.

Bugspray is still in early development, but I plan to continue expanding its set of features, because we hope to make bugzilla actually useful for kernel bug reports.

-K

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

Intriguing. Everybody loves to hate bugzilla, but would bugzilla become less smelly with bugspray enough to make it palatable to all of us?

;-)

On Mon, Sep 23, 2024 at 02:31:07PM GMT, Junio C Hamano wrote:

I'm happy to enable it for this list if you'd like to try this out. It doesn't really create any obligation to use it, but it may end up being something useful.

To enable it, I only need a list of people who are allowed to trigger bugspray via the "bugspray track" trigger phrase. I assume it's going to be more than just you?

-K

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

Now we'll have to come up with and maintain an official list of trusted contributors. Which at first may sound like such a list may alianate those who did not make the list, but when deciding which topics are ready to hit 'next', such a "selection" is implicitly made to choose whose opinion weigh more anyway.

It might make the process more transparent to formalize the "more trusted contributors" list.

I suspect that the list of folks who can operator bugspray do not necessarily have to be with deep technical knowledge of the innards of Git. They have to be able to dedicate the time to read and understand what was said in the discussion threads, recognise when a problem is identified ("bugspray track"), have been long enough to know or able to use "git blame / git log" to see who likely has useful insight into the issue than others ("bugspray tag"?), and have good enough taste to recognise irrelevant "bugs" that are opened by those with worse taste. In a sense, it is very different from the earlier "list of those whose opinion weigh more in assessing topic's doneness". Competent "project secretaries" are the kinds of people we want.

If I misunderstood the nature of "allow-list" for trigger phrase, please correct me. Also it would be very welcome to hear from those listening in from the sidelines who want to see different kinds of people to be on the trigger phrase list.

Thanks.

On Tue, Sep 24, 2024 at 12:15:13PM GMT, Junio C Hamano wrote:

Yeah, you're overthinking this. :) I literally just want to restrict the ability to invoke bugspray to a limited number of people, at least for the time being -- to avoid a situation like a troll sending "bugspray track" to every possible thread.

The people on this list don't have to have any kind of official standing with the git project itself.

FYI, "bugspray tag" assigns the bug in bugzilla to a specific person. If you don't intend to use bugzilla to this degree, you can ignore this aspect of it entirely and never use the tag command.

Hopefully, I clarified it a bit. Also, bugspray is still an early model, so I am happy to add functionality based on the feedback I receive.

-K

On 23/09/2024 22:31, Junio C Hamano wrote:

If it's easy to set up it might be worth a try. My memories of using bugzilla in the past are that it wasn't too bad for issue tracking. Most of the pain came from trying to use it to review patches which we wouldn't be doing.

Best Wishes

Phillip

Phillip Wood <phillip.wood123@gmail.com> writes:

The biggest pain point I remember with bugzilla was to find bugs that are still relevant to make sure they are assigned to somebody. IOW, curating the collection to make sure false alarms are marked as such quickly enough.

Thanks.

On 27/09/2024 20:22, Junio C Hamano wrote:

That's certainly a pain, but I don't think it's specific to bugzilla though. I agree that to be useful the list of bugs needs curating.

Best Wishes

Phillip

Modern Build System ===================

(moderator: Patrick; notetaker: brian)

* Patrick: three different build system; should get rid of at least one
  of them
  * Should delete autoconf because it's not really maintained
  * Think about a proper build system
  * Obvious choice: cmake
* Taylor: What's the problem with Makefiles
* Patrick: Non-standard
  * Meson is nicer than cmake as an alternative
* Jonathan: xz compromise shows autoconf is a risk
* Autoconf isn't a problem for distro
* Taylor: distro builds that can't handle "make" without configure are a
  distro problem
* Jonathan: Modern build system can reflect the structure of how your
  code is set up
  * Declared dependencies
* Brian: Rust will make the decision for us: cargo
  * BSDs use Make (granted, not GNU make) for building
* Patrick: Is anyone else in favour of a proper build system
  * Ninja is way faster than make to build the projects
* Taylor: Feels odd to build with a fancy tool that might have a
  dependency on Git
* Dscho: --help is a autoconf feature and removed features are detected
* Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes
* Kyle: Editor integration is useful
* brian: standard structure is helpful for LSPs
* Emily: libification has shown that makefile is cumbersome
* Jonathan: Should we do a comparison of build systems in terms of what
  we need from them on the list? Similar to
  Documentation/technical/unit-tests.txt
  * Patrick: I can write such a thing.
* Patrick: Are their any features we need to consider?
* Johannes Sixt: Consider supported platforms
* Patrick: Want to verify that cmake is up to the task by testing in CI?
  * Will volunteer to post something to the list

On 9/20/24 10:21 AM, Taylor Blau wrote:

I suppose I'm pretty biased but yes, I do feel we (meson) have managed to make some great workflow improvements here. :)

Please do feel free to ask me questions about it.

Anyone can handle "make" without configure without breaking a sweat, that isn't even remotely challenging, and every distro already does it. The problem is that "make" is stateless, which is another way of saying it has amnesia. By that token, everyone cobbles together their own state system on top of "make".

Admittedly, once set up it doesn't require much maintenance from version bump to version bump.

I would just like to note that this is not really true. There is one other build system that supports rust and its name is... meson. :)

Meson supports rust as a language for creating libraries (cdylib or rlib) and executables. You can import a crate from crates.io and meson will synthesize the build system from the existing Cargo.toml to expose it as an rlib dependency.

You still get full build script option parsing, system probing, control flow etc using the meson.build DSL, you can freely mix libraries or executables in any of meson's supported languages (C, C++, Cython, C#, D, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands for data files, run gettext on translations, and more. Meson is designed to be a polyglot build system in ways that cargo will probably never be.

Cargo is probably best thought of as a compiler wrapper: it can spit out an executable if you run it on *.rs sources, but it doesn't replace most of the interesting parts of a build system and it doesn't even provide an "install" rule. No, `cargo install` does not count unfortunately as it has a nasty habit of recompiling the binaries you already compiled, but now with the wrong options.

You really want something that provides a project lifecycle workflow for building, testing, installing, and making dist tarballs with integrated distcheck. The current Makefiles mostly kind of work, given sufficient care, but cargo provides exactly zero of anything so you're back to cobbling together your entire workflow using Makefiles wrapped around cargo. I would call that the very furthest opposite from "make the decision for us".

It is! Yes. Mostly because it does very, very little other than execute a precalculated build graph, whereas the current Makefile runs a bunch of stateless external commands each time in order to calculate top-level Make variables.

cmake does not have an equivalent of ./configure --help. The best you can get is to try to somehow successfully configure cmake once, and then run a cmake command that prints every internal control flow variable used by cmake, then hope that the ones you care about include descriptions.

(Say what you will about GNU autotools but they knew very well how to write good interaction standards, as evidenced by all the Makefile variables git.git already uses from the GNU Coding Standards docs on how to architect a release process.) It is fundamental to the UX design of ./configure that a user may query the build system to find out what choices they can / are expected to make, before committing to those choices.

cmake is actively a severe regression compared to autoconf for these purposes.

These tend to mostly be solved by compile_commands.json, which most modern build systems can produce. In particular, anything that creates a ninja file essentially gets you this for free, because ninja can create one for you.

Plain Makefiles, and GNU automake, don't do very well at this at all, since Make has too irregular a build graph to reliably compute any such thing. Same reason why there isn't much in the way of dedicated editor integration (both cmake and meson have introspection APIs which editor plugins can use to directly query info from the build system, to provide finer-grained control than what compile_commands.json can do).

On Sun, Sep 22, 2024 at 10:01:32PM -0400, Eli Schwartz wrote:

Thanks for your input, Eli, I highly appreciate it to get feedback from a distro maintainer's point of view! I'm not going to answer here, because there already is an ongoing thread at [1].

So I'd propose to consolidate it into that thread. I've put you into Cc there.

Patrick

[1]: <GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com>

Bundle-URI on fetch / resume-able clone =======================================

(moderator: Toon; notetaker: Taylor)

* Toon: we have bundle-uris, which allow us to download bundles before
	cloning. What would it take to do them on fetch, too?
* Toon: Complex; you might end up downloading a lot of bundles that you
	don't need.
* Toon: there was a bundle token that could be used by the client to
	determine whether or not it needs the bundle. Unfortunately, since you
	don't know what amount of history you're missing, the bundle in and of
	itself may not be sufficient.
* Toon: How do we make bundles more efficient on fetch and aware of what
	the clients do and don't have.
* Johannes: In VFS for Git, the set of bundles is "opinionated" and
	regenerated often (e.g., weekly, daily, hourly, etc.). We don't really
	care about oversharing, because it's fast enough to download those
	static files.
* Toon: That's true for the server, not for a singular client.
* Johannes: right, but it's to protect the server. If you don't care
	about having too-big of a bundle, it's OK because you can just fetch
	the last hour and then see what you still need on top of that.
* Johannes: there is logic to determine what you need to download based
	on the time that you last fetched, etc.
* Elijah: are they thin packs? Yes.
* Patrick: the heuristics that we have to advertise what kind of bundles
	are on the server is not sufficient enough to determine which bundles
	the client may or may not want to download. The client must guess.
* Jonathan: ISTM that the property list for the bundles as they are
	today should probably be considered a starting point (as in "part of a
	feature"). The heuristics need to be extended.
* Jonathan: at Google we use packfile-URIs, and one of the advantages of
	how that works is that since the packfiles are advertised after the
	normal fetch negotiation, you get a curated list. For bundle-uris,
	need something analogous to the fetch negotiation for the client to be
	able to make a similar decision of which bundle to download.
* brian: extending the feature to store timestamps, then you could store
	the last fetch on the system would inform some better selection of
	which bundles to clone down during a fetch.
* brian: Would make a big difference for folks in environments which do
	not benefit from reliable Internet connections.
* Toon: Sure... but you have to put a lot of pressure to keep those
	bundles up-to-date on the server side.
* Jonathan: one of the advantages of bundles over packs is that they
	have information about the references. One potential property could be
	"here's the length of this header" and then having the client download
	it to examine whether or not it wants such a bundle.
* Patrick: probably would want to cache those on the client so that
	we're able to avoid re-downloading these every single time.
* Toon: resumability
* Jonathan: protocol supports it, just hasn't been implemented. Someone
	needs to just get it done. :)
* Beyond that, the main complication is how you store the state and what
	the UX is for resuming. But a person implementing it can figure those
	things out.
* Brian: broken-proxy situations require some configurability of where
	your bundles can be downloaded from.

Project Tracking ================

(moderator: Emily, Patrick; notetaker: Taylor)

* Emily: Patrick and I were talking about roadmap-like things sometimes
  this week. It would be nice if we had a list of projects that the
  community has agreed are good ideas. For e.g., “generally we are
  working on getting rid of ‘the_repository’”.
* Emily: We have agreed that libification is a good thing, so anytime
  that someone sends a patch in that area it isn’t up for discussion
  whether or not the patch is fundamentally going in the right
  direction.
* Emily: It would be cool to have a list of agreed-upon things. I also
  think that we should get better at figuring out what we agree on.
  I.e., the status-quo is argument on the list until quorum, and would
  like some kind of more structured way to determine when we are in
  agreement.
* Jonathan: When you say “predictable process”, what does that actually
  mean? Python has PEPs, they have a very clear state machine that
  stringently dictates the process.
* Emily: probably not something that strict, but would like to generally
  be able to tell “is it going in the right direction?” And
  approximately, “Approximately when will we be able to tell when it’s
  done?”
* Taylor: how do we quantify that? A lot of what developing consensus
  looks like is developing patches and then sometimes throwing them away
  if/when we find a fundamental design bug, etc.
* Patrick: “Are we going to do it?” is when something like a brief RFC
  is merged.
* Taylor: Is the Git 3.0 deprecation doc a good example?
* Patrick: Yeah.
* Patrick: We would also want to have a document with a little check
  mark indicating when we are going to do small things like clean up
  memory leaks.
* Jrn: The pain point is being able to know when making a proposal how
  much support they have.
* Taylor: Sometimes implementation clarifies one’s thinking.
* John: We have some tribal knowledge on what is accepted in which
  areas. Can we codify that?
* Patrick: The BreakingChanges statement says that we can change things
  on the document if there is new information. I’d like to see that this
  statement is echoed elsewhere.
* Taylor: It feels like it would be more useful to have a discussion
  based on a WIP or PoC (e.g. UNLEAK() and FREE_AND_NULL()).
* Peff: I don’t want people to produce patches, say, if we blessed unit
  tests, and then consider that discussion immutable. That doesn’t give
  us the opportunity to make changes to the fundamental design. I don’t
  want to use it as a cudgel to shut further discussion down.
* Jonathan: “I guess I am going to argue in favor of cudgel.” Taking
  unit tests as an example, if someone later says “I don’t see any value
  in unit tests”, that’s not very productive. If they say “I see the
  value of unit tests, but not at this cost”, it’s a more worthwhile
  conversation.
* brian: Maybe we can only use that as an argument for 4-5 weeks. Having
  some disagreement is fine, just don’t want to make it indefinite.
* Peff: On PEPs. Often someone will say “I’m going to go in this
  direction”, and I’ll feel mildly negative about it. That’s very
  different from voting against something.
* Emily: Sure, there can be more voting options than just
  yes/no/abstain.
* Jonathan: Apache does a nice job with +/- 0, +/- 1
  (https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions)
* Emily: we should be better about saying generally how we feel about
  things at the end of the series).
* Taylor: Taking a step back for a moment, what are some examples of
  things that are going wrong that need to be changed? What is wrong
  with the project here?
* Emily: things are taking too long.
* Emily: Goal-posting moving, etc.
* Johannes: Yes, that can be very frustrating and cause a lot of
  friction.
* brian: When you do creative work, you get feedback and sometimes you
  take it and sometimes you don’t.
* Taylor: at the risk of repeating what brian said, it’s hard/impossible
  to please 100% of reviewers on 100% of series. At some point you have
  to step back and let the maintainer evaluate.
* Jonathan: I think the point of Patrick’s proposal is “how do you go
  about navigating this with a 10-series long project?” Then you’re in
  trouble. The proposal would allow you to check in a bullet point, or a
  design doc, and go through that process and navigate to the point
  where you get the maintainer’s blessing and the conclusion is checked
  in.
* brian: Maybe a bullet point is too small for some things.
* Taylor: so it’s a continuum, sometimes you are going to save time by
  just writing the patches, sometimes you are going to save time by
  writing out what you are doing (over a multi-series effort) first.
* Patrick: discoverability!
* Mark: could we encourage newcomers to email one of a few people for a
  particular effort (like libification) and have them comment on it?
* Taylor: you might not want to centralize that much power.
* Toon: How about structured errors? We agree it’s a good idea, but not
  on the mechanism of implementation.
* Patrick: Sure, sometimes that just takes time. We don’t have to
  document how to fix them (maybe how to find them, but I digress).
* Patrick: For structured error handling, it should be more involved. It
  makes sense to have an RFC or design document that documents how it’s
  supposed to look like.
* brian: or an initial patch series that comes up with a design.
* Peff: In our project, the formalism of voting is “is it merged to
  ‘master’ in Junio’s tree”.
* Emily: I want to have the process of getting from discussion to merge
  be less fuzzy.
* Peff: So in brian’s example, let’s take SHA-256. The process by which
  the maintainer decides that is inherently fuzzy.
* Emily: Sure, but I would like to be obvious to someone besides the
  maintainer.
* Jonathan: (to Peff) you mentioned sometimes you have a mild negative
  feeling about something and you’re good about expressing it on-list,
  but for a lot of contributors that will cause some discomfort and it
  will cause them to stay away from that thread. If we’re a little more
  clear about what’s expected, then conversations can get stalled less
  often - e.g. when a thread needs a comment from a refs expert, getting
  that comment that supports forward progress.
* brian: I just gave Taylor feedback on the SHA-1 series that he wrote,
  saying that I didn’t love it. But others felt OK about it, so we moved
  forward.
* Emily: strawman doc:
  https://github.com/nasamuffin/git/commit/54079ab00002c6dfa7ac1a33d9810792978d2cce
  - maybe it's bad enough we can poke holes and salvage something we do
  like
* Peff: it’s important to leave at the end of your review the way you
  feel about something instead of just having a few comments.

Taylor Blau <me@ttaylorr.com> writes:

Graduation from 'next' to 'master' is mostly mechanical "spend 1 calendar week and you are done", so 'next' matters a lot more.

FWIW, this also is fuzzy for the maintainer, especially when not many people who ought to know a lot more than the maintainer are staying silent.

Yes, either forward or backward. Having to keep a series that looks potentially worth doing for weeks on 'seen' without getting any movement is *VERY* painful. Would it motivate more experienced contributors to review and express either support or refusal if I more frequently, say after 20 days since its latest round got queued on 'seen', a topic that does not seem to get enough support to be merged to 'next' and is not getting rerolled?

For this particular one, I consider it is not "we moved forward", by the way. Please do not consider anything that is not marked with "Will merge to 'next'?" (with or without the final '?') moving forward.

Yup, that would clarify area experts' position on topics and would help everybody a lot. It would also help me when updating the "What's cooking" draft, which is how the topics currently in-flight are getting tracked.

Thanks.

Junio C Hamano <gitster@pobox.com> writes:

Missing verb was "discard". Instead of keeping the stalled topic, perhaps I should more actively discard them (people are allowed to send in a fresh iteration if they care enough)?

Sorry for the noise.

On 20/09/2024 20:41, Junio C Hamano wrote:

Taylor - thanks for posting these discussions

I think that sounds reasonable. Sometimes I'm quite slow to review but if I haven't managed to do it within 3 weeks I'm unlikely to get round to it. I'm also sometimes slow to re-roll if I'm ruminating on the best way forward, but even if a patch series gets dropped there is nothing stopping the contributor from re-rolling.

Best Wishes

Phillip

git-scm.com state of the site =============================

* Johannes: worked on a static site version of git-scm.com.

(Johannes: demonstration)

* Peff: let’s move it over.
* Taylor: AGREED