{"thread":{"id":"62154","subject":"Notes from the Git Contributor's Summit, 2024","startedAt":"2024-09-20T14:16:04Z","lastAt":"2024-10-01T15:23:53Z","messageCount":38,"participants":["Taylor Blau","rsbecker@nexbridge.com","Junio C Hamano","Kousik Sanagavarapu","Eli Schwartz","Sean Allred","Phillip Wood","Konstantin Ryabitsev","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"503127","messageId":"Zu2DmS30E0kKug2a@nand.local","threadId":"62154","inReplyTo":null,"subject":"Notes from the Git Contributor's Summit, 2024","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:15:53Z","receivedAt":"2024-09-20T14:16:04Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"It was great to see folks at the Contributor's Summit today during Git\nMerge!\n\nThe notes are available (as read-only) in Google Docs, too, for folks\nwho prefer to view them there are the following link:\n\n https://docs.google.com/document/d/1IZvW1_pnkrMMWnBmZO2MbT4QCjIPJBWNJg_shYqSnrE/edit\n\nAt the Contributor's Summit, we discussed the following topics:\n\n - Rust (Kyle)\n - Top-level lib/ directory (Patrick)\n - Structured Error Handling (brian)\n - Platform Support Policy (Emily)\n - SHA-256 / Git 3.0 (Patrick)\n - Git / Conservancy Stuff (Taylor)\n - How to attract new contributors? + Community Discord (Jonathan N. /\n Calvin Wan)\n - Modern Build System (Patrick)\n - Bundle-URI on fetch / resumable clone (Toon)\n - Project Tracking (Emily / Patrick)\n - git-scm.com state of the site (Johannes)\n\nI'll send the broken-out notes for each topic in a response to this\nmessage for posterity, and so folks can continue the discussion on the\nlist.\n\nLike in previous years, if you have any feedback on how the\nContributor's Summit went please feel free to share it with me here, or\noff-list.\n\nI hope to see everybody in person next year!\n\nThanks,\nTaylor\n\n"},{"id":"503128","messageId":"Zu2D/b1ZJbTlC1ml@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 01/11] Rust","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:17:33Z","receivedAt":"2024-09-20T14:17:38Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Rust\n=====\n\n(moderator: Kyle; notetaker: Taylor)\n\n* Kyle: Rust code in the Git project; do we want it? Why would we want\n it?\n* Elijah: Anybody other than Randall that objects to it?\n* Peff: I don't object, but what does it mean for existing developers?\n Will non-Rust developers need to start learning?\n* Emily: The avenue for introducing Rust is replacing low-level C\n libraries that are complicated and un-maintainable.\n* Peff: What's low-level? Peff considers strbuf to be low-level, but\n Emily considers merge-ort.\n* Kyle: Anything dealing with untrusted inputs would be a good spot to\n start.\n* Patrick: Instead: take a system like reftables that is already\n self-contained.\n* Jonathan: Another nice thing: if someone is on a platform without good\n Rust support, then they could stll use Git without reftables.\n* brian: Rust is optional, can we add small new features and performance\n improvements that replace existing code, but it's not required.\n* Emily: are we then carrying parallel versions of the same thing? What\n does that mean for the C version?\n* Taylor: I don't want to double our vulnerable surface area.\n* Patrick: Right, either you go all in or don't.\n* Taylor: I don't want to give too much stock to a small number of\n people/platforms and hold the project hostage.\n* Emily: old versions aren't going away.\n* Patrick: Those could be maintenance releases.\n* Do we need to support an older maint version in pure C\n* Backport security fixes? Would issues be in both implementations?\n* Do we want to encourage those without Rust support to maintain a\n friendly fork C version\n* Johannes: Transpile C to Rust?\n* Elijah: Does that presume we're not using Rust libraries, or are those\n transpile-targets as well.\n* brian: We are going to have to use 'std', the question is what\n versions of Rust are we going to support? Can't be the latest version,\n since it only lives for six weeks.\n* Taylor: vague idea of why we would want to use rust, but what are the\n concrete benefits of moving to rust?\n * brian: increased parallelization, can't write unsafe code,\n incremental parsing of objects. When it fails, you get a panic\n instead of a segfault.\n * Patrick: clear ownership semantics, was a huge problem with the\n memory leak work that they have been doing, it's not clear who owns\n what at what time.\n * Jonathan: 3 things; (a) user-facing benefit of memory safety, (b)\n productivity benefit to ourselves to have better architecture makes\n it easier to make changes, (c) would attract new contributors to\n the project.\n * Kyle: that's what I was going to say on (c), writing C is daunting.\n * Patrick: I'm in the opposite camp, I'm scared of Rust!\n* Why not move over to the gitoxide project? Probably not realistic\n within the next 10 years, though Sebastian is doing great work.\n* Taylor: great, what's the transition plan?\n* Patrick: can't start until libification makes progress.\n* Elijah: what about a low-enough level function that we can start with?\n* Patrick: Still not work-able, there are too many global variables that\n we need to contend with.\n* Taylor: IMO better to port to rust first from an implementation that\n we know, then libify in a language that has better support for\n refactoring.\n* Jonathan: likes what Patrick was saying about having modularization\n make this easier. The other obstacle is that if we want to use any\n Rust at all, we need to have a POLICY on how we use Rust.\n* brian: C shared library built in Rust, or top-level build with cargo?\n* Have had experience with a previous C-to-rust migration! C FFI to call\n into Rust from C until everything is ported over.\n* Patrick: modularization should be the first step, otherwise we're\n going to have the same architecture that we have now. If we inherit it\n now, it'll never get fixed.\n* Mark: need Git to continue to be relevant in 10 years, making this\n kind of change is part of that\n* Maintainability is something we can invest in.\n* Emily: governance can help corporate contributors behave better. Say\n \"your contributions have to meet this standard\"\n* Patrick: meanwhile I don't want to push away drive-by contributors\n* Elijah: if someone wants to contribute a specific component in Rust,\n such as a replacement builtin, they need to call C, what happens to\n infrastructure such as option parsing?\n* Emily: I really like the idea of starting with reftable\n* Patrick: I was going to make a Rust implementation of reftable anyway\n"},{"id":"503129","messageId":"Zu2EF2bELvzC4f9s@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 02/11] Top-level lib/ directory","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:17:59Z","receivedAt":"2024-09-20T14:18:03Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Top-level lib/ directory\n========================\n\n(moderator: Patrick, notetaker: brian)\n\n* Patrick: Difficult to find stuff (README, etc); top-level directory is\n cluttered\n* J6t: Clarifies that this is the C and H files\n* Emily: Originally the plan was to move libified files into lib once\n libified\n* Jonathan:\n * Discussion has been present on the list before (in Git 2.0\n discussion)\n * Bikehedding on the list (more difficult to blame)\n * Differences of opinion about lib and include and naming\n * Blame problems, but this is an opportunity to fix that\n * Heart of it: has nonzero costs, needs to have enough benefit to\n offset it\n* Elijah: git apply doesn't handle directory rename\n* Patrick: Bikeshedding not a problem; can be handled\n* brian: Not really hearing an objection\n* Peff: Not a problem for him, but not a really big objection\n* Kyle: Not sure the value here\n* Jonathan: I really love what Patrick said about \"I can handle\n bikeshedding\", I think it's great if you can guide a discussion\n on-list toward a decision on what we want for source layout, how we\n structure code, etc. Exciting!\n* Taylor: improves things, makes it more maintainable/discoverable, but\n takes time away from other things like security/performance bugs.\n Should be done with a healthy balance.\n"},{"id":"503130","messageId":"Zu2EMKMmNhugAcbY@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 03/11] Structured Error Handling","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:18:24Z","receivedAt":"2024-09-20T14:18:28Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Structured Error Handling\n=========================\n\n(moderator: brian, notetaker: jrnieder)\n\n* brian: idea for structured error handling!\n * Very little needed - pointer to error string, uint64_t error code,\n and ?? (third thing I didn't hear). Return it on the stack. Rust\n does this kind of thing all the time.\n * Having that structured return value lets a caller decide what to do\n with it\n - print a message, decide whether to exit or recover, etc.\n* Patrick: a few requirements\n * want to attach arbitrary metadata to an error (e.g. \"I had a\n conflict between that file and that file for this revision\").\n Especially useful on the server side.\n * avoid having to parse error messages. Gitaly runs into this. Can\n imagine setting an envvar to get json or some other parsable format\n instead of human-consumable error messages.\n* brian: sounds doable. GitHub also has the same hassle with parsing\n error messages.\n* Peff: in your proposal, low-level code produces the error struct which\n is consumed at a higher level. Sometimes, though, you have many errors\n that are related.\n * \"I couldn't merge these files because I couldn't open this file,\n because of this errno\".\n* One thing we've considered is having a callback to decide what to do\n * - print the error, collect into a tree of errors, etc.\n * The point is to keep what's happening in the generators of errors\n as simple as possible - I have this type of error and maybe some\n kind of context strings. That context could be owned by the caller,\n the callee can be responsible for copying it, etc. Inversion of\n control.\n* Patrick: I like the way Go does things, can wrap errors or append\n messages, return up the stack until someone handles the error. Why are\n we afraid of allocations?\n * Peff: What do you do when the allocation fails?\n * Patrick: can handle allocation failure by having a special error\n that has a statically allocated string.\n * Peff: sounds good, getting rid of die() on alloc failure is okay\n * brian: Rust panics on out-of-memory anyway\n * Peff: there are two different cases - small allocations are \"you're\n in trouble anyway\", big allocation of user-supplied length is\n something else\n * Carlos: Rust has a \"try to allocate memory\", relatively new\n* Calvin: how do you propagate up the call stack?\n * Peff: in my proposal, every function would take an error context\n struct, call the callback when there's an error, and keep the\n integer function returns. In brian's proposal, we instead return\n the struct.\n * Emily: Are we comfortable with the amount of churn that generates\n in the codebase?\n * Patrick: my inspiration is Subversion in that respect. It has nice\n error handling in C, they're a role model for me in how to do a\n library. It has nice error types that aren't a hassle to use.\n * J6t: if you compile in C++ and use exceptions, the problem has been\n solved 25 years ago.\n * brian: allocating strings for errors and then freeing them is a\n hassle in C. Versus Rust where that's handled automatically.\n * Emily: so it sounds like this is temporary pain\n* Jonathan: I like Patrick's description of requirements. One thing that\n would make me more comfortable with the churn is when we get benefit\n even from partial conversion\n * E.g. could say we get structured error messages for the call sites\n that have been converted and not from others. And when I go on a\n debugging quest and wish I had a machine-readable structured error\n message, I can send a patch to convert more call sites\n * Peff: Refs code uses its own strbuf based error handling which is\n worse in every way than the options we've been discussing. :) That\n can be a good playground to try things out.\n * Patrick: +1, seems like a good place to start.\n"},{"id":"503131","messageId":"Zu2EVvSajL/pUzL7@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 04/11] Platform Support Policy","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:19:02Z","receivedAt":"2024-09-20T14:19:07Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Platform Support Policy\n=======================\n\n(moderator: Emily; notetaker: Calvin)\n\n* Emily: if you want Git to support your platform, you have to provide\n your tests (e.g. provide your own CI test runner)\n * Should we be more explicit about, for example, the version of C\n that one must support.\n* Brian: less-common architectures (e.g. MIPS) sometimes can catch\n problems (e.g. unaligned access) that are not a good practice anyway\n * qemu based CI is so slow\n * netbsd, openbsd, freebsd, probably solaris are up to date with\n modern standards, probably supportable\n * I'm more comfortable with \"you have to have threading and POSIX\n 2008\" than with \"you have to provide a CI runner\"\n* Peff: I'm not sure what people have been counting on\n * Do we have a way to find out what people are using?\n * \"Take a little risk, see who screams\" has worked okay in the past\n but takes a while\n * Rust is probably a big change\n* Patrick: keep in mind that we're at the core of the whole operating\n system, part of the bootstrapping path\n * Emily: yes and no - Git is not just the client, but Git is a\n standard. You can use older versions of Git and clone things from\n GitHub. If we still support the same protocols, I don't think\n needing native git.git CLI support to run on your platform is as\n compelling as new Git being able to support these older standards.\n * brian: OpenBSD doesn't like the GPL, has a project for getting\n trees called \"got\", it's in C and supportable. It can be a valid\n bootstrapping tool.\n * Patrick: The user experience there is a little closer to CVS. But\n it's still an option.\n* Jrnieder: looking from user perspective, Git is the tool people are\n used to for day to day development\n * Emily: There's a difference between using \"a git\" vs using the\n latest version.\n * Jnieder: telling users to use an older version might result in\n users asking questions on the mailing list about those older\n versions, it's also not free.\n * Peff: to be fair, HP Nonstop support hasn't been a matter of\n \"please support me for free\" - the maintainer there has been active\n in helping test and debug things. The question here is not about\n whether to continue that but rather about whether we're willing to\n increase the platform dependencies when it breaks such a use case.\n * Peff: Are we okay with dropping NO_PTHREADS support?\n * Brian: POSIX 2008 shouldn't be that controversial. Neither C11\n should be. We shouldn't take it too far like POSIX 2024, but we\n have to set \"some\" standards.\n * Emily: So next week when we come home we update the \"minimum\n requirements\" on the mailing list, and everybody upvotes?\n * Jonathan: we live in the real world - the spirit of \"let's require\n POSIX 2008\" sounds right, but real-world considerations should\n matter more than the exact text of the standard\n * Peff: example: Android is missing pthread_setcanceltype, which\n leads to Git on Android using NO_PTHREADS\n * brian: it can be enough to pretend to support (compatibility shim)\n* Calvin: is there a threshold % of users for \"unimportant enough to\n break\"?\n* Jrnieder: it depends on the platform. Do the requirements that a given\n platform imposes push us in a good direction in general as a project?\n * For example, Windows is a very non-POSIXy platform, but it has\n nudged us toward thinking about subprocesses in a different way,\n and I think that's been really healthy\n * brian: As another example, Plan 9 is really difficult to support,\n it won't pass the test suite\n * z/OS patches originally came in and were gross. I saw a patch come\n in recently that was more acceptable.\n"},{"id":"503132","messageId":"Zu2EdQs6xf2FRkpa@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 05/11]: SHA 256 / Git 3.0","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:19:33Z","receivedAt":"2024-09-20T14:19:38Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"SHA-256 / Git 3.0\n=================\n\n(moderator: Patrick, notetaker: Taylor)\n\n* Patrick: some of you may have seen some patches from a few months ago\n to start thinking about this, and we now have a \"deprecations\" doc of\n things that we plan to get rid of.\n * One thing going away is grafts\n * Another thing is git pack-redundant\n* Patrick: SHA-256 will become the default object hash, but is\n contingent on major platforms supporting SHA-256.\n* Emily: this helps us too, because it provides some motivation that\n this is going to happen.\n* Patrick: having it in the 3.0 document makes it easier to push at\n large organizations.\n* Jonathan: with partial clones if I understand correctly users were\n already trying it and complained to GitHub about it not being turned\n on.\n * Taylor: not really…\n * Peff: I was embarrassed, so I wrote the bitmap support for\n filtering objects\n * Taylor: yeah, and turning it on was easier, but didn't require\n updating database columns, etc. so the transition period here would\n be much more expensive.\n * brian: \"can you put it in the customer feedback repo\" is something\n customers can ask for\n* Jonathan: could use interop as a way for Git to default to sha256 with\n the only harm to end users being that clones and fetches get slower\n until servers support it\n* brian: not planning on working on it unless their employer pays for\n them to do it.\n* Mark: customers wanting to start with SHA256 so they don't have to\n migrate later\n* Patrick: GitLab never really wanted SHA-256 until it was done on the\n Gitaly side.\n* brian: has definitely seen it on StackOverflow as something that\n customers want. Not a huge selling point right now, but will become a\n humongous selling point at some point (beyond >2030).\n* Peff: if the proposal is to make SHA-256 the default, then we need to\n be developing with it now, and we're not because there is no interop.\n* Taylor: we should do it via interop, (a) because GitHub could not host\n it, but (b) because we would introduce the same lack of testing just\n with the interop code, not the SHA-256 code. So it must be done via\n interop.\n* Patrick: OK, but why do we care about SHA-256 locally if they're using\n SHA-1 on the remote? The remote could be compromised\n* Jonathan: You can verify things locally. This is the core idea of\n distributed version control.\n* Patrick: Oh, I see.\n* brian: Signatures work with both hash functions, you can sign with\n both.\n* Peff: It does not feel right to me to set the user default until we\n the project are using it, and that the interop code is a part of that\n story. (back to Git 3.0, we combined the SHA-256 and Git 3.0\n discussions into one)\n* Peff: I have a proposal for Git 3.0, maybe this has been discussed?\n Can we get rid of some of the older protocols (dumb HTTP)?\n* Patrick: Lots of esoteric things, like show-branch, which apparently\n nobody uses.\n* Elijah: not just removals, but changing defaults, etc.\n* Emily: are we interested in non-backwards compatible changes, like\n adding multi-Author fields to commits?\n* Peff: I think that's a bad example, it can be done without breaking\n compatibility, but it was decided to not to do it. You're welcome to\n resurrect the discussion.\n* Patrick: … but it's a different question of whether or not that would\n end up in the document.\n* brian: multi-signatures\n* Jonathan: Two questions I'm hearing:\n * Should we include things that haven't been implemented yet?\n Probably not.\n * What do we think about this major version as a way to break\n interoperability with older versions of Git?\n* Patrick: I would not be in favor of breaking something, at least in\n cases where we can add a protocol extension and/or new capabilities.\n Intentionally breaking interoperability with an older version does not\n seem like the right way to go.\n* brian: I agree, but for the dumb HTTP protocol, C git uses it, Eric\n Wong is really into it (lore.kernel.org supports it), etc.\n* Emily: Bundle URIs and resumable clones, could in theoretically work\n for resumable clones, but we don't have client-side support.\n* Peff: Pretty sure that this isn't the case.\n* Mark: can I ask a \"dumb\" question? What would it take to get a\n schedule for 3.0?\n * Patrick: Junio says not too often, maybe only breaking releases\n every 5-10 years, which means 3.0 would come in 1-2 years.\n * Peff: 1-2 years is what is in my mind.\n * Taylor: I think that whatever answer we come to agreement here will\n not be satisfying for you.\n * Taylor: the items on that document aren't a checkbox list of things\n to do before Git 3.0, but isn't a \"let's get all of these things\n done and then we'll release Git 3.0\".\n * More that we'll all wake up one day, realize that we've done all\n or enough of what would go into Git 3.0, then remove a bunch of\n code, and ship it.\n* Jonathan: collecting breaking changes and aggregating them so users\n can prepare for them together is helpful, but it's not the only way\n that breaking changes will happen, especially if there is something\n that needs to go away.\n* Patrick: I want three things from this document:\n * Reminder / documented intent.\n * User feedback to hear things like \"this is important to me, what is\n (if any) the replacement?\"\n * ???\n* brian: changing the default branch name?\n * Taylor: I would be in favor of doing it sooner\n * (some discussion)\n * Taylor: We should consider doing it for git.git as well.\n* Peff: we might write a bunch of those patches, move them into 'next'.\n Could we have a Git 3.0 pseudo-maintainer.\n* Jonathan: I have a naive question: why wouldn't it look like turning\n on a single Makefile variable?\n* Emily: and then we go and delete the code inside of the #ifdefs\n* Taylor: whoever is the maintainer at that point in time could consider\n a double-wide release cycle, where we delete that code, implement new\n things, and then at the end of that cycle the artifact is called Git\n 3.0.\n* Peff: very few people run \"next\"\n * Jonathan: True. Could imagine some % of GitHub Actions runners\n automatically running \"next\", that's the kind of thing that gets a\n more representative workload.\n* Toon: do we want to have maintenance releases?\n* Emily: if we're dropping support for earlier versions, we should just\n do it.\n* Taylor: we should probably have a few supported release tracks that we\n designate as LTS releases.\n* Patrick: For security issues only, probably for a period of 1-2 years.\n* Peff: Should we write this up as a plan for the person who actually\n does release engineering?\n * Taylor: I can write up that plan, and be the point person for the\n LTS releases.\n * Jonathan: the Linux kernel has dedicated maintainers for LTS\n releases, which seems to work well.\n* brian: we can certainly tell that to Junio, but it's also ultimately\n their decision.\n"},{"id":"503133","messageId":"Zu2EmO+DkoH83S0Y@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 06/11] Git and Software Freedom Conservancy","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:20:08Z","receivedAt":"2024-09-20T14:20:13Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Git and Software Freedom Conservancy\n====================================\n\n(moderator: Taylor; notetaker: Patrick)\n\n* Taylor: Sent out new mail to the list with SFC activities.\n * https://lore.kernel.org/git/Zusxcweod1O88h7j@nand.local/T/#t\n * LOTS_OF_MONEY spam alert\n * Generally have more money in our account than we know what to do\n with.\n * SFC consists of 4 persons: Junio, Taylor, Ævar, Christian\n* Taylor: Trademark discussion\n * Enforcing the trademark is untenable because there are so many\n projects out there using \"Git\". We cannot go after those to defend\n our trademark, and would also not be in the spirit of the Git\n project.\n* Taylor: Money\n * We've got a large amount of money for an OSS project with few\n expenses, $90k USD.\n * Heroku is our biggest expense at $60 USD/mo.\n * What can we do with this money?\n* Chris: Mentor Outreachy this year, we'll likely have to sponsor them.\n * $8,000 USD/student. GitHub can probably cover one or two such\n students.\n * GitLab sponsored last year, but getting funding was taking a very\n long time on their side. John probably doesn't want to repeat the\n process again due to the hassle.\n* Jonathan: Git gets money due to GSoC, too. These kinds of mentoring\n projects are things where it's easy for donors to justify giving.\n* Chris: We do get money indeed due to the GSoC mentoring.\n* Chris: We have tried to sponsor travels for GSoC students in the past\n to come to Git Merge. Was quite easy to do that with our funds. Covid\n restricted that somewhat.\n * Students used to have problems acquiring a visa, creating a catch\n 22 because we had to book the flight up front, but it wasn't yet\n clear whether they'd get the visa. BUt without the flight, they\n wouldn't get the visa, either.\n* Peff: THe wasted money on that is probably small enough compared to\n how much funds we have, so the risk is comparatively small.\n* Jonathan: Do we have a rough estimate around how big yearly influx\n minus expenses is?\n* Taylor: The exact year is $93k USD. It's hard to tell exactly due to\n changes in reporting by SFC. Last year it was roughly $89k USD, so\n only up ~$4k. Typically we have a yearly income of around $10k-$20k\n USD/yr.\n* Peff: if you want something, would be relatively easy to run a\n fundraising campaign for Git\n* brian: I'm sure that we can easily raise additional money via\n individual contributors, too.\n* Jonathan: If we have the money for it, I think it might be relatively\n easy to justify hiring a full-time community manager for the Git\n project, for example.\n* Peff: 90k is a high amount of money to do small things, but it's not\n really enough to actually sponsor full positions for an extended\n period of time.\n* brian: True. Nobody is going to work for you without insurance, so it\n indeed isn't all that much money indeed.\n* Jonathan: Edward Thomson also mentioned that libgit2 passed on some\n money to other projects that can use it better\n* Emily: also wanting to spend money on contracting on particular\n projects\n* Brian: there are people who do contractor work like this. I just don't\n know whether we can find somebody who is willing to accept taht little\n money.\n* Emily: Developers are expensive, tech writers are a lot cheaper. Would\n that be a viable option? They could for example rewrite lots of our\n documentation.\n* Johannes: We could delete obsolete documentation!\n* Patrick: I tried to do this on the GitLab side, but it never really\n worked out. They didn't want to join the Git mailing list.\n* Emily: Same.\n* Mark: There would be some concern about having tech writers interact\n with the mailing list flow.\n* Peff: Ævar is not active on the PLC anymore for a long time. Should he\n be removed?\n* Taylor: We've been talking about that in the PLC. There are two\n options:\n * EIther remove him without replacement, such that we have three\n people on it. That would also make it less awkward when it comes to\n voting ties.\n * If we replace him, it would almost happen to have to come from\n someone who isn't affiliated with a large forge / company. We\n already have representation from GitHub, Git Lab, and Google, so\n would want an OSS contributor not affiliated with a major company.\n * Ideally I would like him to come back, but haven't been able to\n hear from him whether or not he is interested in doing so.\n* Michael: The trademark was originally owned by GitHub?\n* Peff: The git-scm.com web site was originally owned by Scott, was then\n moved over to SFC. The SFC applied for the Git trademark, came to an\n agreement with GitHub about details of how it would relate to the\n GitHub trademark.\n* Michael: Is there any obligation of Conservancy to GitHub that the\n trademark is enforced?\n* Peff: No.\n* Michael: Background is that the proposal was to stop enforcing it. SO\n the question is whether we have to due to an agreement.\n* Johannes: You lose the trademark if you don't enforce it in many\n different countries, so we either have to or don't and may thus lose\n it.\n* Chris: We mostly enforce it by privately emailing e.g. website owners\n that use Git in a way we don't agree with. So we do enforce it as\n necessary, even if it only happens very infrequently. Some companies\n do not register a trademark that's conflicting, but they still try to\n use it.\n* Jonathan: I think it would not be a good choice to not be assertive\n about the trademark at all. On the other hand, filing lawsuits against\n low-harm cases doesn't seem like a great use of time and money. So I\n feel like the current balance is sensible.\n* Peff: SFC's lawyers might disagree with that assessment.\n* Taylor: They want to see some new version of the trademark where we\n e.g. only enforce our trademark on the logo.\n* Chris: We raised the question a couple years ago of what to do about\n the trademark, and folks basically agreed with the current way of how\n we handle it.\n* Brian: Debian has a trademark policy that might be sensible to have a\n look at for inspiration. It e.g. says that you have to communicate\n truthfully.\n* Peff: We have similar stuff like that in our policy. The problem is\n that back when writing it we had another company that was trying to\n use the trademark for a \"shitty\" reimplementation of GIt, and we\n didn't want that. We don't really care for \"git-foo\". Dashed commands\n are explicitly allowed. GitOxide is e.g. technically against the\n trademark policy due to being CamelCased, but we are fine with it.\n* Taylor: We cannot do that, we have to consistently enforce the\n trademark. It needs to be very strictly defined what is and is not\n okay.\n* brian: it needs to be definitive whether you're doing the \"good\" or\n \"bad\" thing.\n* Jonathan: It might be interesting to tie this to compatibility with\n the Git test suite. SO if you pass it you are allowed to use it,\n otherwise not.\n* Jonathan: So IIUC, we have questions for the SFC lawyers because we\n canot really answer a lot of the questions?\n* Chris/Taylor: We can do that.\n * Taylor: We will talk offline to figure out who does what.\n"},{"id":"503134","messageId":"Zu2Eup+vjI3dALYu@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 07/11] New Contributors and Discord","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:20:42Z","receivedAt":"2024-09-20T14:20:46Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"How to attract new contributors? + Community Discord\n=====================================================\n\n(moderator: Jonathan N + Calvin Wan, notetaker: Emily)\n\n* jonathan: we talk about this a lot 🙂 let's avoid the common pitfall\n of catering to the tiktokkers and the youths (hypothesizing about\n \"current generation\"):\n* but, our contributor base isn't representative of our user base\n* and our current contributor base doesn't reflect exactly the skills\n needed to improve git - like interface design is not our strong suit.\n how to attract people who are better at our weak spots?\n * taylor: this weakness is an existential problem for Git. jj,\n gitbutler, gitkraken, etc\n * mark: +1\n * peff: one size doesn't fit all, us deciding not to include a GUI is\n understandable, but workflow improvements like jj's are pretty\n interesting\n * jonathan: ex. in hg there's someone very involved in UX review. we\n don't have someone like that\n* missing other disciplines - tech writing, product management, UX\n research, etc.\n * common problem in open source but would be cool if we could get\n good at attracting/retaining these people - and cool for the\n not-eng-discipline people\n * patrick: we could adopt a style guide or guideline but we still\n wouldn't be good at enforcement\n * john: people need to know what they can contribute to - cf. project\n tracking discussion later on\n* jonathan: instead of trying to guess - can we think generally, how do\n we make work easier to approach? how can we lower the barrier to\n entry?\n* patrick: someone is writing third-party rewrite of gitglossary. huge\n improvement over what we have, well made, but the person didn't want\n to come back to contribute. was afraid of the community giving\n pushback\n * patrick was willing to handhold this potential contributor, but it\n didn't seem like enough to make this person comfortable\n* jonathan: related to community discord server - what does it mean to\n function better as a community?\n* calvin: the entry point doesn't need to be discord, but we should pick\n some entry point that lets users contribute other than mailing list\n participation\n * and need to be able to navigate new contributions comfortably\n* brian: how to write text that's accessible to non-native english\n speakers, for example? the mailing list isn't great for these kinds of\n changes.\n* discord is proprietary, that is sometimes an issue\n* moderation on discord is an issue - having an unmoderated discord will\n actually drive away contributors. that means actual dedicated\n moderation\n * balancing between sufficient moderation (list) and ease of use\n (discord)\n* patrick: new contributors sending changes but the changes being\n ignored\n* brian: git-send-email is a barrier, but so are PRs/MRs in some cases\n* jonathan: the localization example is a good one - the translation\n layer is in github, uses a very typical dev workflow, and that's\n working well. there's a strong community there. are there other places\n we can do something similar?\n* peff: can we do that with documentation?\n * jonathan: can we have a documentation maintainer? hypothetically:\n we hire a tech writer, and that tech writer acts as the\n documentation maintainer only. curating existing docs, making sure\n docs changes get good reviews, how to attract new tech writer\n contributors, etc\n * peff: can we manage documentation as a subproject that doesn't use\n the mailing list, and make tech writers' lives easier?\n * how to negotiate that with code changes that require doc changes\n is trickier, we'd have to figure out how to do it, but doable\n * jonathan: readthedocs\n* jonathan: we don't advertise well that we can accept contributions in\n a different way if people are committed to the improvement\n * peff: sometimes a mentor can \"translate\" a contribution. Individual\n contributors are already interested in mentoring, do we need\n more/different mentoring?\n * mentoring list isn't working well yet - maybe it's too faceless?\n should we get a list of individuals who want to mentor?\n * taylor: should we literally put photos of the people on the\n mentoring list up somewhere? \"here are real humans, they will reply\n to you on git-mentoring@\"?\n * jonathan: in-person meetups help with this. emailing is\n transactional, but e.g. python meetups are interactive\n* patrick: we had the git berlin meetup a few months ago, lot of people\n came, we did lightning talks and user conversations. it worked well -\n let's use that model more\n * taylor: hey, we can help spend money on that\n * brian: those are cool but for example, houston linux users group is\n quite small. meetups like this can be helpful, but it's not the\n only source.\n * peff: it doesn't really scale up. python users group are\n user-to-user, doesn't necessarily draw python project contributors.\n * nasamuffin: Gerrit has a community meeting once/month, should we\n use discord for f2f video meetups?\n * peff: if people want to do big group meetups great. we could also\n use it for 1:1 meetups that way, and advertise that it's an option\n"},{"id":"503135","messageId":"Zu2E3vIcTzywWOx3@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 08/11] Modern Build Systems","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:21:18Z","receivedAt":"2024-09-20T14:21:23Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Modern Build System\n===================\n\n(moderator: Patrick; notetaker: brian)\n\n* Patrick: three different build system; should get rid of at least one\n of them\n * Should delete autoconf because it's not really maintained\n * Think about a proper build system\n * Obvious choice: cmake\n* Taylor: What's the problem with Makefiles\n* Patrick: Non-standard\n * Meson is nicer than cmake as an alternative\n* Jonathan: xz compromise shows autoconf is a risk\n* Autoconf isn't a problem for distro\n* Taylor: distro builds that can't handle \"make\" without configure are a\n distro problem\n* Jonathan: Modern build system can reflect the structure of how your\n code is set up\n * Declared dependencies\n* Brian: Rust will make the decision for us: cargo\n * BSDs use Make (granted, not GNU make) for building\n* Patrick: Is anyone else in favour of a proper build system\n * Ninja is way faster than make to build the projects\n* Taylor: Feels odd to build with a fancy tool that might have a\n dependency on Git\n* Dscho: --help is a autoconf feature and removed features are detected\n* Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes\n* Kyle: Editor integration is useful\n* brian: standard structure is helpful for LSPs\n* Emily: libification has shown that makefile is cumbersome\n* Jonathan: Should we do a comparison of build systems in terms of what\n we need from them on the list? Similar to\n Documentation/technical/unit-tests.txt\n * Patrick: I can write such a thing.\n* Patrick: Are their any features we need to consider?\n* Johannes Sixt: Consider supported platforms\n* Patrick: Want to verify that cmake is up to the task by testing in CI?\n * Will volunteer to post something to the list\n"},{"id":"503136","messageId":"Zu2FCF+BOrshAzxN@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 09/11] Bundle-URI on fetch / resume-able clone","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:22:00Z","receivedAt":"2024-09-20T14:22:05Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Bundle-URI on fetch / resume-able clone\n=======================================\n\n(moderator: Toon; notetaker: Taylor)\n\n* Toon: we have bundle-uris, which allow us to download bundles before\n\tcloning. What would it take to do them on fetch, too?\n* Toon: Complex; you might end up downloading a lot of bundles that you\n\tdon't need.\n* Toon: there was a bundle token that could be used by the client to\n\tdetermine whether or not it needs the bundle. Unfortunately, since you\n\tdon't know what amount of history you're missing, the bundle in and of\n\titself may not be sufficient.\n* Toon: How do we make bundles more efficient on fetch and aware of what\n\tthe clients do and don't have.\n* Johannes: In VFS for Git, the set of bundles is \"opinionated\" and\n\tregenerated often (e.g., weekly, daily, hourly, etc.). We don't really\n\tcare about oversharing, because it's fast enough to download those\n\tstatic files.\n* Toon: That's true for the server, not for a singular client.\n* Johannes: right, but it's to protect the server. If you don't care\n\tabout having too-big of a bundle, it's OK because you can just fetch\n\tthe last hour and then see what you still need on top of that.\n* Johannes: there is logic to determine what you need to download based\n\ton the time that you last fetched, etc.\n* Elijah: are they thin packs? Yes.\n* Patrick: the heuristics that we have to advertise what kind of bundles\n\tare on the server is not sufficient enough to determine which bundles\n\tthe client may or may not want to download. The client must guess.\n* Jonathan: ISTM that the property list for the bundles as they are\n\ttoday should probably be considered a starting point (as in \"part of a\n\tfeature\"). The heuristics need to be extended.\n* Jonathan: at Google we use packfile-URIs, and one of the advantages of\n\thow that works is that since the packfiles are advertised after the\n\tnormal fetch negotiation, you get a curated list. For bundle-uris,\n\tneed something analogous to the fetch negotiation for the client to be\n\table to make a similar decision of which bundle to download.\n* brian: extending the feature to store timestamps, then you could store\n\tthe last fetch on the system would inform some better selection of\n\twhich bundles to clone down during a fetch.\n* brian: Would make a big difference for folks in environments which do\n\tnot benefit from reliable Internet connections.\n* Toon: Sure... but you have to put a lot of pressure to keep those\n\tbundles up-to-date on the server side.\n* Jonathan: one of the advantages of bundles over packs is that they\n\thave information about the references. One potential property could be\n\t\"here's the length of this header\" and then having the client download\n\tit to examine whether or not it wants such a bundle.\n* Patrick: probably would want to cache those on the client so that\n\twe're able to avoid re-downloading these every single time.\n* Toon: resumability\n* Jonathan: protocol supports it, just hasn't been implemented. Someone\n\tneeds to just get it done. :)\n* Beyond that, the main complication is how you store the state and what\n\tthe UX is for resuming. But a person implementing it can figure those\n\tthings out.\n* Brian: broken-proxy situations require some configurability of where\n\tyour bundles can be downloaded from.\n"},{"id":"503137","messageId":"Zu2FMQnLCKQ2skkM@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 10/11] Project Tracking","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:22:41Z","receivedAt":"2024-09-20T14:22:46Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Project Tracking\n================\n\n(moderator: Emily, Patrick; notetaker: Taylor)\n\n* Emily: Patrick and I were talking about roadmap-like things sometimes\n this week. It would be nice if we had a list of projects that the\n community has agreed are good ideas. For e.g., “generally we are\n working on getting rid of ‘the_repository’”.\n* Emily: We have agreed that libification is a good thing, so anytime\n that someone sends a patch in that area it isn’t up for discussion\n whether or not the patch is fundamentally going in the right\n direction.\n* Emily: It would be cool to have a list of agreed-upon things. I also\n think that we should get better at figuring out what we agree on.\n I.e., the status-quo is argument on the list until quorum, and would\n like some kind of more structured way to determine when we are in\n agreement.\n* Jonathan: When you say “predictable process”, what does that actually\n mean? Python has PEPs, they have a very clear state machine that\n stringently dictates the process.\n* Emily: probably not something that strict, but would like to generally\n be able to tell “is it going in the right direction?” And\n approximately, “Approximately when will we be able to tell when it’s\n done?”\n* Taylor: how do we quantify that? A lot of what developing consensus\n looks like is developing patches and then sometimes throwing them away\n if/when we find a fundamental design bug, etc.\n* Patrick: “Are we going to do it?” is when something like a brief RFC\n is merged.\n* Taylor: Is the Git 3.0 deprecation doc a good example?\n* Patrick: Yeah.\n* Patrick: We would also want to have a document with a little check\n mark indicating when we are going to do small things like clean up\n memory leaks.\n* Jrn: The pain point is being able to know when making a proposal how\n much support they have.\n* Taylor: Sometimes implementation clarifies one’s thinking.\n* John: We have some tribal knowledge on what is accepted in which\n areas. Can we codify that?\n* Patrick: The BreakingChanges statement says that we can change things\n on the document if there is new information. I’d like to see that this\n statement is echoed elsewhere.\n* Taylor: It feels like it would be more useful to have a discussion\n based on a WIP or PoC (e.g. UNLEAK() and FREE_AND_NULL()).\n* Peff: I don’t want people to produce patches, say, if we blessed unit\n tests, and then consider that discussion immutable. That doesn’t give\n us the opportunity to make changes to the fundamental design. I don’t\n want to use it as a cudgel to shut further discussion down.\n* Jonathan: “I guess I am going to argue in favor of cudgel.” Taking\n unit tests as an example, if someone later says “I don’t see any value\n in unit tests”, that’s not very productive. If they say “I see the\n value of unit tests, but not at this cost”, it’s a more worthwhile\n conversation.\n* brian: Maybe we can only use that as an argument for 4-5 weeks. Having\n some disagreement is fine, just don’t want to make it indefinite.\n* Peff: On PEPs. Often someone will say “I’m going to go in this\n direction”, and I’ll feel mildly negative about it. That’s very\n different from voting against something.\n* Emily: Sure, there can be more voting options than just\n yes/no/abstain.\n* Jonathan: Apache does a nice job with +/- 0, +/- 1\n (https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions)\n* Emily: we should be better about saying generally how we feel about\n things at the end of the series).\n* Taylor: Taking a step back for a moment, what are some examples of\n things that are going wrong that need to be changed? What is wrong\n with the project here?\n* Emily: things are taking too long.\n* Emily: Goal-posting moving, etc.\n* Johannes: Yes, that can be very frustrating and cause a lot of\n friction.\n* brian: When you do creative work, you get feedback and sometimes you\n take it and sometimes you don’t.\n* Taylor: at the risk of repeating what brian said, it’s hard/impossible\n to please 100% of reviewers on 100% of series. At some point you have\n to step back and let the maintainer evaluate.\n* Jonathan: I think the point of Patrick’s proposal is “how do you go\n about navigating this with a 10-series long project?” Then you’re in\n trouble. The proposal would allow you to check in a bullet point, or a\n design doc, and go through that process and navigate to the point\n where you get the maintainer’s blessing and the conclusion is checked\n in.\n* brian: Maybe a bullet point is too small for some things.\n* Taylor: so it’s a continuum, sometimes you are going to save time by\n just writing the patches, sometimes you are going to save time by\n writing out what you are doing (over a multi-series effort) first.\n* Patrick: discoverability!\n* Mark: could we encourage newcomers to email one of a few people for a\n particular effort (like libification) and have them comment on it?\n* Taylor: you might not want to centralize that much power.\n* Toon: How about structured errors? We agree it’s a good idea, but not\n on the mechanism of implementation.\n* Patrick: Sure, sometimes that just takes time. We don’t have to\n document how to fix them (maybe how to find them, but I digress).\n* Patrick: For structured error handling, it should be more involved. It\n makes sense to have an RFC or design document that documents how it’s\n supposed to look like.\n* brian: or an initial patch series that comes up with a design.\n* Peff: In our project, the formalism of voting is “is it merged to\n ‘master’ in Junio’s tree”.\n* Emily: I want to have the process of getting from discussion to merge\n be less fuzzy.\n* Peff: So in brian’s example, let’s take SHA-256. The process by which\n the maintainer decides that is inherently fuzzy.\n* Emily: Sure, but I would like to be obvious to someone besides the\n maintainer.\n* Jonathan: (to Peff) you mentioned sometimes you have a mild negative\n feeling about something and you’re good about expressing it on-list,\n but for a lot of contributors that will cause some discomfort and it\n will cause them to stay away from that thread. If we’re a little more\n clear about what’s expected, then conversations can get stalled less\n often - e.g. when a thread needs a comment from a refs expert, getting\n that comment that supports forward progress.\n* brian: I just gave Taylor feedback on the SHA-1 series that he wrote,\n saying that I didn’t love it. But others felt OK about it, so we moved\n forward.\n* Emily: strawman doc:\n https://github.com/nasamuffin/git/commit/54079ab00002c6dfa7ac1a33d9810792978d2cce\n - maybe it's bad enough we can poke holes and salvage something we do\n like\n* Peff: it’s important to leave at the end of your review the way you\n feel about something instead of just having a few comments.\n"},{"id":"503138","messageId":"Zu2FRo7MJeng41UP@nand.local","threadId":"62154","inReplyTo":"Zu2DmS30E0kKug2a@nand.local","subject":"[TOPIC 11/11] git-scm.com state of the site","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-09-20T14:23:02Z","receivedAt":"2024-09-20T14:23:07Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"git-scm.com state of the site\n=============================\n\n* Johannes: worked on a static site version of git-scm.com.\n\n(Johannes: demonstration)\n\n* Peff: let’s move it over.\n* Taylor: AGREED\n"},{"id":"503141","messageId":"053f01db0b79$0d885b30$28991190$@nexbridge.com","threadId":"62154","inReplyTo":"Zu2D/b1ZJbTlC1ml@nand.local","subject":"RE: [TOPIC 01/11] Rust","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-09-20T16:20:42Z","receivedAt":"2024-09-20T16:20:55Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2024 10:18 AM, Taylor Blau wrote:\n>* Kyle: Rust code in the Git project; do we want it? Why would we want\n> it?\n>* Elijah: Anybody other than Randall that objects to it?\n\nTo be honest, I do not fundamentally object to Rust. My problem is that the\nRust team is not supporting including NonStop as a platform. I would love\nto be able to do the port, but it is not up to me - it is up to Rust's permission\n(or lack of in this case) to support NonStop, and I do not see this changing\nin my life-time. Depending on a piece of technology where control of where\nit runs is outside of git's control is not responsible, in my view. It restricts\nwhere git can run, and excludes platforms that currently use a critical piece\nof infrastructure (git). I have tens of thousands of people in my community\nwho depend on git on a daily basis, and simply kicking them off because\nof a decision, or lack of decision, that some unrelated dependency controls\nshould be (unfortunately does not appear to be for git) a showstopper.\n\nI am just the vocal one who is paying attention to the issue.\n\nSincerely,\nRandall\n\n"},{"id":"503158","messageId":"xmqqzfo2f7vh.fsf@gitster.g","threadId":"62154","inReplyTo":"Zu2EdQs6xf2FRkpa@nand.local","subject":"Re: [TOPIC 05/11]: SHA 256 / Git 3.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-20T19:22:10Z","receivedAt":"2024-09-20T19:22:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> * Peff: I have a proposal for Git 3.0, maybe this has been discussed?\n> Can we get rid of some of the older protocols (dumb HTTP)?\n\nPlease discuss these on list. Removal of http walker (both for\nfetching and pushing) you have my blessing ;-)\n\n> * Patrick: Lots of esoteric things, like show-branch, which apparently\n> nobody uses.\n\nYou remove show-branch and you will stop seeing \"What's cooking\"\n(\"git show-branch master $branch1 $branch2 ...\" is used as a way to\nfind the commits on each topic branch in flight, instead of running\n\"git log master..$branch\" N times).\n\n> * Elijah: not just removals, but changing defaults, etc.\n\nYes.\n\n> * Emily: are we interested in non-backwards compatible changes, like\n> adding multi-Author fields to commits?\n> * Peff: I think that's a bad example, it can be done without breaking\n> compatibility, but it was decided to not to do it. You're welcome to\n> resurrect the discussion.\n\nGood.\n\n> * Taylor: the items on that document aren't a checkbox list of things\n> to do before Git 3.0, but isn't a \"let's get all of these things\n> done and then we'll release Git 3.0\".\n\nYes.\n\n> * More that we'll all wake up one day, realize that we've done all\n> or enough of what would go into Git 3.0, then remove a bunch of\n> code, and ship it.\n\nNot exactly (see my recent comment on feature.git3 on the list---we\nneed a good transition plan and early adopter opt-in mechanism).\n\n\n\n"},{"id":"503159","messageId":"xmqqployf6z5.fsf@gitster.g","threadId":"62154","inReplyTo":"Zu2FMQnLCKQ2skkM@nand.local","subject":"Re: [TOPIC 10/11] Project Tracking","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-20T19:41:34Z","receivedAt":"2024-09-20T19:41:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> * Peff: In our project, the formalism of voting is “is it merged to\n> ‘master’ in Junio’s tree”.\n\nGraduation from 'next' to 'master' is mostly mechanical \"spend 1\ncalendar week and you are done\", so 'next' matters a lot more.\n\n> * Emily: I want to have the process of getting from discussion to merge\n> be less fuzzy.\n> * Peff: So in brian’s example, let’s take SHA-256. The process by which\n> the maintainer decides that is inherently fuzzy.\n> * Emily: Sure, but I would like to be obvious to someone besides the\n> maintainer.\n\nFWIW, this also is fuzzy for the maintainer, especially when not\nmany people who ought to know a lot more than the maintainer are\nstaying silent.\n\n> * Jonathan: (to Peff) you mentioned sometimes you have a mild negative\n> feeling about something and you’re good about expressing it on-list,\n> but for a lot of contributors that will cause some discomfort and it\n> will cause them to stay away from that thread. If we’re a little more\n> clear about what’s expected, then conversations can get stalled less\n> often - e.g. when a thread needs a comment from a refs expert, getting\n> that comment that supports forward progress.\n\nYes, either forward or backward. Having to keep a series that looks\npotentially worth doing for weeks on 'seen' without getting any\nmovement is *VERY* painful. Would it motivate more experienced\ncontributors to review and express either support or refusal if I\nmore frequently, say after 20 days since its latest round got queued\non 'seen', a topic that does not seem to get enough support to be\nmerged to 'next' and is not getting rerolled?\n\n> * brian: I just gave Taylor feedback on the SHA-1 series that he wrote,\n> saying that I didn’t love it. But others felt OK about it, so we moved\n> forward.\n\nFor this particular one, I consider it is not \"we moved forward\", by\nthe way. Please do not consider anything that is not marked with\n\"Will merge to 'next'?\" (with or without the final '?') moving\nforward.\n\n> * Peff: it’s important to leave at the end of your review the way you\n> feel about something instead of just having a few comments.\n\nYup, that would clarify area experts' position on topics and would\nhelp everybody a lot. It would also help me when updating the\n\"What's cooking\" draft, which is how the topics currently in-flight\nare getting tracked.\n\nThanks.\n"},{"id":"503160","messageId":"xmqqldzmf6lh.fsf@gitster.g","threadId":"62154","inReplyTo":"xmqqployf6z5.fsf@gitster.g","subject":"Re: [TOPIC 10/11] Project Tracking","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-20T19:49:46Z","receivedAt":"2024-09-20T19:49:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Yes, either forward or backward. Having to keep a series that looks\n> potentially worth doing for weeks on 'seen' without getting any\n> movement is *VERY* painful. Would it motivate more experienced\n> contributors to review and express either support or refusal if I\n> more frequently, say after 20 days since its latest round got queued\n> on 'seen', a topic that does not seem to get enough support to be\n> merged to 'next' and is not getting rerolled?\n\nMissing verb was \"discard\". Instead of keeping the stalled topic,\nperhaps I should more actively discard them (people are allowed to\nsend in a fresh iteration if they care enough)?\n\nSorry for the noise.\n"},{"id":"503173","messageId":"xmqqjzf6c56s.fsf@gitster.g","threadId":"62154","inReplyTo":"Zu2Eup+vjI3dALYu@nand.local","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-20T22:48:27Z","receivedAt":"2024-09-20T22:48:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> * and our current contributor base doesn't reflect exactly the skills\n> needed to improve git - like interface design is not our strong suit.\n> how to attract people who are better at our weak spots?\n> * taylor: this weakness is an existential problem for Git. jj,\n> gitbutler, gitkraken, etc\n> * mark: +1\n> * peff: one size doesn't fit all, us deciding not to include a GUI is\n> understandable, but workflow improvements like jj's are pretty\n> interesting\n> * jonathan: ex. in hg there's someone very involved in UX review. we\n> don't have someone like that\n> * missing other disciplines - tech writing, product management, UX\n> research, etc.\n> * common problem in open source but would be cool if we could get\n> good at attracting/retaining these people - and cool for the\n> not-eng-discipline people\n> * patrick: we could adopt a style guide or guideline but we still\n> wouldn't be good at enforcement\n> * john: people need to know what they can contribute to - cf. project\n> tracking discussion later on\n\nWould money solve these, e.g., by hiring somebody?\n\nThe issue would be how to find somebody good (\"known to be good with\npast track record\" would be a bonus) and ensure that the community\ntrusts the choice they make and the output they produce, in the\nareas like UI design or tech writing, that we know are not our\nstrong points. Would we be able to give them enough freedom to\nproduce their best product, yet be able to stop them if needed when\ntheir output turns out not so good as we hoped initially? Are we\nequipped to fairly evaluate their output?\n\n> * jonathan: instead of trying to guess - can we think generally, how do\n> we make work easier to approach? how can we lower the barrier to\n> entry?\n> ...\n> * moderation on discord is an issue - having an unmoderated discord will\n> actually drive away contributors. that means actual dedicated\n> moderation\n\nIt is not \"discord\" per-se, but lowering the barrier to entry would\nmean you'll get more people with different background and different\nidea of what is normal to deal with.\n\n> * patrick: new contributors sending changes but the changes being\n> ignored\n\nParaphrase. More patches written, not enough are reviewed.\n\n> * jonathan: the localization example is a good one - the translation\n> layer is in github, uses a very typical dev workflow, and that's\n> working well. there's a strong community there. are there other places\n> we can do something similar?\n> * peff: can we do that with documentation?\n> * jonathan: can we have a documentation maintainer? hypothetically:\n> we hire a tech writer, and that tech writer acts as the\n> documentation maintainer only. curating existing docs, making sure\n> docs changes get good reviews, how to attract new tech writer\n> contributors, etc\n> * peff: can we manage documentation as a subproject that doesn't use\n> the mailing list, and make tech writers' lives easier?\n> * how to negotiate that with code changes that require doc changes\n> is trickier, we'd have to figure out how to do it, but doable\n> * jonathan: readthedocs\n\nThere needs to be a mechanism to ensure the technical correctness of\nthe result to replace the public reviewing on the mailing list for\nthe above model to work.\n\n> * nasamuffin: Gerrit has a community meeting once/month, should we\n> use discord for f2f video meetups?\n> * peff: if people want to do big group meetups great. we could also\n> use it for 1:1 meetups that way, and advertise that it's an option\n\nSounds like a good way to make it easier to link names with faces.\n\n\n"},{"id":"503198","messageId":"Zu78E+0Uk5fMSeQv@five231003","threadId":"62154","inReplyTo":"Zu2Eup+vjI3dALYu@nand.local","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Kousik Sanagavarapu","fromEmail":"five231003@gmail.com","sentAt":"2024-09-21T17:02:11Z","receivedAt":"2024-09-21T17:02:16Z","isPatch":false,"sender":{"key":"five231003@gmail.com","avatar":"https://avatars.githubusercontent.com/u/75560439?v=4"},"body":"Taylor Blau writes:\n\n> How to attract new contributors? + Community Discord\n> =====================================================\n> \n> (moderator: Jonathan N + Calvin Wan, notetaker: Emily)\n> \n> * jonathan: we talk about this a lot 🙂 let's avoid the common pitfall\n> of catering to the tiktokkers and the youths (hypothesizing about\n> \"current generation\"):\n\nI guess I would fall into the \"youths\" category ;)\n\nI started contributing about a year ago although most of my activity was\nduring the GSoC'23 period.\n\n> * jonathan: related to community discord server - what does it mean to\n> function better as a community?\n> * calvin: the entry point doesn't need to be discord, but we should pick\n> some entry point that lets users contribute other than mailing list\n> participation\n> * and need to be able to navigate new contributions comfortably\n> * brian: how to write text that's accessible to non-native english\n> speakers, for example? the mailing list isn't great for these kinds of\n> changes.\n> * discord is proprietary, that is sometimes an issue\n> * moderation on discord is an issue - having an unmoderated discord will\n> actually drive away contributors. that means actual dedicated\n> moderation\n> * balancing between sufficient moderation (list) and ease of use\n> (discord)\n\nI don't know if we get new contributors complaining about our workflow\nbeing centered on the mailing list but I personally find the list really\nintuitive to work with.\n\nEven if we do eventually move towards a more \"user-friendly\" interface\n_for_ new contributors, they may still need to read through history for\ncertain changes they maybe working on, ON the list.\n\n> * patrick: new contributors sending changes but the changes being\n> ignored\n\nI do remember the time when I first contributed and was anxious about\nthe reply but I guess even if someone else doesn't review a particular\npatch, Junio gets around to it eventually (which is not ideal, we want\nmore reviewers...) so they are not completely lost... everytime.\n\nAlthough it would be great if there was some kind of an interface to say\nthat this patch is a new contribution to anyone going through the\nmessages similar to what Calvin said above. So that if the patch were\nsimple enough then maybe some of the newer contributors may also have a\ngo at reviewing the patch.\n\n> * brian: git-send-email is a barrier, but so are PRs/MRs in some cases\n\nI think the main barrier is the configuration of git-send-email rather\nsending the patches themselves. Since most people have gmail accounts,\nthe setup becomes a pain because of the two-factor-auth and creating app\npasswords and for someone who is mailing a minor change, this indeed\nfeels like a lot of effort not worth the time or energy.\n\n> * jonathan: we don't advertise well that we can accept contributions in\n> a different way if people are committed to the improvement\n> * peff: sometimes a mentor can \"translate\" a contribution. Individual\n> contributors are already interested in mentoring, do we need\n> more/different mentoring?\n\nI think having mentors would be great thing. Even if it is not 1:1.\n\nAnother thing that would be great is having a list of things on which a\nnew contributor could work on. GitGitGadget's issues used to do this by\ntagging the appropriate issues \"good-first-issue\" but I guess it is not\nproperly maintained anymore.\n\nI know there is also searching for \"#leftoverbits\" or \"low hanging fruit\"\non the list but the \"good-first-issue\" tagged issues on GitGitGadget are\nprobably more new-contributor-friendly than whole email threads.\n\n> * nasamuffin: Gerrit has a community meeting once/month, should we\n> use discord for f2f video meetups?\n> * peff: if people want to do big group meetups great. we could also\n> use it for 1:1 meetups that way, and advertise that it's an option\n\nI think we hit on this topic last year too in the virtual contributor's\nsummit and I agree that having a regular meetup would be great and\nsomething I personally would very much look forward to. This would also\nhelp put faces to names.\n\nNot exactly a regular community meeting but Review Club was kind of a\nlarge step towards this I guess. I was exactly in one review club\nmeeting and it sadly got shutdown right after that :').\n"},{"id":"503226","messageId":"xmqqsetr5wl1.fsf@gitster.g","threadId":"62154","inReplyTo":"Zu78E+0Uk5fMSeQv@five231003","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-22T19:15:22Z","receivedAt":"2024-09-22T19:15:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kousik Sanagavarapu writes:\n\n> Another thing that would be great is having a list of things on which a\n> new contributor could work on. GitGitGadget's issues used to do this by\n> tagging the appropriate issues \"good-first-issue\" but I guess it is not\n> properly maintained anymore.\n\nTrue.\n\n> I know there is also searching for \"#leftoverbits\" or \"low hanging fruit\"\n> on the list but the \"good-first-issue\" tagged issues on GitGitGadget are\n> probably more new-contributor-friendly than whole email threads.\n\nYes, even with these search terms, finding an issue to work on from\nthe mailing list archive would not be suited for an absolute newbie\nfor four reasons.\n\n * Anybody can write \"low hanging fruit\" in their message. Such a\n label added by somebody without understanding the issue would\n lead readers in a wrong direction. These phrases need to be\n reserved for a case where the person who adds _know_ they can\n solve it themselves fairly easily if they dedicated time on it\n for a few days but deliberately chooses to leave it on the table\n unsolved.\n\n * \"#leftoverbits\" is just that---a direction we could explore in\n the future, and the journey that goes in the direction is limited\n to a short and trivial one.\n\n * Both labels are opinions of the author at the time of writing.\n It may turn out that what was thought of as a \"low hanging fruit\"\n is not all that easy, and it may turn out that what was labeled\n with \"#leftoverbits\" would not lead to a productive direction\n after somebody actually tries.\n\n * And the list archive by its nature will show hits for ideas\n marked with \"#leftoverbits\" and/or \"low hanging fruit\" that have\n already been fully explored, and those who completed the task may\n not reference to the original message that inspired them in the\n References: header, so the archive search cannot show that the\n task is completed already.\n\nWe could improve the situation for all of the above four downsides\nby making it a collective habit to follow-up these messages with\n\"#leftoverbits\" or \"low hanging fruit\" in it, if the situation\nchanges, but your \"whole email threads\" comment still applies.\n\nUnless we make a habit of sending a separate message with such\nmarkings in which we summarize the discussion, that is.\n\n#leftoverbit. Perhaps one of the how-to documents that describe the\nproject workflow (i.e. my first contribution, how to review patches,\netc.) can mention the best-current-practice to encourage such use of\nthese tags? Something like\n\n - When you mention a good idea that is not squarely inside the\n theme of the current discussion, instead of adding \"#leftoverbit\"\n mark in the message, write a separate message as a follow-up to\n the message and summarize the issues and idea in such a way that\n people who later looks for a message with such a mark can grok\n the idea by the message alone, while still allowing them to learn\n more about the backstory by going back in the discussion thread.\n\n - After you find \"#leftoverbit\" message and worked on it (either\n you produced a patch series, or you failed and know why the idea\n described in the #leftoverbit message does not work), make sure\n you mention the original \"#leftoverbit\" message's message-id in\n such a way that a person who found the \"#leftoverbit\" message can\n find your message. Sending your patch series as a reply to such\n a message would be the easiest way to achieve it.\n\nor somesuch, perhaps.\n\n> Not exactly a regular community meeting but Review Club was kind of a\n> large step towards this I guess. I was exactly in one review club\n> meeting and it sadly got shutdown right after that :').\n\nAnybody motivated enough can take initiative to reignite the Review\nClub; you do not need permissions from past hosts to do so.\n\nQuite honestly, I sometimes failed to find much value in the review\nthese meetings produced, and I suspect it was not due to lack of\npreparation on participants' side, but was largely due to the fact\nthat the face-to-face meetings cannot go to sufficient depth in\ntechnical conversion in a single sitting.\n\nIt might have been more productive format if it weren't \"let's\ncritique this series on the fly\". For example, it could instead\nhave been \"There is an excellent reviewer-contributor exchange\nthread on the list. Let's read these exchanges together and learn\nhow to effectively convey the idea from the original author's side,\nand idea for improvements from the reviewer's side\". I dunno.\n\nThere however was a lot of value in the mere fact that people had a\nface-to-face discussion on something, anything, that was related to\nthe project.\n\nThanks.\n"},{"id":"503227","messageId":"xmqqikun5v8b.fsf@gitster.g","threadId":"62154","inReplyTo":"xmqqsetr5wl1.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-22T19:44:36Z","receivedAt":"2024-09-22T19:44:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> * \"#leftoverbits\" is just that---a direction we could explore in\n> the future, and the journey that goes in the direction is limited\n> to a short and trivial one.\n\nCorrection. \"is limited\" -> \"is not limited\".\n\n> Quite honestly, I sometimes failed to find much value in the review\n> these meetings produced, and I suspect it was not due to lack of\n> preparation on participants' side, but was largely due to the fact\n> that the face-to-face meetings cannot go to sufficient depth in\n> technical conversion in a single sitting.\n\nCorrection. \"conversion\" -> \"conversation\".\n\n> There however was a lot of value in the mere fact that people had a\n> face-to-face discussion on something, anything, that was related to\n> the project.\n>\n> Thanks.\n"},{"id":"503235","messageId":"0864bd25-d5c4-45ac-a59e-e6f7d24002de@gentoo.org","threadId":"62154","inReplyTo":"Zu2E3vIcTzywWOx3@nand.local","subject":"Re: [TOPIC 08/11] Modern Build Systems","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-09-23T02:01:32Z","receivedAt":"2024-09-23T02:01:35Z","isPatch":false,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 9/20/24 10:21 AM, Taylor Blau wrote:\n> Modern Build System\n> ===================\n> \n> (moderator: Patrick; notetaker: brian)\n> \n> * Patrick: three different build system; should get rid of at least one\n> of them\n> * Should delete autoconf because it's not really maintained\n> * Think about a proper build system\n> * Obvious choice: cmake\n> * Taylor: What's the problem with Makefiles\n> * Patrick: Non-standard\n> * Meson is nicer than cmake as an alternative\n\n\nI suppose I'm pretty biased but yes, I do feel we (meson) have managed\nto make some great workflow improvements here. :)\n\nPlease do feel free to ask me questions about it.\n\n\n> * Jonathan: xz compromise shows autoconf is a risk\n> * Autoconf isn't a problem for distro\n> * Taylor: distro builds that can't handle \"make\" without configure are a\n> distro problem\n\n\nAnyone can handle \"make\" without configure without breaking a sweat,\nthat isn't even remotely challenging, and every distro already does it.\nThe problem is that \"make\" is stateless, which is another way of saying\nit has amnesia. By that token, everyone cobbles together their own state\nsystem on top of \"make\".\n\nAdmittedly, once set up it doesn't require much maintenance from version\nbump to version bump.\n\n\n> * Jonathan: Modern build system can reflect the structure of how your\n> code is set up\n> * Declared dependencies\n> * Brian: Rust will make the decision for us: cargo\n\n\nI would just like to note that this is not really true. There is one\nother build system that supports rust and its name is... meson. :)\n\nMeson supports rust as a language for creating libraries (cdylib or\nrlib) and executables. You can import a crate from crates.io and meson\nwill synthesize the build system from the existing Cargo.toml to expose\nit as an rlib dependency.\n\nYou still get full build script option parsing, system probing, control\nflow etc using the meson.build DSL, you can freely mix libraries or\nexecutables in any of meson's supported languages (C, C++, Cython, C#,\nD, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands\nfor data files, run gettext on translations, and more. Meson is designed\nto be a polyglot build system in ways that cargo will probably never be.\n\nCargo is probably best thought of as a compiler wrapper: it can spit out\nan executable if you run it on *.rs sources, but it doesn't replace most\nof the interesting parts of a build system and it doesn't even provide\nan \"install\" rule. No, `cargo install` does not count unfortunately as\nit has a nasty habit of recompiling the binaries you already compiled,\nbut now with the wrong options.\n\nYou really want something that provides a project lifecycle workflow for\nbuilding, testing, installing, and making dist tarballs with integrated\ndistcheck. The current Makefiles mostly kind of work, given sufficient\ncare, but cargo provides exactly zero of anything so you're back to\ncobbling together your entire workflow using Makefiles wrapped around\ncargo. I would call that the very furthest opposite from \"make the\ndecision for us\".\n\n\n> * BSDs use Make (granted, not GNU make) for building\n> * Patrick: Is anyone else in favour of a proper build system\n> * Ninja is way faster than make to build the projects\n\n\nIt is! Yes. Mostly because it does very, very little other than execute\na precalculated build graph, whereas the current Makefile runs a bunch\nof stateless external commands each time in order to calculate top-level\nMake variables.\n\n\n> * Taylor: Feels odd to build with a fancy tool that might have a\n> dependency on Git\n> * Dscho: --help is a autoconf feature and removed features are detected\n> * Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes\n\n\ncmake does not have an equivalent of ./configure --help. The best you\ncan get is to try to somehow successfully configure cmake once, and then\nrun a cmake command that prints every internal control flow variable\nused by cmake, then hope that the ones you care about include descriptions.\n\n(Say what you will about GNU autotools but they knew very well how to\nwrite good interaction standards, as evidenced by all the Makefile\nvariables git.git already uses from the GNU Coding Standards docs on how\nto architect a release process.) It is fundamental to the UX design of\n./configure that a user may query the build system to find out what\nchoices they can / are expected to make, before committing to those choices.\n\ncmake is actively a severe regression compared to autoconf for these\npurposes.\n\n\n> * Kyle: Editor integration is useful\n> * brian: standard structure is helpful for LSPs\n\n\nThese tend to mostly be solved by compile_commands.json, which most\nmodern build systems can produce. In particular, anything that creates a\nninja file essentially gets you this for free, because ninja can create\none for you.\n\nPlain Makefiles, and GNU automake, don't do very well at this at all,\nsince Make has too irregular a build graph to reliably compute any such\nthing. Same reason why there isn't much in the way of dedicated editor\nintegration (both cmake and meson have introspection APIs which editor\nplugins can use to directly query info from the build system, to provide\nfiner-grained control than what compile_commands.json can do).\n\n\n> * Emily: libification has shown that makefile is cumbersome\n> * Jonathan: Should we do a comparison of build systems in terms of what\n> we need from them on the list? Similar to\n> Documentation/technical/unit-tests.txt\n> * Patrick: I can write such a thing.\n> * Patrick: Are their any features we need to consider?\n> * Johannes Sixt: Consider supported platforms\n> * Patrick: Want to verify that cmake is up to the task by testing in CI?\n> * Will volunteer to post something to the list\n> \n\n-- \nEli Schwartz\nGentoo Developer and Meson Build maintainer\n"},{"id":"503236","messageId":"m0v7ynm7h0.fsf@epic96565.epic.com","threadId":"62154","inReplyTo":"053f01db0b79$0d885b30$28991190$@nexbridge.com","subject":"Re: [TOPIC 01/11] Rust","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2024-09-23T02:25:47Z","receivedAt":"2024-09-23T02:25:51Z","isPatch":false,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":"Hi Randall,\n\nThis ended up being pretty long, so I apologize in advance for 'not\nhaving the time to make it shorter' (if you'll permit a small amount of\nplagiarism there). These are just my thoughts on this topic that have\nbeen cooking for a long time. I've been following this conversation\nclosely, and for the first time, I thought I might have something small\nto add. Unfortunately, it's taken a lot of words to say it!\n\n writes:\n> On September 20, 2024 10:18 AM, Taylor Blau wrote:\n>>* Kyle: Rust code in the Git project; do we want it? Why would we want\n>> it?\n>>* Elijah: Anybody other than Randall that objects to it?\n>\n> To be honest, I do not fundamentally object to Rust.\n\nI don't think anybody (or at least, I hope nobody) thinks so; this is\nabsolutely a conversation we can and should (and I believe do) have in\ngood faith :-)\n\nI've not contributed to this conversation much so far -- not out of lack\nof interest, but out of respect:\n\n1. While I've been using Git for many, many years, I'm a pretty new face\n on this list. I'm still working on making a good first impression :-)\n\n2. I know absolutely _nothing_ about NonStop, but I do know what it's\n like to feel like you're a member of an invisible set of users. There\n are significant aspects of my $DAYJOB where that is absolutely the\n case, so I want to leave room for what I know that I don't know. I\n know your customers are important, and (I think I know) you\n supporting your customers requires the tools being used to be\n supported.\n\n3. I don't even know _that_ much about Git's implementation compared to\n the experts on this list, so I feel ill-equipped to judge personally\n whether Rust is a good fit for the project to begin with -- thus I\n don't feel I have much to contribute to that conversation over what\n the experts have already said.\n\nPutting my own cards on the table -- I'd be in favor of introducing Rust\ninto Git's codebase for many of the reasons cited elsewhere. Based on my\nnaive understanding of the codebase and the types of bug fixes I've seen\ncome in during my time paying attention to this list, it does seem like\nrustc would add the value for which it was designed. I say this not to\n'upvote' the idea of including Rust, but to be transparent about the\ncontext from which I'm speaking.\n\nSo, in good faith, here goes :-)\n\n> My problem is that the Rust team is not supporting including NonStop\n> as a platform. I would love to be able to do the port, but it is not\n> up to me - it is up to Rust's permission (or lack of in this case) to\n> support NonStop, and I do not see this changing in my life-time.\n\nIs this just regarding the GCC dependency I've seen you reference\nelsewhere[1] or is there something else? I just want to make all the\ncards are on the table here -- particularly I want to make sure you're\nnot referencing some licensing incompatibility or project policy that\ncould be (even) more challenging than porting GCC to NonStop. An\nuneducated search of rustc's book[2] for 'gcc' didn't yield anything\nimmediately interesting, but there are call-outs for not supporting\nplatforms that introduce license incompatibilities or 'onerous legal\nterms'.\n\nIf not, is this about (what I assume to be the) 'tier 3' platform\nsupport policy mentioned at [2]? In some respects, it seems like this is\nsimilar to the status of NonStop as a supported platform in the Git\nproject already, though I suppose that's also a main topic of\nconversation for the 'supported platform' thread elsewhere. It does seem\nin line with what you already do, though, which is to provide patches to\nGit when something merges that breaks tests on NonStop. It seems it\nwould be similar in a Rust world, though patches would 'just' be sent to\nthe Rust maintainers instead. (I say that knowing that it would be an\nentirely foreign codebase and set of concerns for submitting correct\npatches -- so the two are not at all similar in effort, just in\nbehavior.)\n\n> Depending on a piece of technology where control of where it runs is\n> outside of git's control is not responsible, in my view. It restricts\n> where git can run, and excludes platforms that currently use a\n> critical piece of infrastructure (git).\n\nI think this is going to be true of any platform that the Git project\nchooses to continue to build upon, isn't it? Any platform-specific bugs\nin the various C compilers used are not in this project's control,\neither, nor OpenSSL, cURL, PCRE, gettext, etc., etc. that are already\nessential to Git's main functions when it's being used by a human (i.e.,\nnot as part of a larger automated system).\n\nAny added dependency will run the risk of not being buildable on every\nplatform out there -- even if it's included in the standard library,\npotentially -- and I don't believe it's a sustainable practice to never\nadd any dependencies.\n\n> I have tens of thousands of people in my community who depend on git\n> on a daily basis, and simply kicking them off because of a decision,\n> or lack of decision, that some unrelated dependency controls should be\n> (unfortunately does not appear to be for git) a showstopper.\n\nI'd like to understand this a little better.\n\nFirst, from the original notes:\n>> Emily: old versions aren't going away.\nwhich I mention only to supply the obvious counterpoint. I believe\nyou've said in the past (sorry that I can't find the specific link) that\nyou'd like to see Git continue to receive improvements and enhancements\nthat you can forward onto your customers. This is great! I understand\nthis perfectly. I have the very same desire for my users (which number\nin the 3-4k range). I look forward to every performance improvement and\nrevamped workflow with bated breath -- wondering how/when it can be\nincorporated into our system to give our folks the best experience they\ncan possibly have as direct users of Git in a heavily automated system.\n\nIt stands to reason that your users wouldn't see such improvements if\nincompatible technologies like Rust are adopted into the codebase and\nthose features were written using this incompatible technology. This is\nunderstandably a frustrating prospect! Previously, you would have been\nable to get even more value out of all the open-source effort (and your\nown effort as a maintainer keeping it compatible) -- and now it's not\nreally feasible. I do understand this sentiment. (Regardless of how much\nI understand it, if this is not _your_ sentiment, please let me know!)\n\nHere's where I'm struggling a bit. From what I see, I understand two\ncontradictory points:\n\n1. To continue building Git on every platform where it builds today, the\n project must either\n\n a) not add any new incompatible dependencies or\n b) put any such dependencies behind a feature flag (e.g. NO_CURL) so\n that Git may continue to be built without that dependency.\n\n Great, no harm -- no foul. But...\n\n2. If you continue building without that dependency, you don't get that\n feature, so the original purpose of enhancing Git -- to pass that\n benefit on to users -- is lost.\n\nSo it would seem that this leaves us with only option (a) to not add any\nnew incompatible dependencies -- which is what I understand you've been\nproposing. Certainly reasonable. But then how do you build cool new\nstuff? Well, build it yourself, I guess.\n\nThere's been a _lot_ of cool new stuff lately. This is great! But this\ndoes seem to be spearheaded by the work (and thus funding) of companies\nlike GitLab, Microsoft, and Google (and these are just the ones I\nrecognize either by contributor name or by email domain). I'm incredibly\nthankful for the work and expertise these folks add to the project on an\nongoing basis.\n\nI worry though that the 'cool new stuff' seems to require such\ninvestment. It is _hard_ to write correct, safe C. I worry that this\ndifficulty will eventually translate to significant, safe contributions\ncoming only from those with the resources to create them and not from a\nmore diverse pool of contributors. As grateful as I am to large\ncompanies who fund Git contributions, I don't think those companies,\ngiven the choice in and of themselves, would think twice about dropping\nsupport for a platform they don't use -- and that is probably a much\nsmaller set than 'does the platform have GCC'. I don't think this is a\ndanger today or tomorrow, but it _is_ a danger of not having a diverse\ngroup of contributors -- and that is the danger posed by not allowing\nyourself to use any of the 'cool new stuff' _other_ people have written.\n\n--\n\nI don't have a satisfying response to what to do for NonStop in a world\nwhere Rust enters the Git codebase. I really don't, and that frustrates\nme for you. I hope that there's a solution out there (maybe from your\nvendors, maybe from the storied halls of GCC maintainers, who knows),\nbut I'll echo (more earnestly this time):\n>> Emily: old versions aren't going away.\nNobody has the power to 'kick users off' a project such as Git -- not\neven if everyone somehow miraculously agreed to port the entire thing to\nsomething hot off the presses at /r/programminglanguages :-) Ultimately,\nyour systems will continue to function regardless of what happens\nupstream. Of course I can't speak to support contracts, but I assume\nneither can anyone on this list.\n\nThat said, I also don't know how a project can continue to thrive\nwithout the (occasional, thoughtful, and deliberate) introduction of new\ntechnologies, new contributors excited and emboldened by those\ntechnologies, and new ideas from those contributors.\n\nChange is essential to growth. Like I mentioned at the outset, I'll let\nthe true experts on this list speak to whether _this_ change is\nessential for growth, but I hope I've at least made some points that\nwere worth reading.\n\n[1]: https://lore.kernel.org/git/007c01da4420$10a7b700$31f72500$@nexbridge.com/\n[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html\n\n-- \nSean Allred\n"},{"id":"503244","messageId":"25050ad6-bdf8-4b1f-bbc8-cffe6ca15386@gmail.com","threadId":"62154","inReplyTo":"xmqqployf6z5.fsf@gitster.g","subject":"Re: [TOPIC 10/11] Project Tracking","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-23T09:15:23Z","receivedAt":"2024-09-23T09:15:26Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 20/09/2024 20:41, Junio C Hamano wrote:\n> Taylor Blau writes:\n\nTaylor - thanks for posting these discussions\n\n>> * Jonathan: (to Peff) you mentioned sometimes you have a mild negative\n>> feeling about something and you’re good about expressing it on-list,\n>> but for a lot of contributors that will cause some discomfort and it\n>> will cause them to stay away from that thread. If we’re a little more\n>> clear about what’s expected, then conversations can get stalled less\n>> often - e.g. when a thread needs a comment from a refs expert, getting\n>> that comment that supports forward progress.\n> \n> Yes, either forward or backward. Having to keep a series that looks\n> potentially worth doing for weeks on 'seen' without getting any\n> movement is *VERY* painful. Would it motivate more experienced\n> contributors to review and express either support or refusal if I\n> more frequently, say after 20 days since its latest round got queued\n> on 'seen', a topic that does not seem to get enough support to be\n> merged to 'next' and is not getting rerolled?\n\nI think that sounds reasonable. Sometimes I'm quite slow to review but \nif I haven't managed to do it within 3 weeks I'm unlikely to get round \nto it. I'm also sometimes slow to re-roll if I'm ruminating on the best \nway forward, but even if a patch series gets dropped there is nothing \nstopping the contributor from re-rolling.\n\nBest Wishes\n\nPhillip\n"},{"id":"503249","messageId":"00a501db0db2$94d505d0$be7f1170$@nexbridge.com","threadId":"62154","inReplyTo":"m0v7ynm7h0.fsf@epic96565.epic.com","subject":"RE: [TOPIC 01/11] Rust","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-09-23T12:17:33Z","receivedAt":"2024-09-23T12:17:48Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 22, 2024 10:26 PM, Sean Allred wrote:\n>This ended up being pretty long, so I apologize in advance for 'not having\nthe time\n>to make it shorter' (if you'll permit a small amount of plagiarism there).\nThese are\n>just my thoughts on this topic that have been cooking for a long time. I've\nbeen\n>following this conversation closely, and for the first time, I thought I\nmight have\n>something small to add. Unfortunately, it's taken a lot of words to say it!\n>\n> writes:\n>> On September 20, 2024 10:18 AM, Taylor Blau wrote:\n>>>* Kyle: Rust code in the Git project; do we want it? Why would we want\n>>> it?\n>>>* Elijah: Anybody other than Randall that objects to it?\n>>\n>> To be honest, I do not fundamentally object to Rust.\n>\n>I don't think anybody (or at least, I hope nobody) thinks so; this is\nabsolutely a\n>conversation we can and should (and I believe do) have in good faith :-)\n>\n>I've not contributed to this conversation much so far -- not out of lack of\ninterest,\n>but out of respect:\n>\n>1. While I've been using Git for many, many years, I'm a pretty new face\n> on this list. I'm still working on making a good first impression :-)\n>\n>2. I know absolutely _nothing_ about NonStop, but I do know what it's\n> like to feel like you're a member of an invisible set of users. There\n> are significant aspects of my $DAYJOB where that is absolutely the\n> case, so I want to leave room for what I know that I don't know. I\n> know your customers are important, and (I think I know) you\n> supporting your customers requires the tools being used to be\n> supported.\n>\n>3. I don't even know _that_ much about Git's implementation compared to\n> the experts on this list, so I feel ill-equipped to judge personally\n> whether Rust is a good fit for the project to begin with -- thus I\n> don't feel I have much to contribute to that conversation over what\n> the experts have already said.\n>\n>Putting my own cards on the table -- I'd be in favor of introducing Rust\ninto Git's\n>codebase for many of the reasons cited elsewhere. Based on my naive\n>understanding of the codebase and the types of bug fixes I've seen come in\nduring\n>my time paying attention to this list, it does seem like rustc would add\nthe value for\n>which it was designed. I say this not to 'upvote' the idea of including\nRust, but to be\n>transparent about the context from which I'm speaking.\n>\n>So, in good faith, here goes :-)\n>\n>> My problem is that the Rust team is not supporting including NonStop\n>> as a platform. I would love to be able to do the port, but it is not\n>> up to me - it is up to Rust's permission (or lack of in this case) to\n>> support NonStop, and I do not see this changing in my life-time.\n>\n>Is this just regarding the GCC dependency I've seen you reference\nelsewhere[1] or is\n>there something else? I just want to make all the cards are on the table\nhere --\n>particularly I want to make sure you're not referencing some licensing\n>incompatibility or project policy that could be (even) more challenging\nthan porting\n>GCC to NonStop. An uneducated search of rustc's book[2] for 'gcc' didn't\nyield\n>anything immediately interesting, but there are call-outs for not\nsupporting\n>platforms that introduce license incompatibilities or 'onerous legal\nterms'.\n\nThe GCC dependency, which does not currently exist in git, is independent of\nRust.\nRust has its own rules and runtime. The issue here is that the Rust team\ngets to\ndecide what platforms can participate, NOT the platform maintainers. No\nmatter\nwhat my intent, or resources, I cannot get the Rust team to \"Allow\" a port.\nIn\nmany ways, this is egregious and is a policy issue entirely on Rust, not us.\nWe\nwant to do a Rust port but are simply not allowed/approved. It is their\npolicy.\n\n>If not, is this about (what I assume to be the) 'tier 3' platform support\npolicy\n>mentioned at [2]? In some respects, it seems like this is similar to the\nstatus of\n>NonStop as a supported platform in the Git project already, though I\nsuppose that's\n>also a main topic of conversation for the 'supported platform' thread\nelsewhere. It\n>does seem in line with what you already do, though, which is to provide\npatches to\n>Git when something merges that breaks tests on NonStop. It seems it would\nbe\n>similar in a Rust world, though patches would 'just' be sent to the Rust\nmaintainers\n>instead. (I say that knowing that it would be an entirely foreign codebase\nand set of\n>concerns for submitting correct patches -- so the two are not at all\nsimilar in effort,\n>just in\n>behavior.)\n\nThis is not a tier 3 policy with regards to Rust. It is exclusionary.\n \n>> Depending on a piece of technology where control of where it runs is\n>> outside of git's control is not responsible, in my view. It restricts\n>> where git can run, and excludes platforms that currently use a\n>> critical piece of infrastructure (git).\n>\n>I think this is going to be true of any platform that the Git project\nchooses to\n>continue to build upon, isn't it? Any platform-specific bugs in the various\nC\n>compilers used are not in this project's control, either, nor OpenSSL,\ncURL, PCRE,\n>gettext, etc., etc. that are already essential to Git's main functions when\nit's being\n>used by a human (i.e., not as part of a larger automated system).\n>\n>Any added dependency will run the risk of not being buildable on every\nplatform\n>out there -- even if it's included in the standard library, potentially --\nand I don't\n>believe it's a sustainable practice to never add any dependencies.\n\nI agree that it is not a good policy to never add new dependencies. However,\nDependencies must be reasonable and give the platforms a chance, at least,\nto adapt. We cannot in the case of Rust. The problem is not actually that we\ncan\ndo without new features that are in Rust but not C. The problem is when\nthere\nare CVEs. Suppose a severe CVE happens that is fixed in a Rust component but\nreferenced by a C component or somehow intertwined. The fix to the CVE\nbecomes unavailable and git gets thrown off the platform. That is the\nreality\nof how insidious CVEs are when it meets corporate policy. I am primarily\ntrying\nto protect from that.\n\nIf git was a toy or an experiment, this would not be an issue. But git is\ncore\nInfrastructure for managing and deploying customer facing functionality now,\nmore than any other single piece of code on any platform. It my hope that\nthe\ngit team will finally and eventually understand this, and act accordingly.\n\nIf the component in Rust is a toy or non-core, like Git LFS in GO, it can\nsometimes\nbe worked around. Git LFS was something we wanted to port, but it turns out\nto\nbe irrelevant as restrictions in Cloud GitHub and BitBucket make it pretty\nmuch\nworthless looking into the future.\n\n>> I have tens of thousands of people in my community who depend on git\n>> on a daily basis, and simply kicking them off because of a decision,\n>> or lack of decision, that some unrelated dependency controls should be\n>> (unfortunately does not appear to be for git) a showstopper.\n>\n>I'd like to understand this a little better.\n\nTelling 10-20000 users that their core bit of infrastructure is insecure and\nnot fixable\nis not a tenable position. However, it is hard to defend the community when\nthe git\nteam is hell-bent on this particular decision. What do you need to\nunderstand here?\nIt is a small community with a large number of users in key financial\ninstitutions that\nhave a very conservative adoption policy and an even more conservative\nhardware\nvendors.\n\n>First, from the original notes:\n>>> Emily: old versions aren't going away.\n>which I mention only to supply the obvious counterpoint. I believe you've\nsaid in\n>the past (sorry that I can't find the specific link) that you'd like to see\nGit continue to\n>receive improvements and enhancements that you can forward onto your\n>customers. This is great! I understand this perfectly. I have the very same\ndesire for\n>my users (which number in the 3-4k range). I look forward to every\nperformance\n>improvement and revamped workflow with bated breath -- wondering how/when\n>it can be incorporated into our system to give our folks the best\nexperience they can\n>possibly have as direct users of Git in a heavily automated system.\n\nWhat I should have said was that I have no problem with git adding new\nportable\ndependencies. Rust is fundamentally unportable given the policy restrictions\nImposed by that team.\n\n>\n>It stands to reason that your users wouldn't see such improvements if\nincompatible\n>technologies like Rust are adopted into the codebase and those features\nwere\n>written using this incompatible technology. This is understandably a\nfrustrating\n>prospect! Previously, you would have been able to get even more value out\nof all\n>the open-source effort (and your own effort as a maintainer keeping it\ncompatible) -\n>- and now it's not really feasible. I do understand this sentiment.\n(Regardless of how\n>much I understand it, if this is not _your_ sentiment, please let me know!)\n>\n>Here's where I'm struggling a bit. From what I see, I understand two\ncontradictory\n>points:\n>\n>1. To continue building Git on every platform where it builds today, the\n> project must either\n>\n> a) not add any new incompatible dependencies or\n> b) put any such dependencies behind a feature flag (e.g. NO_CURL) so\n> that Git may continue to be built without that dependency.\n>\n> Great, no harm -- no foul. But...\n>\n>2. If you continue building without that dependency, you don't get that\n> feature, so the original purpose of enhancing Git -- to pass that\n> benefit on to users -- is lost.\n>\n>So it would seem that this leaves us with only option (a) to not add any\nnew\n>incompatible dependencies -- which is what I understand you've been\nproposing.\n>Certainly reasonable. But then how do you build cool new stuff? Well, build\nit\n>yourself, I guess.\n>\n>There's been a _lot_ of cool new stuff lately. This is great! But this does\nseem to be\n>spearheaded by the work (and thus funding) of companies like GitLab,\nMicrosoft,\n>and Google (and these are just the ones I recognize either by contributor\nname or\n>by email domain). I'm incredibly thankful for the work and expertise these\nfolks add\n>to the project on an ongoing basis.\n>\n>I worry though that the 'cool new stuff' seems to require such investment.\nIt is\n>_hard_ to write correct, safe C. I worry that this difficulty will\neventually translate to\n>significant, safe contributions coming only from those with the resources\nto create\n>them and not from a more diverse pool of contributors. As grateful as I am\nto large\n>companies who fund Git contributions, I don't think those companies, given\nthe\n>choice in and of themselves, would think twice about dropping support for a\n>platform they don't use -- and that is probably a much smaller set than\n'does the\n>platform have GCC'. I don't think this is a danger today or tomorrow, but\nit _is_ a\n>danger of not having a diverse group of contributors -- and that is the\ndanger posed\n>by not allowing yourself to use any of the 'cool new stuff' _other_ people\nhave\n>written.\n>\n>--\n>\n>I don't have a satisfying response to what to do for NonStop in a world\nwhere Rust\n>enters the Git codebase. I really don't, and that frustrates me for you. I\nhope that\n>there's a solution out there (maybe from your vendors, maybe from the\nstoried\n>halls of GCC maintainers, who knows), but I'll echo (more earnestly this\ntime):\n>>> Emily: old versions aren't going away.\n\nAgain, it is not the gcc dependency. We have been coping with c99 and will\nhave c11\nshortly. It is Rust itself that is exclusionary. It might be easier to write\nnew\nfunctionality in Rust - it is easier in Java, Perl, and Python too. Why\nRust? Because\nsomeone wants it, not because you cannot implement the functionality.\n\nI do not see giving up on git is an option, but if that is what ultimately\nhappens,\nI think it will be embarrassing and expensive in the extreme for large\nnumbers\nof users. Considering that 90% of all financial transactions quietly and\nwithout\nfanfare touch NonStop hardware at some point, the impact should be obvious\nbut not initially apparent.\n\n>Nobody has the power to 'kick users off' a project such as Git -- not even\nif\n>everyone somehow miraculously agreed to port the entire thing to something\nhot\n>off the presses at /r/programminglanguages :-) Ultimately, your systems\nwill\n>continue to function regardless of what happens upstream. Of course I can't\nspeak\n>to support contracts, but I assume neither can anyone on this list.\n>\n>That said, I also don't know how a project can continue to thrive without\nthe\n>(occasional, thoughtful, and deliberate) introduction of new technologies,\nnew\n>contributors excited and emboldened by those technologies, and new ideas\nfrom\n>those contributors.\n>\n>Change is essential to growth. Like I mentioned at the outset, I'll let the\ntrue experts\n>on this list speak to whether _this_ change is essential for growth, but I\nhope I've at\n>least made some points that were worth reading.\n>\n>[1]:\n>https://lore.kernel.org/git/007c01da4420$10a7b700$31f72500$@nexbridge.co\n>m/\n>[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html\n>\n>--\n>Sean Allred\n\n"},{"id":"503258","messageId":"20240923-spirited-lime-lyrebird-fe90d5@lemur","threadId":"62154","inReplyTo":"xmqqsetr5wl1.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2024-09-23T13:51:49Z","receivedAt":"2024-09-23T13:51:52Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Sun, Sep 22, 2024 at 12:15:22PM GMT, Junio C Hamano wrote:\n> > I know there is also searching for \"#leftoverbits\" or \"low hanging fruit\"\n> > on the list but the \"good-first-issue\" tagged issues on GitGitGadget are\n> > probably more new-contributor-friendly than whole email threads.\n> \n> Yes, even with these search terms, finding an issue to work on from\n> the mailing list archive would not be suited for an absolute newbie\n> for four reasons.\n\nI can chime up and offer bugspray bot integration for the list. This is a new\ntool I've been developing for integrating the mailing list with bugzilla. I've\nbeen using it on the tools mailing list over the past year with reasonable\nsuccess.\n\nIt works something like this:\n\n- a mailing list thread can be turned into a bugzilla entry by saying a\n trigger phrase like \"bugspray track\" or \"bugspray tag \". This\n converts the entire existing thread into a bugzilla bug entry and makes the\n bot follow the conversation, adding any new mailing list messages to the\n bug. This is a two-way bridge, so someone can add things like large debug\n dumps or other files to the bug and have a notification about that go to the\n thread participants. Here's an example of a bug created from a thread using\n the \"bugbot assign to me\" trigger phrase:\n https://bugzilla.kernel.org/show_bug.cgi?id=219230\n\n- the opposite also works: a bug created in bugzilla becomes a mailing list\n thread. Here's an example:\n https://bugzilla.kernel.org/show_bug.cgi?id=218821\n and here's a thread it created:\n https://lore.kernel.org/linux-mmc/20240922-b218821c6-a6dc79e2a03f@bugzilla.kernel.org/T/#t\n\n- git commits are also able to close bugs via the Closes: trailer. E.g. here's\n one example:\n https://bugzilla.kernel.org/show_bug.cgi?id=217359\n\nThe bugspray bot integration is significantly different from Bugzilla's native\nemail support. The goal was specifically to not require bug participants from\ncreating a bugzilla account in order to be able to participate in the\ndiscussion.\n\nBugs can, of course, be easily queried, assigned, and tagged with keywords\nthat can be filtered.\n\nBugspray is still in early development, but I plan to continue expanding its\nset of features, because we hope to make bugzilla actually useful for kernel\nbug reports.\n\n-K\n"},{"id":"503291","messageId":"xmqqbk0exdk4.fsf@gitster.g","threadId":"62154","inReplyTo":"20240923-spirited-lime-lyrebird-fe90d5@lemur","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-23T21:31:07Z","receivedAt":"2024-09-23T21:31:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev writes:\n\n> I can chime up and offer bugspray bot integration for the list. This is a new\n> tool I've been developing for integrating the mailing list with bugzilla. I've\n> been using it on the tools mailing list over the past year with reasonable\n> success.\n\nIntriguing. Everybody loves to hate bugzilla, but would bugzilla\nbecome less smelly with bugspray enough to make it palatable to all\nof us?\n\n> Bugs can, of course, be easily queried, assigned, and tagged with keywords\n> that can be filtered.\n>\n> Bugspray is still in early development, but I plan to continue expanding its\n> set of features, because we hope to make bugzilla actually useful for kernel\n> bug reports.\n\n;-)\n"},{"id":"503349","messageId":"ZvKs6BrX-Ht7sFJN@pks.im","threadId":"62154","inReplyTo":"0864bd25-d5c4-45ac-a59e-e6f7d24002de@gentoo.org","subject":"Re: [TOPIC 08/11] Modern Build Systems","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-24T12:13:28Z","receivedAt":"2024-09-24T12:13:26Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sun, Sep 22, 2024 at 10:01:32PM -0400, Eli Schwartz wrote:\n> On 9/20/24 10:21 AM, Taylor Blau wrote:\n> > Modern Build System\n> > ===================\n> > \n> > (moderator: Patrick; notetaker: brian)\n> > \n> > * Patrick: three different build system; should get rid of at least one\n> > of them\n> > * Should delete autoconf because it's not really maintained\n> > * Think about a proper build system\n> > * Obvious choice: cmake\n> > * Taylor: What's the problem with Makefiles\n> > * Patrick: Non-standard\n> > * Meson is nicer than cmake as an alternative\n> \n> \n> I suppose I'm pretty biased but yes, I do feel we (meson) have managed\n> to make some great workflow improvements here. :)\n> \n> Please do feel free to ask me questions about it.\n> \n> \n> > * Jonathan: xz compromise shows autoconf is a risk\n> > * Autoconf isn't a problem for distro\n> > * Taylor: distro builds that can't handle \"make\" without configure are a\n> > distro problem\n> \n> \n> Anyone can handle \"make\" without configure without breaking a sweat,\n> that isn't even remotely challenging, and every distro already does it.\n> The problem is that \"make\" is stateless, which is another way of saying\n> it has amnesia. By that token, everyone cobbles together their own state\n> system on top of \"make\".\n> \n> Admittedly, once set up it doesn't require much maintenance from version\n> bump to version bump.\n> \n> \n> > * Jonathan: Modern build system can reflect the structure of how your\n> > code is set up\n> > * Declared dependencies\n> > * Brian: Rust will make the decision for us: cargo\n> \n> \n> I would just like to note that this is not really true. There is one\n> other build system that supports rust and its name is... meson. :)\n> \n> Meson supports rust as a language for creating libraries (cdylib or\n> rlib) and executables. You can import a crate from crates.io and meson\n> will synthesize the build system from the existing Cargo.toml to expose\n> it as an rlib dependency.\n> \n> You still get full build script option parsing, system probing, control\n> flow etc using the meson.build DSL, you can freely mix libraries or\n> executables in any of meson's supported languages (C, C++, Cython, C#,\n> D, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands\n> for data files, run gettext on translations, and more. Meson is designed\n> to be a polyglot build system in ways that cargo will probably never be.\n> \n> Cargo is probably best thought of as a compiler wrapper: it can spit out\n> an executable if you run it on *.rs sources, but it doesn't replace most\n> of the interesting parts of a build system and it doesn't even provide\n> an \"install\" rule. No, `cargo install` does not count unfortunately as\n> it has a nasty habit of recompiling the binaries you already compiled,\n> but now with the wrong options.\n> \n> You really want something that provides a project lifecycle workflow for\n> building, testing, installing, and making dist tarballs with integrated\n> distcheck. The current Makefiles mostly kind of work, given sufficient\n> care, but cargo provides exactly zero of anything so you're back to\n> cobbling together your entire workflow using Makefiles wrapped around\n> cargo. I would call that the very furthest opposite from \"make the\n> decision for us\".\n> \n> \n> > * BSDs use Make (granted, not GNU make) for building\n> > * Patrick: Is anyone else in favour of a proper build system\n> > * Ninja is way faster than make to build the projects\n> \n> \n> It is! Yes. Mostly because it does very, very little other than execute\n> a precalculated build graph, whereas the current Makefile runs a bunch\n> of stateless external commands each time in order to calculate top-level\n> Make variables.\n> \n> \n> > * Taylor: Feels odd to build with a fancy tool that might have a\n> > dependency on Git\n> > * Dscho: --help is a autoconf feature and removed features are detected\n> > * Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes\n> \n> \n> cmake does not have an equivalent of ./configure --help. The best you\n> can get is to try to somehow successfully configure cmake once, and then\n> run a cmake command that prints every internal control flow variable\n> used by cmake, then hope that the ones you care about include descriptions.\n> \n> (Say what you will about GNU autotools but they knew very well how to\n> write good interaction standards, as evidenced by all the Makefile\n> variables git.git already uses from the GNU Coding Standards docs on how\n> to architect a release process.) It is fundamental to the UX design of\n> ./configure that a user may query the build system to find out what\n> choices they can / are expected to make, before committing to those choices.\n> \n> cmake is actively a severe regression compared to autoconf for these\n> purposes.\n> \n> \n> > * Kyle: Editor integration is useful\n> > * brian: standard structure is helpful for LSPs\n> \n> \n> These tend to mostly be solved by compile_commands.json, which most\n> modern build systems can produce. In particular, anything that creates a\n> ninja file essentially gets you this for free, because ninja can create\n> one for you.\n> \n> Plain Makefiles, and GNU automake, don't do very well at this at all,\n> since Make has too irregular a build graph to reliably compute any such\n> thing. Same reason why there isn't much in the way of dedicated editor\n> integration (both cmake and meson have introspection APIs which editor\n> plugins can use to directly query info from the build system, to provide\n> finer-grained control than what compile_commands.json can do).\n> \n> \n> > * Emily: libification has shown that makefile is cumbersome\n> > * Jonathan: Should we do a comparison of build systems in terms of what\n> > we need from them on the list? Similar to\n> > Documentation/technical/unit-tests.txt\n> > * Patrick: I can write such a thing.\n> > * Patrick: Are their any features we need to consider?\n> > * Johannes Sixt: Consider supported platforms\n> > * Patrick: Want to verify that cmake is up to the task by testing in CI?\n> > * Will volunteer to post something to the list\n\nThanks for your input, Eli, I highly appreciate it to get feedback from\na distro maintainer's point of view! I'm not going to answer here,\nbecause there already is an ongoing thread at [1].\n\nSo I'd propose to consolidate it into that thread. I've put you into Cc\nthere.\n\nPatrick\n\n[1]: \n"},{"id":"503365","messageId":"18d732da-ad34-4a45-b59f-cf2cb3c7238b@gmail.com","threadId":"62154","inReplyTo":"00a501db0db2$94d505d0$be7f1170$@nexbridge.com","subject":"Re: [TOPIC 01/11] Rust","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-24T15:30:03Z","receivedAt":"2024-09-24T15:30:06Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Randall\n\nOn 23/09/2024 13:17, rsbecker@nexbridge.com wrote:\n> On September 22, 2024 10:26 PM, Sean Allred wrote:\n> \n> The GCC dependency, which does not currently exist in git, is independent of\n> Rust. > Rust has its own rules and runtime. The issue here is that the Rust team\n> gets to\n> decide what platforms can participate, NOT the platform maintainers. No\n> matter\n> what my intent, or resources, I cannot get the Rust team to \"Allow\" a port.\n> In\n> many ways, this is egregious and is a policy issue entirely on Rust, not us.\n> We\n> want to do a Rust port but are simply not allowed/approved. It is their\n> policy.\n\nI'm hearing that there is a fundamental incompatibility between some \naspect of the NonStop platform and rust's requirements for supported \nplatforms. Does that mean it is likely that rust will never be available \non NonStop?\n\n> I agree that it is not a good policy to never add new dependencies. However,\n> Dependencies must be reasonable and give the platforms a chance, at least,\n> to adapt. We cannot in the case of Rust. The problem is not actually that we\n> can\n> do without new features that are in Rust but not C. The problem is when\n> there\n> are CVEs. Suppose a severe CVE happens that is fixed in a Rust component but\n> referenced by a C component or somehow intertwined. The fix to the CVE\n> becomes unavailable and git gets thrown off the platform. That is the\n> reality\n> of how insidious CVEs are when it meets corporate policy. I am primarily\n> trying\n> to protect from that.\n\nIn that scenario there is nothing preventing a different fix being \nimplemented for an older version of git running on a platform that does \nnot support rust. It's likely that such a fix would need to come from \nthe community using that platform rather than upstream which would \nrepresent an additional cost for users that have previously been relying \non the upstream to provide security updates.\n\n> Telling 10-20000 users that their core bit of infrastructure is insecure and\n> not fixable\n> is not a tenable position. However, it is hard to defend the community when\n> the git\n> team is hell-bent on this particular decision. What do you need to\n> understand here?\n> It is a small community with a large number of users in key financial\n> institutions that\n> have a very conservative adoption policy and an even more conservative\n> hardware\n> vendors.\n\nI'm struggling to understand why such a conservative community needs \naccess to the latest version of git. I'd have thought that key financial \ninstitutions should be able to fund someone to backport security updates \nto their critical systems.\n\n> Again, it is not the gcc dependency. We have been coping with c99 and will\n> have c11\n> shortly. It is Rust itself that is exclusionary. It might be easier to write\n> new\n> functionality in Rust - it is easier in Java, Perl, and Python too. Why\n> Rust? Because\n> someone wants it, not because you cannot implement the functionality.\n\nIt may be true in theory that anything one can write in rust could be \nwritten in C instead but in I'm not sure it is true in practice. In \nprevious discussions multi-threading has been mentioned as an example of \nsomething that is sufficiently difficult to get right in C that \ncontributors are not willing to implement whereas they would be happy to \ndo so in rust.\n\nI believe that those advocating for using rust are doing so because they \nbelieve it will benefit both contributors and users. The problem we have \nto wrestle with is whether those benefits outweigh the cost to the \nrelatively small proportion of users who do not have access to rust on \ntheir platform.\n\nBest Wishes\n\nPhillip\n"},{"id":"503386","messageId":"20240924-sawfish-of-exotic-fantasy-b6abdb@meerkat","threadId":"62154","inReplyTo":"xmqqbk0exdk4.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2024-09-24T18:06:07Z","receivedAt":"2024-09-24T18:06:08Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Mon, Sep 23, 2024 at 02:31:07PM GMT, Junio C Hamano wrote:\n> > I can chime up and offer bugspray bot integration for the list. This is a new\n> > tool I've been developing for integrating the mailing list with bugzilla. I've\n> > been using it on the tools mailing list over the past year with reasonable\n> > success.\n> \n> Intriguing. Everybody loves to hate bugzilla, but would bugzilla\n> become less smelly with bugspray enough to make it palatable to all\n> of us?\n\nI'm happy to enable it for this list if you'd like to try this out. It doesn't\nreally create any obligation to use it, but it may end up being something\nuseful.\n\nTo enable it, I only need a list of people who are allowed to trigger bugspray\nvia the \"bugspray track\" trigger phrase. I assume it's going to be more than\njust you?\n\n-K\n"},{"id":"503390","messageId":"xmqqmsjwsw1q.fsf@gitster.g","threadId":"62154","inReplyTo":"20240924-sawfish-of-exotic-fantasy-b6abdb@meerkat","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-24T19:15:13Z","receivedAt":"2024-09-24T19:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev writes:\n\n> On Mon, Sep 23, 2024 at 02:31:07PM GMT, Junio C Hamano wrote:\n>> > I can chime up and offer bugspray bot integration for the list. This is a new\n>> > tool I've been developing for integrating the mailing list with bugzilla. I've\n>> > been using it on the tools mailing list over the past year with reasonable\n>> > success.\n>> \n>> Intriguing. Everybody loves to hate bugzilla, but would bugzilla\n>> become less smelly with bugspray enough to make it palatable to all\n>> of us?\n>\n> I'm happy to enable it for this list if you'd like to try this out. It doesn't\n> really create any obligation to use it, but it may end up being something\n> useful.\n>\n> To enable it, I only need a list of people who are allowed to trigger bugspray\n> via the \"bugspray track\" trigger phrase. I assume it's going to be more than\n> just you?\n\nNow we'll have to come up with and maintain an official list of\ntrusted contributors. Which at first may sound like such a list may\nalianate those who did not make the list, but when deciding which\ntopics are ready to hit 'next', such a \"selection\" is implicitly\nmade to choose whose opinion weigh more anyway.\n\nIt might make the process more transparent to formalize the \"more\ntrusted contributors\" list.\n\nI suspect that the list of folks who can operator bugspray do not\nnecessarily have to be with deep technical knowledge of the innards\nof Git. They have to be able to dedicate the time to read and\nunderstand what was said in the discussion threads, recognise when a\nproblem is identified (\"bugspray track\"), have been long enough to\nknow or able to use \"git blame / git log\" to see who likely has\nuseful insight into the issue than others (\"bugspray tag\"?), and\nhave good enough taste to recognise irrelevant \"bugs\" that are\nopened by those with worse taste. In a sense, it is very different\nfrom the earlier \"list of those whose opinion weigh more in\nassessing topic's doneness\". Competent \"project secretaries\" are\nthe kinds of people we want.\n\nIf I misunderstood the nature of \"allow-list\" for trigger phrase,\nplease correct me. Also it would be very welcome to hear from those\nlistening in from the sidelines who want to see different kinds of\npeople to be on the trigger phrase list.\n\nThanks.\n\n\n\n\n\n"},{"id":"503391","messageId":"20240924-loud-honeybee-of-development-d2f893@meerkat","threadId":"62154","inReplyTo":"xmqqmsjwsw1q.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2024-09-24T19:23:41Z","receivedAt":"2024-09-24T19:23:44Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Sep 24, 2024 at 12:15:13PM GMT, Junio C Hamano wrote:\n> > To enable it, I only need a list of people who are allowed to trigger bugspray\n> > via the \"bugspray track\" trigger phrase. I assume it's going to be more than\n> > just you?\n> \n> Now we'll have to come up with and maintain an official list of\n> trusted contributors. Which at first may sound like such a list may\n> alianate those who did not make the list, but when deciding which\n> topics are ready to hit 'next', such a \"selection\" is implicitly\n> made to choose whose opinion weigh more anyway.\n\nYeah, you're overthinking this. :) I literally just want to restrict the\nability to invoke bugspray to a limited number of people, at least for the\ntime being -- to avoid a situation like a troll sending \"bugspray track\" to\nevery possible thread. \n\nThe people on this list don't have to have any kind of official standing with\nthe git project itself.\n\n> I suspect that the list of folks who can operator bugspray do not\n> necessarily have to be with deep technical knowledge of the innards\n> of Git. They have to be able to dedicate the time to read and\n> understand what was said in the discussion threads, recognise when a\n> problem is identified (\"bugspray track\"), have been long enough to\n> know or able to use \"git blame / git log\" to see who likely has\n> useful insight into the issue than others (\"bugspray tag\"?),\n\nFYI, \"bugspray tag\" assigns the bug in bugzilla to a specific person. If you\ndon't intend to use bugzilla to this degree, you can ignore this aspect of it\nentirely and never use the tag command.\n\n> and have good enough taste to recognise irrelevant \"bugs\" that are\n> opened by those with worse taste. In a sense, it is very different\n> from the earlier \"list of those whose opinion weigh more in\n> assessing topic's doneness\". Competent \"project secretaries\" are\n> the kinds of people we want.\n> \n> If I misunderstood the nature of \"allow-list\" for trigger phrase,\n> please correct me. Also it would be very welcome to hear from those\n> listening in from the sidelines who want to see different kinds of\n> people to be on the trigger phrase list.\n\nHopefully, I clarified it a bit. Also, bugspray is still an early model, so I\nam happy to add functionality based on the feedback I receive.\n\n-K\n"},{"id":"503448","messageId":"018401db0ed3$667bcf80$33736e80$@nexbridge.com","threadId":"62154","inReplyTo":"18d732da-ad34-4a45-b59f-cf2cb3c7238b@gmail.com","subject":"RE: [TOPIC 01/11] Rust","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-09-24T22:44:59Z","receivedAt":"2024-09-24T22:45:18Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 24, 2024 11:30 AM, Phillip Wood wrote:\n>On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:\n>> On September 22, 2024 10:26 PM, Sean Allred wrote:\n>>\n>> The GCC dependency, which does not currently exist in git, is\n>> independent of Rust. > Rust has its own rules and runtime. The issue\n>> here is that the Rust team gets to decide what platforms can\n>> participate, NOT the platform maintainers. No matter what my intent,\n>> or resources, I cannot get the Rust team to \"Allow\" a port.\n>> In\n>> many ways, this is egregious and is a policy issue entirely on Rust, not us.\n>> We\n>> want to do a Rust port but are simply not allowed/approved. It is\n>> their policy.\n>\n>I'm hearing that there is a fundamental incompatibility between some aspect of the\n>NonStop platform and rust's requirements for supported platforms. Does that\n>mean it is likely that rust will never be available on NonStop?\n\nI do not know whether Rust will never be available. The policy is that the Rust\nmaintainers must sanction and approve any ports. I have tried to get approval\nand have not been able to do so. It is not for a lack of trying. To me, this is a\nserious problem because there is no \"community\" concept for Rust. It is either\nsanctioned or denied, regardless of the desire of someone to port the code.\n\n>> I agree that it is not a good policy to never add new dependencies.\n>> However, Dependencies must be reasonable and give the platforms a\n>> chance, at least, to adapt. We cannot in the case of Rust. The problem\n>> is not actually that we can do without new features that are in Rust\n>> but not C. The problem is when there are CVEs. Suppose a severe CVE\n>> happens that is fixed in a Rust component but referenced by a C\n>> component or somehow intertwined. The fix to the CVE becomes\n>> unavailable and git gets thrown off the platform. That is the reality\n>> of how insidious CVEs are when it meets corporate policy. I am\n>> primarily trying to protect from that.\n>\n>In that scenario there is nothing preventing a different fix being implemented for an\n>older version of git running on a platform that does not support rust. It's likely that\n>such a fix would need to come from the community using that platform rather than\n>upstream which would represent an additional cost for users that have previously\n>been relying on the upstream to provide security updates.\n\nThis means that the community is responsible separate for CVE security fixes.\nI have a major problem with that. It means that there will be separate NIST\nand Mitre reports for security issues for the same case. The code will then\nforever deviate and git will no longer be one product. It also means that\ncustomers can no longer consider the official git to be available on NonStop\nbut will have to come from an unsanctioned community edition that will\nlag behind all security fixes associated with Rust code.\n\n>\n>> Telling 10-20000 users that their core bit of infrastructure is\n>> insecure and not fixable is not a tenable position. However, it is\n>> hard to defend the community when the git team is hell-bent on this\n>> particular decision. What do you need to understand here?\n>> It is a small community with a large number of users in key financial\n>> institutions that have a very conservative adoption policy and an even\n>> more conservative hardware vendors.\n>\n>I'm struggling to understand why such a conservative community needs access to\n>the latest version of git. I'd have thought that key financial institutions should be\n>able to fund someone to backport security updates to their critical systems.\n\nThe community does not need access to the latest version. It *does* need\naccess to security fixes made in response to CVE reports. As above, being\nable to backport security fixes means that git is no longer officially the\nsame, nor can be verified as legitimate once this is done.\n\n>\n>> Again, it is not the gcc dependency. We have been coping with c99 and\n>> will have c11 shortly. It is Rust itself that is exclusionary. It\n>> might be easier to write new functionality in Rust - it is easier in\n>> Java, Perl, and Python too. Why Rust? Because someone wants it, not\n>> because you cannot implement the functionality.\n>\n>It may be true in theory that anything one can write in rust could be written in C\n>instead but in I'm not sure it is true in practice. In previous discussions multi-\n>threading has been mentioned as an example of something that is sufficiently\n>difficult to get right in C that contributors are not willing to implement whereas they\n>would be happy to do so in rust.\n\nMy position, as a professional product manager, is that such changes should not\nbe approved.\n\n>\n>I believe that those advocating for using rust are doing so because they believe it will\n>benefit both contributors and users. The problem we have to wrestle with is\n>whether those benefits outweigh the cost to the relatively small proportion of users\n>who do not have access to rust on their platform.\n\nI would be very happy to have Rust on the platform. I do not control the situation\neven if I have the skill to do the port. This is entirely unfair, in my opinion, to the\ncommunity maintainers, (me for one) who are going to end up doing far more\nwork for free than anyone else.\n\nI am sorry to disagree, but I cannot see any way around the problem that makes\nsense. I have been the NonStop maintainer since 2016, and feel like I am being\nnow being thrown under a bus outside of any of my control. If there is a way to\nsolve this, without this becoming my full time (for free) job, I would consider it.\n(Note that the git license (GPL) requires me to contribute my changes, so it is\nbeing done for free even if I find a way to charge for it.) Honestly, is that\nreasonable?\n\n"},{"id":"503610","messageId":"m0msjtmo81.fsf@epic96565.epic.com","threadId":"62154","inReplyTo":"018401db0ed3$667bcf80$33736e80$@nexbridge.com","subject":"Re: [TOPIC 01/11] Rust","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2024-09-27T09:37:34Z","receivedAt":"2024-09-27T09:37:39Z","isPatch":false,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":" writes:\n> I do not know whether Rust will never be available. The policy is that the Rust\n> maintainers must sanction and approve any ports. I have tried to get approval\n> and have not been able to do so. It is not for a lack of trying.\n\nI do not see a proposal for \"NonStop\" in a pull request filed against\nrust-lang/rust[2] per the process laid out by [1]; can you point me to\nwhere you submitted this request?\n\n[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html\n[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop\n\n-- \nSean Allred\n"},{"id":"503612","messageId":"4e2b5740-6863-4ab6-8483-2e933b4c427c@gmail.com","threadId":"62154","inReplyTo":"xmqqbk0exdk4.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-27T10:08:19Z","receivedAt":"2024-09-27T10:08:25Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 23/09/2024 22:31, Junio C Hamano wrote:\n> Konstantin Ryabitsev writes:\n> \n>> I can chime up and offer bugspray bot integration for the list. This is a new\n>> tool I've been developing for integrating the mailing list with bugzilla. I've\n>> been using it on the tools mailing list over the past year with reasonable\n>> success.\n> \n> Intriguing. Everybody loves to hate bugzilla, but would bugzilla\n> become less smelly with bugspray enough to make it palatable to all\n> of us?\n\nIf it's easy to set up it might be worth a try. My memories of using \nbugzilla in the past are that it wasn't too bad for issue tracking. Most \nof the pain came from trying to use it to review patches which we \nwouldn't be doing.\n\nBest Wishes\n\nPhillip\n\n>> Bugs can, of course, be easily queried, assigned, and tagged with keywords\n>> that can be filtered.\n>>\n>> Bugspray is still in early development, but I plan to continue expanding its\n>> set of features, because we hope to make bugzilla actually useful for kernel\n>> bug reports.\n> \n> ;-)\n> \n"},{"id":"503615","messageId":"032401db10d8$141962f0$3c4c28d0$@nexbridge.com","threadId":"62154","inReplyTo":"m0msjtmo81.fsf@epic96565.epic.com","subject":"RE: [TOPIC 01/11] Rust","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-09-27T12:23:31Z","receivedAt":"2024-09-27T12:23:42Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 27, 2024 5:38 AM, Sean Allred wrote:\n> writes:\n>> I do not know whether Rust will never be available. The policy is that\n>> the Rust maintainers must sanction and approve any ports. I have tried\n>> to get approval and have not been able to do so. It is not for a lack of\ntrying.\n>\n>I do not see a proposal for \"NonStop\" in a pull request filed against rust-\n>lang/rust[2] per the process laid out by [1]; can you point me to where you\n>submitted this request?\n>\n>[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html\n>[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop\n\nI will investigate where this went.\n\n"},{"id":"503617","messageId":"035001db1104$528b16b0$f7a14410$@nexbridge.com","threadId":"62154","inReplyTo":"032401db10d8$141962f0$3c4c28d0$@nexbridge.com","subject":"RE: [TOPIC 01/11] Rust","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-09-27T17:40:13Z","receivedAt":"2024-09-27T17:40:25Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 27, 2024 8:24 AM, I wrote:\n>On September 27, 2024 5:38 AM, Sean Allred wrote:\n>> writes:\n>>> I do not know whether Rust will never be available. The policy is\n>>> that the Rust maintainers must sanction and approve any ports. I have\n>>> tried to get approval and have not been able to do so. It is not for\n>>> a lack of\n>trying.\n>>\n>>I do not see a proposal for \"NonStop\" in a pull request filed against\n>>rust- lang/rust[2] per the process laid out by [1]; can you point me to\n>>where you submitted this request?\n>>\n>>[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html\n>>[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop\n>\n>I will investigate where this went.\n\nI have taken this up with the platform vendor. Any request of this sort\nneeds to come from them, in my opinion, even if I do the port.\n\nI will advise the list if I get anywhere.\n\n"},{"id":"503620","messageId":"xmqqed54gauq.fsf@gitster.g","threadId":"62154","inReplyTo":"4e2b5740-6863-4ab6-8483-2e933b4c427c@gmail.com","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-27T19:22:53Z","receivedAt":"2024-09-27T19:22:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> On 23/09/2024 22:31, Junio C Hamano wrote:\n>> Konstantin Ryabitsev writes:\n>> \n>>> I can chime up and offer bugspray bot integration for the list. This is a new\n>>> tool I've been developing for integrating the mailing list with bugzilla. I've\n>>> been using it on the tools mailing list over the past year with reasonable\n>>> success.\n>> Intriguing. Everybody loves to hate bugzilla, but would bugzilla\n>> become less smelly with bugspray enough to make it palatable to all\n>> of us?\n>\n> If it's easy to set up it might be worth a try. My memories of using\n> bugzilla in the past are that it wasn't too bad for issue\n> tracking. Most of the pain came from trying to use it to review\n> patches which we wouldn't be doing.\n\nThe biggest pain point I remember with bugzilla was to find bugs\nthat are still relevant to make sure they are assigned to somebody.\nIOW, curating the collection to make sure false alarms are marked as\nsuch quickly enough.\n\nThanks.\n"},{"id":"503843","messageId":"3eb55b24-0890-4093-abf5-362b35cab1bd@gmail.com","threadId":"62154","inReplyTo":"xmqqed54gauq.fsf@gitster.g","subject":"Re: [TOPIC 07/11] New Contributors and Discord","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-10-01T15:23:50Z","receivedAt":"2024-10-01T15:23:53Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 27/09/2024 20:22, Junio C Hamano wrote:\n> Phillip Wood writes:\n> \n>> If it's easy to set up it might be worth a try. My memories of using\n>> bugzilla in the past are that it wasn't too bad for issue\n>> tracking. Most of the pain came from trying to use it to review\n>> patches which we wouldn't be doing.\n> \n> The biggest pain point I remember with bugzilla was to find bugs\n> that are still relevant to make sure they are assigned to somebody.\n> IOW, curating the collection to make sure false alarms are marked as\n> such quickly enough.\n\nThat's certainly a pain, but I don't think it's specific to bugzilla \nthough. I agree that to be useful the list of bugs needs curating.\n\nBest Wishes\n\nPhillip\n"}]}