{"thread":{"id":"60829","subject":"Migrate away from vger to GitHub or (on-premise) GitLab?","startedAt":"2024-02-01T12:10:14Z","lastAt":"2024-02-06T08:06:24Z","messageCount":48,"participants":["Hans Meiser","Kristoffer Haugsbakk","Antonin Delpeuch","Dragan Simic","Konstantin Ryabitsev","Nico Williams","rsbecker@nexbridge.com","brian m. carlson","Patrick Steinhardt","Phillip Wood","Michal Suchánek","Sergey Organov","Theodore Ts'o","Junio C Hamano","Oswald Buddenhagen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"487738","messageId":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"AS2P195MB21350F44B079009C05A1EAF1E2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-01T12:10:11Z","receivedAt":"2024-02-01T12:10:14Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"Hi,\n\nis there any current discussion about moving Git development away from using a mailing list to some modern form of collaboration?\n\nI'd like to be able to follow a structured discussion in issues and to contribute to the Git documentation, but the mailing list currently just bloats my personal inbox with loads of uninteresting e-mails in an unstructured waterfall of messy discussion that I am not able to follow professionally.\n\nAre you consideration for migrating?\n\nRegards,\nAxel Dahmen"},{"id":"487739","messageId":"ada5564d-d810-4707-83b8-c00a7b5aa79f@app.fastmail.com","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-02-01T12:21:15Z","receivedAt":"2024-02-01T12:21:38Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"Hi\n\nOn Thu, Feb 1, 2024, at 13:10, Hans Meiser wrote:\n> Hi,\n>\n> Regards,\n> Axel Dahmen\n\nA relevant discussion seems to be “Improving new contrib onboarding”[1]\n\nThere’s GitGitGadget for people who want to use GitHub as a bridge[2]\n\nThere’s an unofficial issue tracker for project ideas (not for bugs)[3]\n\nThat’s what I know.\n\n🔗 1: https://lore.kernel.org/git/ZRrgMDacYpj41DcO@nand.local/\n🔗 2: https://gitgitgadget.github.io/\n🔗 3: https://github.com/gitgitgadget/git/issues\n\n-- \nKristoffer Haugsbakk\n"},{"id":"487740","messageId":"213029f5-63db-4fa6-9c88-2aebd0df9a15@delpeuch.eu","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Antonin Delpeuch","fromEmail":"antonin@delpeuch.eu","sentAt":"2024-02-01T12:20:27Z","receivedAt":"2024-02-01T12:25:42Z","isPatch":false,"sender":{"key":"antonin@delpeuch.eu","avatar":"https://avatars.githubusercontent.com/u/309908?v=4"},"body":"Hi Hans,\n\nAs a new contributor I have also been wondering about that and I found\nthe notes of the 2023 contributor summit very interesting in this regard:\n\nhttps://docs.google.com/document/d/1GKoYtVhpdr_N2BAonYsxVTpPToP1CgCS9um0K7Gx9gQ/edit#heading=h.bdw77tvsksnr\n\nThere is a section on \"Project management practices\" which touches on\nthis topic, with the idea of using a bug tracker being raised for\ninstance. So you are not the only one thinking about it at least.\n\nFor what it's worth, I have written up a small report about my\ncontribution experience (which covers project management practices):\n\nhttps://antonin.delpeuch.eu/posts/contribution-experience-report-git/\n\nBest,\n\nAntonin\n\nOn 01/02/2024 13:10, Hans Meiser wrote:\n> Hi,\n>\n> is there any current discussion about moving Git development away from using a mailing list to some modern form of collaboration?\n>\n> I'd like to be able to follow a structured discussion in issues and to contribute to the Git documentation, but the mailing list currently just bloats my personal inbox with loads of uninteresting e-mails in an unstructured waterfall of messy discussion that I am not able to follow professionally.\n>\n> Are you consideration for migrating?\n>\n> Regards,\n> Axel Dahmen\n"},{"id":"487741","messageId":"cf4a0ac7850a9b1e4597830bfd5e1c42@manjaro.org","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T12:56:08Z","receivedAt":"2024-02-01T12:56:10Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello,\n\nOn 2024-02-01 13:10, Hans Meiser wrote:\n> is there any current discussion about moving Git development away from\n> using a mailing list to some modern form of collaboration?\n> \n> I'd like to be able to follow a structured discussion in issues and to\n> contribute to the Git documentation, but the mailing list currently\n> just bloats my personal inbox with loads of uninteresting e-mails in\n> an unstructured waterfall of messy discussion that I am not able to\n> follow professionally.\n> \n> Are you consideration for migrating?\n\nPerhaps it would be good to also know that many people simply don't\nlive in a web browser, so to speak, and live in the CLI instead. For\nsuch people, having to use a web browser for development is simply,\nwell, awkward and inefficient.\n\nIn other words, as much as not using some more modern, web-based\ntools may drive some people away, there's also exactly the opposite\nreaction that should also be considered.\n\nThere was recently some similar discussion for another open-source\nproject, but I simply can't find it now. :/\n"},{"id":"487747","messageId":"20240201-primitive-aardwark-of-contentment-aaabb9@lemur","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2024-02-01T15:39:04Z","receivedAt":"2024-02-01T15:39:09Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:\n> is there any current discussion about moving Git development away from using\n> a mailing list to some modern form of collaboration?\n> \n> I'd like to be able to follow a structured discussion in issues and to\n> contribute to the Git documentation, but the mailing list currently just\n> bloats my personal inbox with loads of uninteresting e-mails in an\n> unstructured waterfall of messy discussion that I am not able to follow\n> professionally.\n\nHere's a perspective from the world of Linux kernel, where this discussion is\ncontinuously raging. Funny enough, the main objection a lot of kernel\nmaintainers have to forges is that it makes it really hard to find relevant\ndiscussions once the volume goes above a certain threshold. These folks have\nbecome *extremely* efficient at querying and filtering the mailing list\ntraffic, to the point where all they ever see are just those discussions\nrelevant to their work. They love the fact that it all arrives into the same\nplace (their inbox) without having to go and click on various websites, each\nwith their own login information, UI, and preferred workflow.\n\nThe kernel maintainers are able to review tens of thousands of patches monthly\nwith only about a hundred or so top maintainers. To them, this system is\nworking great, especially now that some tools allow easy ways to query,\nretrieve, verify, and apply patches (shameless plug for lore, lei, and b4\nhere).\n\nThe obvious problem, of course, is that these folks are FOSS's \"marathon\nrunners\" who got really good at their workflow, but the situation is different\nfor anyone else who is just starting out. Any new kernel maintainer stepping\nup obviously finds this overwhelming, because they aren't yet so good at\nfiltering the huge volume of the mailing list traffic and to them it's just a\ntorrent of mostly irrelevant patches.\n\n> Are you consideration for migrating?\n\nYes, of course, this is constantly under consideration. There isn't some sort\nof anti-forge cabal that is preventing things from going forward, but there\nare some serious hurdles and considerations to consider:\n\n- How to avoid a vendor lock-in? Those of us who have been around for a while\n have seen forges bloom, and then shrink into irrelevance (e.g. bitkeeper)\n or slowly ensh*ttify to the point of unusability (sourceforge). GitHub is a\n proprietary service owned by a single company who are currently\n FOSS-friendly, but have certainly been extremely FOSS-hostile in the past.\n GitLab is open-core, and the current record for open-core projects isn't\n very encouraging (Puppet open-cored themselves into irrelevance, Terraform\n has gone full-proprietary, among most recent examples). Full-FOSS\n alternatives exist, but people aren't really that enthused about using\n less-popular solutions like Forgejo, because they hate unfamiliar UIs almost\n as much, or even more than they hate unfiltered mailing lists.\n\n- How to avoid centralization and single points of failure? If Linux or Git\n move to a self-hosted forge, how do we ensure that an adversary can't stop\n all development on a project by knocking it offline for weeks? This has\n literally just happened to Sourcehut and Codeberg -- and as far as anyone\n can tell, the attacker was just bored and knocked them out just because they\n could. Yes, you can knock out vger, but this will only impact the mailing\n list -- people can still send around patches and hold discussions by\n temporarily moving to alternative hosts. With the distributed nature of the\n mailing list archives, this can even be largely transparent to anyone using\n lei-queries.\n\n- How to avoid alienating these hundreds of key maintainers who are now\n extremely proficient at their query-based workflows? We're talking about an\n extremely finely-tuned engine that is performing remarkably well -- we don't\n want to disrupt development for months just to try things out with a forge\n and find that it isn't working out.\n\nFinally, there's also the consideration of current trends. One upside of \"AI\"\n(LLM, really) technologies is that they are extremely good at taking in a huge\nsource of data and finding relevant information based on natural language\nqueries. I can very easily see a mechanism spring up in the next year or less\nwhere you can issue a query like \"send me any threads about reftables or\npromissory remotes if they contain follow-ups from Junio\" and reasonaly expect\nthis to work and work great -- all while keeping things decentralized in\naddition to distributed.\n\nAbove all, this isn't a \"forges are terrible and shouldn't be used\" response\n-- they are clearly useful, especially when it comes to CI integrations. A\nlarge part of my work is bridging forges with mailing lists and vice-versa,\nwhich I hope I'll be able to do in the near future (GitGitGadget already does\nit with GitHub, but my goal is to have a pluggable multi-forge solution). I\njust wanted to highlight the aspects that aren't necessarily obvious or\nvisible from the outside.\n\nBest regards,\n-K\n"},{"id":"487753","messageId":"7e395301c5ff46a69d8aca71eb0bb766@manjaro.org","threadId":"60829","inReplyTo":"20240201-primitive-aardwark-of-contentment-aaabb9@lemur","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T16:54:23Z","receivedAt":"2024-02-01T16:54:25Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Konstantin,\n\nOn 2024-02-01 16:39, Konstantin Ryabitsev wrote:\n> On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:\n>> is there any current discussion about moving Git development away from \n>> using\n>> a mailing list to some modern form of collaboration?\n>> \n>> I'd like to be able to follow a structured discussion in issues and to\n>> contribute to the Git documentation, but the mailing list currently \n>> just\n>> bloats my personal inbox with loads of uninteresting e-mails in an\n>> unstructured waterfall of messy discussion that I am not able to \n>> follow\n>> professionally.\n> \n> Here's a perspective from the world of Linux kernel, where this \n> discussion is\n> continuously raging. Funny enough, the main objection a lot of kernel\n> maintainers have to forges is that it makes it really hard to find \n> relevant\n> discussions once the volume goes above a certain threshold. These folks \n> have\n> become *extremely* efficient at querying and filtering the mailing list\n> traffic, to the point where all they ever see are just those \n> discussions\n> relevant to their work. They love the fact that it all arrives into the \n> same\n> place (their inbox) without having to go and click on various websites, \n> each\n> with their own login information, UI, and preferred workflow.\n> \n> The kernel maintainers are able to review tens of thousands of patches \n> monthly\n> with only about a hundred or so top maintainers. To them, this system \n> is\n> working great, especially now that some tools allow easy ways to query,\n> retrieve, verify, and apply patches (shameless plug for lore, lei, and \n> b4\n> here).\n> \n> The obvious problem, of course, is that these folks are FOSS's \n> \"marathon\n> runners\" who got really good at their workflow, but the situation is \n> different\n> for anyone else who is just starting out. Any new kernel maintainer \n> stepping\n> up obviously finds this overwhelming, because they aren't yet so good \n> at\n> filtering the huge volume of the mailing list traffic and to them it's \n> just a\n> torrent of mostly irrelevant patches.\n> \n>> Are you consideration for migrating?\n> \n> Yes, of course, this is constantly under consideration. There isn't \n> some sort\n> of anti-forge cabal that is preventing things from going forward, but \n> there\n> are some serious hurdles and considerations to consider:\n> \n> - How to avoid a vendor lock-in? Those of us who have been around for a \n> while\n> have seen forges bloom, and then shrink into irrelevance (e.g. \n> bitkeeper)\n> or slowly ensh*ttify to the point of unusability (sourceforge). \n> GitHub is a\n> proprietary service owned by a single company who are currently\n> FOSS-friendly, but have certainly been extremely FOSS-hostile in the \n> past.\n> GitLab is open-core, and the current record for open-core projects \n> isn't\n> very encouraging (Puppet open-cored themselves into irrelevance, \n> Terraform\n> has gone full-proprietary, among most recent examples). Full-FOSS\n> alternatives exist, but people aren't really that enthused about \n> using\n> less-popular solutions like Forgejo, because they hate unfamiliar UIs \n> almost\n> as much, or even more than they hate unfiltered mailing lists.\n> \n> - How to avoid centralization and single points of failure? If Linux or \n> Git\n> move to a self-hosted forge, how do we ensure that an adversary can't \n> stop\n> all development on a project by knocking it offline for weeks? This \n> has\n> literally just happened to Sourcehut and Codeberg -- and as far as \n> anyone\n> can tell, the attacker was just bored and knocked them out just \n> because they\n> could. Yes, you can knock out vger, but this will only impact the \n> mailing\n> list -- people can still send around patches and hold discussions by\n> temporarily moving to alternative hosts. With the distributed nature \n> of the\n> mailing list archives, this can even be largely transparent to anyone \n> using\n> lei-queries.\n> \n> - How to avoid alienating these hundreds of key maintainers who are now\n> extremely proficient at their query-based workflows? We're talking \n> about an\n> extremely finely-tuned engine that is performing remarkably well -- \n> we don't\n> want to disrupt development for months just to try things out with a \n> forge\n> and find that it isn't working out.\n> \n> Finally, there's also the consideration of current trends. One upside \n> of \"AI\"\n> (LLM, really) technologies is that they are extremely good at taking in \n> a huge\n> source of data and finding relevant information based on natural \n> language\n> queries. I can very easily see a mechanism spring up in the next year \n> or less\n> where you can issue a query like \"send me any threads about reftables \n> or\n> promissory remotes if they contain follow-ups from Junio\" and reasonaly \n> expect\n> this to work and work great -- all while keeping things decentralized \n> in\n> addition to distributed.\n> \n> Above all, this isn't a \"forges are terrible and shouldn't be used\" \n> response\n> -- they are clearly useful, especially when it comes to CI \n> integrations. A\n> large part of my work is bridging forges with mailing lists and \n> vice-versa,\n> which I hope I'll be able to do in the near future (GitGitGadget \n> already does\n> it with GitHub, but my goal is to have a pluggable multi-forge \n> solution). I\n> just wanted to highlight the aspects that aren't necessarily obvious or\n> visible from the outside.\n\nThank you very much for taking your time to write this down!\nMuch appreciated.\n"},{"id":"487754","messageId":"5d796ab27f4575ded4807e08618c9249@manjaro.org","threadId":"60829","inReplyTo":"7e395301c5ff46a69d8aca71eb0bb766@manjaro.org","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T17:00:54Z","receivedAt":"2024-02-01T17:00:56Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-01 17:54, Dragan Simic wrote:\n> Hello Konstantin,\n> \n> On 2024-02-01 16:39, Konstantin Ryabitsev wrote:\n>> On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:\n>>> is there any current discussion about moving Git development away \n>>> from using\n>>> a mailing list to some modern form of collaboration?\n>>> \n>>> I'd like to be able to follow a structured discussion in issues and \n>>> to\n>>> contribute to the Git documentation, but the mailing list currently \n>>> just\n>>> bloats my personal inbox with loads of uninteresting e-mails in an\n>>> unstructured waterfall of messy discussion that I am not able to \n>>> follow\n>>> professionally.\n>> \n>> Here's a perspective from the world of Linux kernel, where this \n>> discussion is\n>> continuously raging. Funny enough, the main objection a lot of kernel\n>> maintainers have to forges is that it makes it really hard to find \n>> relevant\n>> discussions once the volume goes above a certain threshold. These \n>> folks have\n>> become *extremely* efficient at querying and filtering the mailing \n>> list\n>> traffic, to the point where all they ever see are just those \n>> discussions\n>> relevant to their work. They love the fact that it all arrives into \n>> the same\n>> place (their inbox) without having to go and click on various \n>> websites, each\n>> with their own login information, UI, and preferred workflow.\n>> \n>> The kernel maintainers are able to review tens of thousands of patches \n>> monthly\n>> with only about a hundred or so top maintainers. To them, this system \n>> is\n>> working great, especially now that some tools allow easy ways to \n>> query,\n>> retrieve, verify, and apply patches (shameless plug for lore, lei, and \n>> b4\n>> here).\n>> \n>> The obvious problem, of course, is that these folks are FOSS's \n>> \"marathon\n>> runners\" who got really good at their workflow, but the situation is \n>> different\n>> for anyone else who is just starting out. Any new kernel maintainer \n>> stepping\n>> up obviously finds this overwhelming, because they aren't yet so good \n>> at\n>> filtering the huge volume of the mailing list traffic and to them it's \n>> just a\n>> torrent of mostly irrelevant patches.\n>> \n>>> Are you consideration for migrating?\n>> \n>> Yes, of course, this is constantly under consideration. There isn't \n>> some sort\n>> of anti-forge cabal that is preventing things from going forward, but \n>> there\n>> are some serious hurdles and considerations to consider:\n>> \n>> - How to avoid a vendor lock-in? Those of us who have been around for \n>> a while\n>> have seen forges bloom, and then shrink into irrelevance (e.g. \n>> bitkeeper)\n>> or slowly ensh*ttify to the point of unusability (sourceforge). \n>> GitHub is a\n>> proprietary service owned by a single company who are currently\n>> FOSS-friendly, but have certainly been extremely FOSS-hostile in the \n>> past.\n>> GitLab is open-core, and the current record for open-core projects \n>> isn't\n>> very encouraging (Puppet open-cored themselves into irrelevance, \n>> Terraform\n>> has gone full-proprietary, among most recent examples). Full-FOSS\n>> alternatives exist, but people aren't really that enthused about \n>> using\n>> less-popular solutions like Forgejo, because they hate unfamiliar \n>> UIs almost\n>> as much, or even more than they hate unfiltered mailing lists.\n>> \n>> - How to avoid centralization and single points of failure? If Linux \n>> or Git\n>> move to a self-hosted forge, how do we ensure that an adversary \n>> can't stop\n>> all development on a project by knocking it offline for weeks? This \n>> has\n>> literally just happened to Sourcehut and Codeberg -- and as far as \n>> anyone\n>> can tell, the attacker was just bored and knocked them out just \n>> because they\n>> could. Yes, you can knock out vger, but this will only impact the \n>> mailing\n>> list -- people can still send around patches and hold discussions by\n>> temporarily moving to alternative hosts. With the distributed nature \n>> of the\n>> mailing list archives, this can even be largely transparent to \n>> anyone using\n>> lei-queries.\n>> \n>> - How to avoid alienating these hundreds of key maintainers who are \n>> now\n>> extremely proficient at their query-based workflows? We're talking \n>> about an\n>> extremely finely-tuned engine that is performing remarkably well -- \n>> we don't\n>> want to disrupt development for months just to try things out with a \n>> forge\n>> and find that it isn't working out.\n>> \n>> Finally, there's also the consideration of current trends. One upside \n>> of \"AI\"\n>> (LLM, really) technologies is that they are extremely good at taking \n>> in a huge\n>> source of data and finding relevant information based on natural \n>> language\n>> queries. I can very easily see a mechanism spring up in the next year \n>> or less\n>> where you can issue a query like \"send me any threads about reftables \n>> or\n>> promissory remotes if they contain follow-ups from Junio\" and \n>> reasonaly expect\n>> this to work and work great -- all while keeping things decentralized \n>> in\n>> addition to distributed.\n>> \n>> Above all, this isn't a \"forges are terrible and shouldn't be used\" \n>> response\n>> -- they are clearly useful, especially when it comes to CI \n>> integrations. A\n>> large part of my work is bridging forges with mailing lists and \n>> vice-versa,\n>> which I hope I'll be able to do in the near future (GitGitGadget \n>> already does\n>> it with GitHub, but my goal is to have a pluggable multi-forge \n>> solution). I\n>> just wanted to highlight the aspects that aren't necessarily obvious \n>> or\n>> visible from the outside.\n> \n> Thank you very much for taking your time to write this down!\n> Much appreciated.\n\ns/your time/the time/\n\nSorry for the noise.\n"},{"id":"487755","messageId":"DB9P195MB21301E5E271567256303443CE2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"20240201-primitive-aardwark-of-contentment-aaabb9@lemur","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-01T17:28:30Z","receivedAt":"2024-02-01T17:28:33Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"Thank you for enlightening me and elaborating on all of these very important facts!\n\nJust to make sure: So \"git\" is considered part of the kernel? And the \"git documentation\" is considered part of the kernel, too?\n\nShouldn't these topics be separated then into separate repositories, particularly the git documentation?\n\nFor people like me, who are contributing to dozens of documentations on GitHub (and GitLab) … We don't focus on the kernel alone. We receive dozens of important technical, business and financially important e-mails from different sources day by day. So, people like me need some modern, common channels/tools for contributing. (If contribution is considered helpful and valuable by the kernel team at all.)\n\nWith todays platforms, issues can be created by e-mail and e-mails will be received with each issue update. It's even possible to upload patches via REST services. No web browser required. So this would keep mailing list users acquainted to their habit.\n\nSetting up a local (on-premise) GitLab or Azure DevOps server for long-term use should not be impossible. I'm running each of these myself. Once installed on-premise, the installation wouldn't be bound to any continuous support. All it needs is a provider for keeping the server machine running.\n\nCheers,\nAxelD"},{"id":"487757","messageId":"DB9P195MB21306E8C1DB2FCBDDF5A5614E2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"ada5564d-d810-4707-83b8-c00a7b5aa79f@app.fastmail.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-01T17:39:20Z","receivedAt":"2024-02-01T17:39:23Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"Hi Kristoffer,\n\nthanks for sharing these very helpful links to GitGitGadget! Love it!\n\nBest regards,\nAxelD\n\n--\nFrom: Kristoffer Haugsbakk \nSent: Thursday, February 1, 2024 13:21\nTo: Hans Meiser \nCc: git@vger.kernel.org \nSubject: Re: Migrate away from vger to GitHub or (on-premise) GitLab?\n \nHi\n\nOn Thu, Feb 1, 2024, at 13:10, Hans Meiser wrote:\n> Hi,\n>\n> Regards,\n> Axel Dahmen\n\nA relevant discussion seems to be “Improving new contrib onboarding”[1]\n\nThere’s GitGitGadget for people who want to use GitHub as a bridge[2]\n\nThere’s an unofficial issue tracker for project ideas (not for bugs)[3]\n\nThat’s what I know.\n\n🔗 1: https://lore.kernel.org/git/ZRrgMDacYpj41DcO@nand.local/\n🔗 2: https://gitgitgadget.github.io/\n🔗 3: https://github.com/gitgitgadget/git/issues\n\n--\nKristoffer Haugsbakk"},{"id":"487758","messageId":"6174fbd7-5eee-450b-a38b-1d1b695f6d14@app.fastmail.com","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-02-01T17:39:30Z","receivedAt":"2024-02-01T17:40:39Z","isPatch":false,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"(Disclaimer that I’m relatively inexperienced with this project\nworkflow)\n\nMy impression is that the email workflow is very flexible and\ntool-agnostic.[1] On the other hand it’s hard to get set up in a way\nthat makes contributing to a project as easy as contributing to a\nproject that is hosted on GitHub.[2]\n\n† 1: Konstantin’s reply here seems to confirm this. And thanks by the\n way for all your emails on this workflow subject, which I always\n enjoy reading. And for your work on tooling that of course other\n email-based projects than Linux can use.\n† 2: With the assumption that you already have an account there\n\nWhat would really “sell” the email workflow would be to have some sort\nof program which can set everything up for you so that you can track\nyour contributions as easily as a PR on GitHub. Of course people use all\nkinds of different platforms, but let’s say that it only was for the\nlatest Mac OS (this is all hypothetical anyway). All you would need to\ndo was to give your email credentials and whatever other technical email\nthings that are required. Just install one program and track all your\npatches as well as the replies on them. More concretely: maybe it would\nhave an email client which would make sure that all your outgoing emails\nare done correctly. Including things like not mangling patches in your\nreply because of hard-wrapping or something. (I created a support ticket\nfor that on Fastmail yesterday.) Or: let you immediately inline a\n“scissor lines” patch into your current message based on a commit or\njust your current working tree.[3]\n\nAlso: never having to copy–paste message ids manually. :)\n\n(Again, all hypothetical for the sake of the argument)\n\nThis program could be very opinionated and dictate a very rigid\nworkflow; the point would be that there *is* a way to have a setup which\nis as easy as GitHub (modulo email credentials/technical\nthings). Because then if you want to customize your workflow you are\nstill totally free to put together your own tools just like what\napparently many people do right now.\n\nIf this was even just hypothetically possible—I dunno—then that would be\na strong argument in favor of this kind of project workflow.\n\nI think that would be the best of both worlds.\n\n† 3: That also sounds more convenient than pushing to a GitHub repo. in\n order to make a PR\n\n-- \nKristoffer Haugsbakk\n"},{"id":"487759","messageId":"ZbvY/01kebuFagn2@ubby","threadId":"60829","inReplyTo":"20240201-primitive-aardwark-of-contentment-aaabb9@lemur","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2024-02-01T17:46:39Z","receivedAt":"2024-02-01T17:46:48Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Thu, Feb 01, 2024 at 10:39:04AM -0500, Konstantin Ryabitsev wrote:\n> [excellent discussion of e-mail workflows elided]\n\nIt would surely help if the e-mail interfaces of forges were not\nterrible. But they really have to be as good as the mailing list\napproach.\n\nI envision that the \"issues\" and \"PRs\" could be webmail-ish thread\ntrackers that auto-close on prolonged silence. One could open issues/\nPRs by e-mail, close them by e-mail, etc., all e-mails going to the same\n[forge-run?] list address, but still have a forge-style view of a PR's\ncommits, still have a forge-style code review web UI (with all comments\ngoing to e-mail too, and with e-mail being first-class, not an\nafterthought), still have a CI checks UI, and still have a big\nrebase-and-merge button for maintainers.\n\nI.e., forge e-mail UI as first-class equivalent of forge web UI.\n\nThe forges tend to be run by people who prioritize users who are not\nheavy e-mail workflow devs. It makes economic sense, given how few\nusers demand e-mail as a first-class forge UI. Still, it would be quite\nawesome if some forge did this.\n\n> - How to avoid a vendor lock-in? [...]\n\nAssuming some forge exists with an e-mail UI on the same footing as its\nweb UI, and also good enough for kernel/git/... devs, you could maintain\nmirrors on all the other forges, naturally, and always fallback on\ne-mail only if the primary forge disappears or becomes too expensive.\n\n> - How to avoid centralization and single points of failure? [...]\n\nIt's all forks, all the time. It'd be good if the kernel maintainers\nmaintained non-forge git servers as mirror/staging/primary repos.\n\n> - How to avoid alienating these hundreds of key maintainers who are now\n> extremely proficient at their query-based workflows? [...]\n\nThe only answer is to stick to the current workflow until some forge\nprovide an equivalently first-class e-mail interface. New participants\njust have to get used to it. IMO.\n\nNico\n-- \n"},{"id":"487761","messageId":"c3b6de0c2ccf71f0dfa5aff06fa63d8f@manjaro.org","threadId":"60829","inReplyTo":"DB9P195MB21301E5E271567256303443CE2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T17:49:58Z","receivedAt":"2024-02-01T17:50:02Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-01 18:28, Hans Meiser wrote:\n> Thank you for enlightening me and elaborating on all of these very\n> important facts!\n> \n> Just to make sure: So \"git\" is considered part of the kernel? And the\n> \"git documentation\" is considered part of the kernel, too?\n\nOf course it isn't.\n\n> Shouldn't these topics be separated then into separate repositories,\n> particularly the git documentation?\n> \n> For people like me, who are contributing to dozens of documentations\n> on GitHub (and GitLab) … We don't focus on the kernel alone. We\n> receive dozens of important technical, business and financially\n> important e-mails from different sources day by day. So, people like\n> me need some modern, common channels/tools for contributing. (If\n> contribution is considered helpful and valuable by the kernel team at\n> all.)\n\nCould you, please, clarify what kind of git documentation are you\nreferring to? Are you having git man pages in mind?\n\n> With todays platforms, issues can be created by e-mail and e-mails\n> will be received with each issue update. It's even possible to upload\n> patches via REST services. No web browser required. So this would keep\n> mailing list users acquainted to their habit.\n> \n> Setting up a local (on-premise) GitLab or Azure DevOps server for\n> long-term use should not be impossible. I'm running each of these\n> myself. Once installed on-premise, the installation wouldn't be bound\n> to any continuous support. All it needs is a provider for keeping the\n> server machine running.\n\nQuite frankly, I think you've missed some important points from the\nKonstantin's message. To sum it up a bit, not having continuous support\nis simply unacceptable for any kind of a long-term project.\n"},{"id":"487765","messageId":"DB9P195MB21303B5546A764A18FE78C97E2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"c3b6de0c2ccf71f0dfa5aff06fa63d8f@manjaro.org","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-01T18:36:48Z","receivedAt":"2024-02-01T18:36:53Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> Could you, please, clarify what kind of git documentation are you\n> referring to?  Are you having git man pages in mind?\n\nYes, these in particular.\n\nFrom my point of view, many of these are quite unorganized, hard to read and – as I believe – need a fix-up. Markdown could replace the currently used language, so editing them would be more easy, proving support for preview and lint the documentation.\n\n>Quite frankly, I think you've missed some important points from the\n> Konstantin's message.  To sum it up a bit, not having continuous support\n> is simply unacceptable for any kind of a long-term project.\n\nAs I wrote, once installed on-premise, no-one will shut down an on-premise git server except for yourself. It can run for eternity. You just need someone to administer it properly and publish the website.\n\nIn the end, it's all just about git. You may create your own git webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb), or just use an existing one, like the GitLab server: https://about.gitlab.com/install/\n\nIn these servers, everything is configurable. Moreover, many plug-ins exist for plumbing extensions to these providers. It's possible to establish your own workflow, rights management and automatic handling. You just need someone who is an expert with the tool of your choice.\n\nMany other great repositories already are using one of those providers; Meta, Google, Microsoft for example share their code there – just to name a few. I wouldn't consider these users as being known for being exceptional risk-takers."},{"id":"487768","messageId":"691395bc13ea6c3013adcb98cfcbd102@manjaro.org","threadId":"60829","inReplyTo":"DB9P195MB21303B5546A764A18FE78C97E2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T19:00:02Z","receivedAt":"2024-02-01T19:00:05Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-01 19:36, Hans Meiser wrote:\n>> Could you, please, clarify what kind of git documentation are you\n>> referring to?  Are you having git man pages in mind?\n> \n> Yes, these in particular.\n> \n> From my point of view, many of these are quite unorganized, hard to\n> read and – as I believe – need a fix-up. Markdown could replace the\n> currently used language, so editing them would be more easy, proving\n> support for preview and lint the documentation.\n\nPlease keep in mind that editing the git man pages requires very\nintimate knowledge of the related git source code. Many times even\nsmall changes to the language style can change the meaning and diverge\nthe man pages from the source code, making the man pages useless.\n\n>> Quite frankly, I think you've missed some important points from the\n>> Konstantin's message.  To sum it up a bit, not having continuous \n>> support\n>> is simply unacceptable for any kind of a long-term project.\n> \n> As I wrote, once installed on-premise, no-one will shut down an\n> on-premise git server except for yourself. It can run for eternity.\n> You just need someone to administer it properly and publish the\n> website.\n\nA git server? I was under impression that you proposed running an\nown instance of GitLab or something similar.\n\n> In the end, it's all just about git. You may create your own git\n> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n> or just use an existing one, like the GitLab server:\n> https://about.gitlab.com/install/\n> \n> In these servers, everything is configurable. Moreover, many plug-ins\n> exist for plumbing extensions to these providers. It's possible to\n> establish your own workflow, rights management and automatic handling.\n> You just need someone who is an expert with the tool of your choice.\n> \n> Many other great repositories already are using one of those\n> providers; Meta, Google, Microsoft for example share their code there\n> – just to name a few. I wouldn't consider these users as being known\n> for being exceptional risk-takers.\n"},{"id":"487773","messageId":"7a9048296c585d499d3b2547b05d1341@manjaro.org","threadId":"60829","inReplyTo":"060d01da5549$6e93e250$4bbba6f0$@nexbridge.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-01T20:09:30Z","receivedAt":"2024-02-01T20:09:32Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-01 21:01, rsbecker@nexbridge.com wrote:\n> On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:\n>> On 2024-02-01 19:36, Hans Meiser wrote:\n>>>> Quite frankly, I think you've missed some important points from the\n>>>> Konstantin's message. To sum it up a bit, not having continuous\n>>>> support is simply unacceptable for any kind of a long-term project.\n>>> \n>>> As I wrote, once installed on-premise, no-one will shut down an\n>>> on-premise git server except for yourself. It can run for eternity.\n>>> You just need someone to administer it properly and publish the\n>>> website.\n>> \n>> A git server? I was under impression that you proposed running an own \n>> instance of\n>> GitLab or something similar.\n> \n> Git is unique, as a project, given that everything (! Not everything\n> but a whole lot) is managed using git, including the enterprise git\n> server platforms.\n> \n> A huge advantage of using a git server is being able to mirror the\n> repository. If we went with a GitLab host, we could potentially mirror\n> over to GitHub. The drawback is that the pull request history (and\n> related discussions) id not (currently) preserved. I think this is a\n> situation no matter what, even if we go GitLab/GitLab or\n> GitHub/GitHub. The value of the discussion threads is the most\n> important part of what needs to be preserved. I have high confidence\n> that the team could move to either Pull Request/Merge Request\n> structure reasonably easily, but if we had to move again in future\n> (count on it), there must be a way to preserve the community assets of\n> the discussions that went into making decisions. Without that, I am\n> concerned that a migration to a GitLab (or any other) instance would\n> increase velocity but put long term decisions at risk.\n\nGood point, I agree that the value of the discussions on the mailing\nlist is extremely high. We should also keep in mind that the risk of\na vendor lock-in is even higher when it comes to the discussions.\n\nFrankly, the resilience of email as a service and the openness of its\nformat can hardly be beaten.\n\n>>> In the end, it's all just about git. You may create your own git\n>>> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n>>> or just use an existing one, like the GitLab server:\n>>> https://about.gitlab.com/install/\n>>> \n>>> In these servers, everything is configurable. Moreover, many plug-ins\n>>> exist for plumbing extensions to these providers. It's possible to\n>>> establish your own workflow, rights management and automatic \n>>> handling.\n>>> You just need someone who is an expert with the tool of your choice.\n>>> \n>>> Many other great repositories already are using one of those\n>>> providers; Meta, Google, Microsoft for example share their code there\n>>> – just to name a few. I wouldn't consider these users as being known\n>>> for being exceptional risk-takers.\n"},{"id":"487774","messageId":"060d01da5549$6e93e250$4bbba6f0$@nexbridge.com","threadId":"60829","inReplyTo":"691395bc13ea6c3013adcb98cfcbd102@manjaro.org","subject":"RE: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-02-01T20:01:17Z","receivedAt":"2024-02-01T20:09:37Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:\n>On 2024-02-01 19:36, Hans Meiser wrote:\n>>> Could you, please, clarify what kind of git documentation are you\n>>> referring to? Are you having git man pages in mind?\n>>\n>> Yes, these in particular.\n>>\n>> From my point of view, many of these are quite unorganized, hard to\n>> read and – as I believe – need a fix-up. Markdown could replace the\n>> currently used language, so editing them would be more easy, proving\n>> support for preview and lint the documentation.\n>\n>Please keep in mind that editing the git man pages requires very intimate knowledge\n>of the related git source code. Many times even small changes to the language style\n>can change the meaning and diverge the man pages from the source code, making\n>the man pages useless.\n>\n>>> Quite frankly, I think you've missed some important points from the\n>>> Konstantin's message. To sum it up a bit, not having continuous\n>>> support is simply unacceptable for any kind of a long-term project.\n>>\n>> As I wrote, once installed on-premise, no-one will shut down an\n>> on-premise git server except for yourself. It can run for eternity.\n>> You just need someone to administer it properly and publish the\n>> website.\n>\n>A git server? I was under impression that you proposed running an own instance of\n>GitLab or something similar.\n\nGit is unique, as a project, given that everything (! Not everything but a whole lot) is managed using git, including the enterprise git server platforms.\n\nA huge advantage of using a git server is being able to mirror the repository. If we went with a GitLab host, we could potentially mirror over to GitHub. The drawback is that the pull request history (and related discussions) id not (currently) preserved. I think this is a situation no matter what, even if we go GitLab/GitLab or GitHub/GitHub. The value of the discussion threads is the most important part of what needs to be preserved. I have high confidence that the team could move to either Pull Request/Merge Request structure reasonably easily, but if we had to move again in future (count on it), there must be a way to preserve the community assets of the discussions that went into making decisions. Without that, I am concerned that a migration to a GitLab (or any other) instance would increase velocity but put long term decisions at risk.\n\n>> In the end, it's all just about git. You may create your own git\n>> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n>> or just use an existing one, like the GitLab server:\n>> https://about.gitlab.com/install/\n>>\n>> In these servers, everything is configurable. Moreover, many plug-ins\n>> exist for plumbing extensions to these providers. It's possible to\n>> establish your own workflow, rights management and automatic handling.\n>> You just need someone who is an expert with the tool of your choice.\n>>\n>> Many other great repositories already are using one of those\n>> providers; Meta, Google, Microsoft for example share their code there\n>> – just to name a few. I wouldn't consider these users as being known\n>> for being exceptional risk-takers.\n\n--Randall\n\n"},{"id":"487786","messageId":"ZbxI4wNTBZ48YcTi@tapette.crustytoothpaste.net","threadId":"60829","inReplyTo":"DB9P195MB21303B5546A764A18FE78C97E2432@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-02-02T01:44:03Z","receivedAt":"2024-02-02T01:53:29Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-02-01 at 18:36:48, Hans Meiser wrote:\n> > Could you, please, clarify what kind of git documentation are you\n> > referring to?  Are you having git man pages in mind?\n> \n> Yes, these in particular.\n> \n> From my point of view, many of these are quite unorganized, hard to\n> read and – as I believe – need a fix-up. Markdown could replace the\n> currently used language, so editing them would be more easy, proving\n> support for preview and lint the documentation.\n\nWe've discussed moving to Markdown. Unfortunately, while Markdown is\ngreat for HTML, it's pretty terrible for things that are not HTML.\nCertainly there are tools that convert Markdown to other formats, but\nI'm not aware of any single tool (outside of Pandoc[0]) that does so into\nall the formats we offer, including HTML, PDF, Texinfo, and manual\npages. Markdown also comes in a large variety of variants and writing\ndocumentation to please any substantial number of tools is very\ndifficult.\n\nAsciiDoc supports converting into all of those things either directly or\nthrough DocBook, and it's flexible enough to allow a decent amount of\ncustomization, which we take advantage of. It also has relatively\nlittle variation. Both of these are part of the reason that Git LFS\nmoved from Markdown to AsciiDoc.\n\n> >Quite frankly, I think you've missed some important points from the\n> > Konstantin's message.  To sum it up a bit, not having continuous support\n> > is simply unacceptable for any kind of a long-term project.\n> \n> As I wrote, once installed on-premise, no-one will shut down an\n> on-premise git server except for yourself. It can run for eternity.\n> You just need someone to administer it properly and publish the\n> website.\n\nYes, and that would be someone at kernel.org, which is a nonprofit.\nMaintaining a busy Git server takes server resources and sufficient\nstaffing to ensure that things work properly and that problems are\nresolved in a timely manner. It also comes with potential security\nrisks. The mail-based approach will likely remain for the Linux kernel,\nso someone will have to maintain this in addition. Are you offering to\nprovide long-term funding to kernel.org to provide the necessary\nresources and staffing?\n\n> In the end, it's all just about git. You may create your own git\n> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n> or just use an existing one, like the GitLab server:\n> https://about.gitlab.com/install/\n\nThe Git project has tried for a long time to be neutral on any\nparticular external piece of software. Installing a GitLab server as\nour preferred development platform would promote GitLab as the preferred\nforge to other users. Similarly, moving to GitHub would prefer GitHub\nover other forges. That's not a thing we want to do.\n\nWe also don't accept patches or features for the benefit of one\nparticular forge or external project. Patches and features must be\nof general benefit to the project at large.\n\n[0] Pandoc is built in Haskell using GHC, which has decent architecture\nsupport, but quite poor OS support outside of the most common platforms.\nRelying on it would be a serious regression in terms of documentation\nsupport.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"487788","messageId":"Zbx5Xzb3kyHvkp7C@tanuki","threadId":"60829","inReplyTo":"ZbxI4wNTBZ48YcTi@tapette.crustytoothpaste.net","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-02-02T05:10:55Z","receivedAt":"2024-02-02T05:11:03Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:\n> On 2024-02-01 at 18:36:48, Hans Meiser wrote:\n[snip]\n> > In the end, it's all just about git. You may create your own git\n> > webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n> > or just use an existing one, like the GitLab server:\n> > https://about.gitlab.com/install/\n> \n> The Git project has tried for a long time to be neutral on any\n> particular external piece of software. Installing a GitLab server as\n> our preferred development platform would promote GitLab as the preferred\n> forge to other users. Similarly, moving to GitHub would prefer GitHub\n> over other forges. That's not a thing we want to do.\n> \n> We also don't accept patches or features for the benefit of one\n> particular forge or external project. Patches and features must be\n> of general benefit to the project at large.\n\nI think this point is indeed really important in the context of the Git\nproject. It's a rather unique limitation that no other project out there\nwill really have. I don't think this has to completely rule out the use\nof a forge. But in my opinion it completely rules out any forge that is\nrun by a for-profit company and that isn't completely open source. So\nGitLab, GitHub and Bitbucket are not really an option in my opinion.\n\nThat still leaves other forges like SourceHut, Gogs or Forgejo. But the\nbenefit becomes at least a bit more questionable as the barrier for\nentry is again higher in that context -- after all most people only know\nabout the large forges out there, and creating a new account raises the\nbar.\n\nPatrick\n"},{"id":"487799","messageId":"DB9P195MB2130EB8EB69A8140A31BB432E2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"691395bc13ea6c3013adcb98cfcbd102@manjaro.org","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-02T10:18:45Z","receivedAt":"2024-02-02T10:18:47Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> Please keep in mind that editing the git man pages requires very\n> intimate knowledge of the related git source code.  Many times even\n> small changes to the language style can change the meaning and diverge\n> the man pages from the source code, making the man pages useless.\n\nSure. Eventually, I'd rather propose to have parts of the man pages be generated from code comments (XmlDoc, JsDoc or similar), particularly syntax and parameter list. That would keep documentation from deviating from code right from the beginning. And it would keep documentation writers from manually updating obvious parts.\n\n> A git server?  I was under impression that you proposed running an\n> own instance of GitLab or something similar.\n\nBasically, GitLab, GitHub, Azure DevOps are all just Git servers, plus collaboration and automation functionality. I suggested using GitWeb only in case you wanted to write (and keep control over) collaboration and automation functionality yourself. Otherwise you may use one of the existing ones that have already been written (i.e., GitLab, GitHub, Azure DevOps)."},{"id":"487800","messageId":"DB9P195MB2130D9CFF998FBCB6100FB6CE2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"060d01da5549$6e93e250$4bbba6f0$@nexbridge.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-02T10:21:55Z","receivedAt":"2024-02-02T10:21:57Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> A huge advantage of using a git server is being able to mirror the repository. If we\n> went with a GitLab host, we could potentially mirror over to GitHub. The drawback is\n> that the pull request history (and related discussions) id not (currently) preserved.\n\nI'm pretty sure that if you want to move over to any of the platforms, admins there will happily assist you in pre-filling issues and PRs there from your mailing list.\n\nI just saw in the mailing list that a PR needs to be splitted over multiple e-mails. Do you really want to cling to this old fashioned (I'd rather call it obsolete) process?"},{"id":"487801","messageId":"DB9P195MB21302F96E3E2CD404FDBF9ACE2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"ZbxI4wNTBZ48YcTi@tapette.crustytoothpaste.net","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-02T10:43:44Z","receivedAt":"2024-02-02T10:43:49Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> We've discussed moving to Markdown.  Unfortunately, while Markdown is\n> great for HTML, it's pretty terrible for things that are not HTML.\n> Certainly there are tools that convert Markdown to other formats, but\n> I'm not aware of any single tool (outside of Pandoc[0]) that does so into\n> all the formats we offer, including HTML, PDF, Texinfo, and manual\n> pages.  Markdown also comes in a large variety of variants and writing\n> documentation to please any substantial number of tools is very\n> difficult.\n\nActually, there a plenty of converters out there converting Markdown to anything. You many find many websites that are using these converters for providing conversion online. In case there'd be a particular target language that actually may be missing, you may want to employ a 2-step process: e.g., just convert Markdown to HTML and from there to anything else. Once established, documentation would get updated automatically with every build and always correspond to the latest version.\n\nI've been working with many documentation teams (e.g., Microsoft, Alphabet) who are using their own Markdown compilers for adding hyperlinks, warnings etc. in their automation script converting Markdown to HTML. In all the cases I've seen it's a simple pre-compiler, replacing particular tokens with actual Markdown content before conversion.\n\nMoreover, Markdown commonly accepts a restricted set of HTML tags, so you may even extend Markdown inline for anything fancy."},{"id":"487802","messageId":"DB9P195MB21306A747B3BEBB53FCBCE5FE2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"DB9P195MB21302F96E3E2CD404FDBF9ACE2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-02T10:48:01Z","receivedAt":"2024-02-02T10:48:03Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> Actually, there a plenty of converters out there converting Markdown to anything.\n\nYou may even want to convert Markdown to AsciiDoc:\nhttps://matthewsetter.com/technical-documentation/asciidoc/convert-markdown-to-asciidoc-with-kramdoc/\n"},{"id":"487804","messageId":"c9a0cb1fe64f8e7d21c21458e5e76af9@manjaro.org","threadId":"60829","inReplyTo":"DB9P195MB2130EB8EB69A8140A31BB432E2422@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-02T10:54:51Z","receivedAt":"2024-02-02T10:54:54Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-02 11:18, Hans Meiser wrote:\n>> Please keep in mind that editing the git man pages requires very\n>> intimate knowledge of the related git source code.  Many times even\n>> small changes to the language style can change the meaning and diverge\n>> the man pages from the source code, making the man pages useless.\n> \n> Sure. Eventually, I'd rather propose to have parts of the man pages be\n> generated from code comments (XmlDoc, JsDoc or similar), particularly\n> syntax and parameter list. That would keep documentation from\n> deviating from code right from the beginning. And it would keep\n> documentation writers from manually updating obvious parts.\n\nThat might work out in some places, but I'm not really sure about the\noverall effectiveness. The git man pages don't document function calls.\n\n>> A git server?  I was under impression that you proposed running an\n>> own instance of GitLab or something similar.\n> \n> Basically, GitLab, GitHub, Azure DevOps are all just Git servers, plus\n> collaboration and automation functionality. I suggested using GitWeb\n> only in case you wanted to write (and keep control over)\n> collaboration and automation functionality yourself. Otherwise you may\n> use one of the existing ones that have already been written (i.e.,\n> GitLab, GitHub, Azure DevOps).\n\nThe plus brings additional issues. It's been already noted that \nfavoring\nany of those solutions actually wouldn't be in the interest of git \nitself\nas a project, because it wants to remain neutral.\n\nIMHO, these days too much is expected to be handled by \"something else\",\ninstead of the developers handling that. It's like offloading the \nbasically\nunavoidable complexity to some utility, and expecting that the \ncomplexity\nwill somehow go away.\n\nIn other words, a developer has to keep quite a lot in their short-term\nmemory, and a lot in their long-term memory, to be able to accomplish \nsome\ntask, and hardly any utility is going to make that significantly easier.\nThe same principle, in general, applies to a group of developers working\non the same task.\n"},{"id":"487805","messageId":"6b34d999-3da2-42ef-bfff-37c8f592347f@gmail.com","threadId":"60829","inReplyTo":"691395bc13ea6c3013adcb98cfcbd102@manjaro.org","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-02-02T11:07:18Z","receivedAt":"2024-02-02T11:07:21Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 01/02/2024 19:00, Dragan Simic wrote:\n> On 2024-02-01 19:36, Hans Meiser wrote:\n> Please keep in mind that editing the git man pages requires very\n> intimate knowledge of the related git source code.  Many times even\n> small changes to the language style can change the meaning and diverge\n> the man pages from the source code, making the man pages useless.\n\nWhile there are some aspects of the documentation that require a \nfamiliarity with the source I don't think that is true in general. If \nsomeone has a suggestion to improve part of the documentation that they \nfound hard to understand we should be encouraging them to contribute a \npatch. There is no doubt that there are places where our documentation \ncould be improved and it is not necessary to be a C programmer to \ncontribute improvements to it.\n\nBest Wishes\n\nPhillip\n\n"},{"id":"487806","messageId":"8f5ca8f5dfd465fea0a53dabc81a58cd@manjaro.org","threadId":"60829","inReplyTo":"6b34d999-3da2-42ef-bfff-37c8f592347f@gmail.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-02T11:13:05Z","receivedAt":"2024-02-02T11:13:11Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-02 12:07, Phillip Wood wrote:\n> On 01/02/2024 19:00, Dragan Simic wrote:\n>> On 2024-02-01 19:36, Hans Meiser wrote:\n>> Please keep in mind that editing the git man pages requires very\n>> intimate knowledge of the related git source code.  Many times even\n>> small changes to the language style can change the meaning and diverge\n>> the man pages from the source code, making the man pages useless.\n> \n> While there are some aspects of the documentation that require a\n> familiarity with the source I don't think that is true in general. If\n> someone has a suggestion to improve part of the documentation that\n> they found hard to understand we should be encouraging them to\n> contribute a patch. There is no doubt that there are places where our\n> documentation could be improved and it is not necessary to be a C\n> programmer to contribute improvements to it.\n\nSure, but there has to be someone with intimate knowledge of the git\nsource code in the entire chain, if you agree, to make sure that \nimproving\nthe readability or style doesn't diverge the man pages from the truth.\n"},{"id":"487807","messageId":"0e3e6102-40eb-4462-b541-0c7452e79f42@gmail.com","threadId":"60829","inReplyTo":"Zbx5Xzb3kyHvkp7C@tanuki","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-02-02T11:15:26Z","receivedAt":"2024-02-02T11:15:28Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 02/02/2024 05:10, Patrick Steinhardt wrote:\n> On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:\n>> On 2024-02-01 at 18:36:48, Hans Meiser wrote:\n> [snip]\n>>> In the end, it's all just about git. You may create your own git\n>>> webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n>>> or just use an existing one, like the GitLab server:\n>>> https://about.gitlab.com/install/\n>>\n>> The Git project has tried for a long time to be neutral on any\n>> particular external piece of software. Installing a GitLab server as\n>> our preferred development platform would promote GitLab as the preferred\n>> forge to other users. Similarly, moving to GitHub would prefer GitHub\n>> over other forges. That's not a thing we want to do.\n>>\n>> We also don't accept patches or features for the benefit of one\n>> particular forge or external project. Patches and features must be\n>> of general benefit to the project at large.\n> \n> I think this point is indeed really important in the context of the Git\n> project.\n\nAgreed, thank you for making it brian. If we did decide to use a forge \nwe'd need to be very clear in our decision making that it was selected \nbased on the specific needs of this project and was not a general \nendorsement of one product over another. We'd also need to address the \nimportant practical problems of finding resources to maintain the \ninfrastructure and software to run it.\n\nBest Wishes\n\nPhillip\n\n"},{"id":"487808","messageId":"93be64af474b228e914a4c39443b5a9c@manjaro.org","threadId":"60829","inReplyTo":"c9a0cb1fe64f8e7d21c21458e5e76af9@manjaro.org","subject":"Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?)","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-02T11:23:41Z","receivedAt":"2024-02-02T11:23:44Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello everyone,\n\nI went ahead and contacted the mlmmj project, which runs the vger \nmailing\nlists, [1] with an idea to implement a new command/feature that allows\nthreads to be muted or unmuted. For example, that would allow receiving\nonly the replies to one's patch that was sent to a list.\n\nThe initial reactions are good, but various concerns have been raised\nregarding the actual implementation. I'll think about the way to \nimplement\nit in an efficient and simple way. I think this would make using \nmailing\nlists much more friendly to many users.\n\nAll suggestions and thoughts are welcome, of course.\n\n[1] https://people.kernel.org/monsieuricon/subspace-mailing-list-server\n\n\nOn 2024-02-02 11:54, Dragan Simic wrote:\n> On 2024-02-02 11:18, Hans Meiser wrote:\n>>> Please keep in mind that editing the git man pages requires very\n>>> intimate knowledge of the related git source code.  Many times even\n>>> small changes to the language style can change the meaning and \n>>> diverge\n>>> the man pages from the source code, making the man pages useless.\n>> \n>> Sure. Eventually, I'd rather propose to have parts of the man pages be\n>> generated from code comments (XmlDoc, JsDoc or similar), particularly\n>> syntax and parameter list. That would keep documentation from\n>> deviating from code right from the beginning. And it would keep\n>> documentation writers from manually updating obvious parts.\n> \n> That might work out in some places, but I'm not really sure about the\n> overall effectiveness. The git man pages don't document function \n> calls.\n> \n>>> A git server?  I was under impression that you proposed running an\n>>> own instance of GitLab or something similar.\n>> \n>> Basically, GitLab, GitHub, Azure DevOps are all just Git servers, plus\n>> collaboration and automation functionality. I suggested using GitWeb\n>> only in case you wanted to write (and keep control over)\n>> collaboration and automation functionality yourself. Otherwise you may\n>> use one of the existing ones that have already been written (i.e.,\n>> GitLab, GitHub, Azure DevOps).\n> \n> The plus brings additional issues. It's been already noted that \n> favoring\n> any of those solutions actually wouldn't be in the interest of git \n> itself\n> as a project, because it wants to remain neutral.\n> \n> IMHO, these days too much is expected to be handled by \"something \n> else\",\n> instead of the developers handling that. It's like offloading the \n> basically\n> unavoidable complexity to some utility, and expecting that the \n> complexity\n> will somehow go away.\n> \n> In other words, a developer has to keep quite a lot in their short-term\n> memory, and a lot in their long-term memory, to be able to accomplish \n> some\n> task, and hardly any utility is going to make that significantly \n> easier.\n> The same principle, in general, applies to a group of developers \n> working\n> on the same task.\n"},{"id":"487811","messageId":"20240202115004.GV9696@kitsune.suse.cz","threadId":"60829","inReplyTo":"0e3e6102-40eb-4462-b541-0c7452e79f42@gmail.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2024-02-02T11:50:04Z","receivedAt":"2024-02-02T11:50:07Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Fri, Feb 02, 2024 at 11:15:26AM +0000, Phillip Wood wrote:\n> On 02/02/2024 05:10, Patrick Steinhardt wrote:\n> > On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:\n> > > On 2024-02-01 at 18:36:48, Hans Meiser wrote:\n> > [snip]\n> > > > In the end, it's all just about git. You may create your own git\n> > > > webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),\n> > > > or just use an existing one, like the GitLab server:\n> > > > https://about.gitlab.com/install/\n> > > \n> > > The Git project has tried for a long time to be neutral on any\n> > > particular external piece of software. Installing a GitLab server as\n> > > our preferred development platform would promote GitLab as the preferred\n> > > forge to other users. Similarly, moving to GitHub would prefer GitHub\n> > > over other forges. That's not a thing we want to do.\n> > > \n> > > We also don't accept patches or features for the benefit of one\n> > > particular forge or external project. Patches and features must be\n> > > of general benefit to the project at large.\n> > \n> > I think this point is indeed really important in the context of the Git\n> > project.\n> \n> Agreed, thank you for making it brian. If we did decide to use a forge we'd\n> need to be very clear in our decision making that it was selected based on\n> the specific needs of this project and was not a general endorsement of one\n> product over another. We'd also need to address the important practical\n> problems of finding resources to maintain the infrastructure and software to\n> run it.\n\nIn this context using lore is basically also a forge choice. It is built\non top of git, and expands the functionality of what the project git\nrepository alone provides.\n\nUnlike most other forge software it is based completely on open\nstandards such as e-mail headers and git itself, very open and modular,\nand does not in any way tie the project git repository to this\nadditional functionality provided by lore.\n\nThis open and separate nature of lore is what makes it the tool of\nchoice for Linux and git, and any forge that aims to replace lore should\naim at similar level of openness. Of the forges I am aware of only\nsourcehut comes close in terms of planned functionality but it's nowhere\nnear completed as far as I am aware.\n\nGiven the open nature of lore it should be feasible to provide\nadditional interfaces on top of it that cater to people used to PRs\non popular forge web UIs without hijacking the whole project and the\nexisting tools and interfaces. For some reason people are set on\nreplacing it as a whole, and removing the interfaces they personally\ndon't use, calling them obosolete.\n\nIn a project with large numger of collaborators with varying backgrounds\nthat's not going to work well. There are many people working on git\nusing different workflows, and adding support for new workflow by\nremoving a number of existing ones will cause problems. The goal of\nchanging the forge software should be to be more open, supporting more\nusers with more varying workflows and needs, not less.\n\nThanks\n\nMichal\n"},{"id":"487812","messageId":"46725c2b5defc9f819513700b66ffa86@manjaro.org","threadId":"60829","inReplyTo":"20240202115004.GV9696@kitsune.suse.cz","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-02T12:36:36Z","receivedAt":"2024-02-02T12:36:49Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-02 12:50, Michal Suchánek wrote:\n> Given the open nature of lore it should be feasible to provide\n> additional interfaces on top of it that cater to people used to PRs\n> on popular forge web UIs without hijacking the whole project and the\n> existing tools and interfaces. For some reason people are set on\n> replacing it as a whole, and removing the interfaces they personally\n> don't use, calling them obosolete.\n> \n> In a project with large numger of collaborators with varying \n> backgrounds\n> that's not going to work well. There are many people working on git\n> using different workflows, and adding support for new workflow by\n> removing a number of existing ones will cause problems. The goal of\n> changing the forge software should be to be more open, supporting more\n> users with more varying workflows and needs, not less.\n\nTotally agreed. Augmenting the traditional interfaces and workflows,\ninstead of declaring them obsolete and killing them, should be the way\nto go. Having different options available is always good.\n"},{"id":"487816","messageId":"877cjm53bf.fsf@osv.gnss.ru","threadId":"60829","inReplyTo":"AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2024-02-02T14:49:24Z","receivedAt":"2024-02-02T14:49:28Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Hans Meiser writes:\n\n> Hi,\n>\n> is there any current discussion about moving Git development away from\n> using a mailing list to some modern form of collaboration?\n\nYes, now there is (again).\n\n> I'd like to be able to follow a structured discussion in issues and to\n> contribute to the Git documentation, but the mailing list currently\n> just bloats my personal inbox with loads of uninteresting e-mails in\n> an unstructured waterfall of messy discussion that I am not able to\n> follow professionally.\n\nDid you consider to rather read the list through\ngmane.comp.version-control.git nntp newsgroup?\n\nThis way you get only very specific mails in your mail-box, those where\nyou are explicitly CC'ed, and you usually get more support for\nstructuring from NNTP readers than from mail clients.\n\nHTH\n\n-- \nSergey Organov\n"},{"id":"487821","messageId":"008b01da55eb$9f3c36d0$ddb4a470$@nexbridge.com","threadId":"60829","inReplyTo":"877cjm53bf.fsf@osv.gnss.ru","subject":"RE: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-02-02T15:22:18Z","receivedAt":"2024-02-02T15:22:29Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, February 2, 2024 9:49 AM, Sergey Organov wrote:\n>Hans Meiser writes:\n>\n>> Hi,\n>>\n>> is there any current discussion about moving Git development away from\n>> using a mailing list to some modern form of collaboration?\n>\n>Yes, now there is (again).\n>\n>> I'd like to be able to follow a structured discussion in issues and to\n>> contribute to the Git documentation, but the mailing list currently\n>> just bloats my personal inbox with loads of uninteresting e-mails in\n>> an unstructured waterfall of messy discussion that I am not able to\n>> follow professionally.\n>\n>Did you consider to rather read the list through gmane.comp.version-control.git\n>nntp newsgroup?\n>\n>This way you get only very specific mails in your mail-box, those where you are\n>explicitly CC'ed, and you usually get more support for structuring from NNTP\n>readers than from mail clients.\n\nGoogle is dropping Usenet NNTP updates on 22 Feb 2024. I would love that idea, but it has a limited lifespan.\n\n"},{"id":"487823","messageId":"20240202161643.GD119530@mit.edu","threadId":"60829","inReplyTo":"008b01da55eb$9f3c36d0$ddb4a470$@nexbridge.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2024-02-02T16:16:43Z","receivedAt":"2024-02-02T16:16:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Feb 02, 2024 at 10:22:18AM -0500, rsbecker@nexbridge.com wrote:\n> >\n> >Did you consider to rather read the list through\n> >gmane.comp.version-control.git nntp newsgroup?\n> >\n> >This way you get only very specific mails in your mail-box, those\n> >where you are explicitly CC'ed, and you usually get more support\n> >for structuring from NNTP readers than from mail clients.\n> \n> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love\n> that idea, but it has a limited lifespan.\n\nGoogle might be dropping Usenix NNTP updates, but news.gmaine.io and\nnntp.lore.kernel.org are not not run by Google. So whether or not\nGoogle groups are supporting NNTP is not really supporting.\n\nOne other thing I would note that is that if someone isn't interested\nin following most of the git mailing list, it's unclear how much they\ncan actually contribute. Maybe they could fix spelling or grammer\nissues in the git man pages, but it's unlikely they could actually\nmake code contributions.\n\nSo from an open source project perspective, which is primarily run by\nvolunteers, each open source project has to make a cost-benefit\ntradeoff as far as the *project* is concerned. Individuals do not\nhave a fundamental human right to contribute to a project. Hence, the\nopen source project doesn't owe an obligation to spend a huge amount\nof effort supporting some kind of forge web site just because some\npotential contributors are clammoring for it. Especially if they are\nsaying that they can't be bothered to follow the mailing list traffic\nbecause it's somehow too much.\n\n(Of course, I have all of the Linux kernel mailing list flowing into\nmy inbox, and have e-mail practices that can handle that load --- so\nit's hard for me to have much sympathy about people complaining that\nthe e-mail load for git is too large --- compared to LKML, it's\n*nothing*. :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"487824","messageId":"xmqqcytevmwq.fsf@gitster.g","threadId":"60829","inReplyTo":"008b01da55eb$9f3c36d0$ddb4a470$@nexbridge.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-02T16:41:41Z","receivedAt":"2024-02-02T16:41:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n>>Did you consider to rather read the list through gmane.comp.version-control.git\n>>nntp newsgroup?\n>>\n>>This way you get only very specific mails in your mail-box, those where you are\n>>explicitly CC'ed, and you usually get more support for structuring from NNTP\n>>readers than from mail clients.\n>\n> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would\n> love that idea, but it has a limited lifespan.\n\nYou do not have to read NNTP newsgroup via Google Groups, which has,\nbut will be ending, support to gateway between them. The suggestion\nwas to read these articles over NNTP instead of subscribing to the\nlist, which does not involve anything Google would (or wouldn't) do.\n\n\n"},{"id":"487827","messageId":"009601da55fa$1ecc9580$5c65c080$@nexbridge.com","threadId":"60829","inReplyTo":"xmqqcytevmwq.fsf@gitster.g","subject":"RE: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-02-02T17:06:04Z","receivedAt":"2024-02-02T17:06:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, February 2, 2024 11:42 AM, Junio C Hamano wrote:\n> writes:\n>\n>>>Did you consider to rather read the list through\n>>>gmane.comp.version-control.git nntp newsgroup?\n>>>\n>>>This way you get only very specific mails in your mail-box, those\n>>>where you are explicitly CC'ed, and you usually get more support for\n>>>structuring from NNTP readers than from mail clients.\n>>\n>> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love\n>> that idea, but it has a limited lifespan.\n>\n>You do not have to read NNTP newsgroup via Google Groups, which has, but\nwill be\n>ending, support to gateway between them. The suggestion was to read these\n>articles over NNTP instead of subscribing to the list, which does not\ninvolve\n>anything Google would (or wouldn't) do.\n\nI should have qualified this with \"free\" NNTP. I have only been able to find\nfor fee NNTP servers where I am. The search continues.\n\n"},{"id":"487829","messageId":"20240202172327.GW9696@kitsune.suse.cz","threadId":"60829","inReplyTo":"20240202161643.GD119530@mit.edu","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2024-02-02T17:23:27Z","receivedAt":"2024-02-02T17:23:30Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Fri, Feb 02, 2024 at 11:16:43AM -0500, Theodore Ts'o wrote:\n> On Fri, Feb 02, 2024 at 10:22:18AM -0500, rsbecker@nexbridge.com wrote:\n> > >\n> > >Did you consider to rather read the list through\n> > >gmane.comp.version-control.git nntp newsgroup?\n> > >\n> > >This way you get only very specific mails in your mail-box, those\n> > >where you are explicitly CC'ed, and you usually get more support\n> > >for structuring from NNTP readers than from mail clients.\n> > \n> > Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love\n> > that idea, but it has a limited lifespan.\n> \n> Google might be dropping Usenix NNTP updates, but news.gmaine.io and\n> nntp.lore.kernel.org are not not run by Google. So whether or not\n> Google groups are supporting NNTP is not really supporting.\n> \n> One other thing I would note that is that if someone isn't interested\n> in following most of the git mailing list, it's unclear how much they\n> can actually contribute. Maybe they could fix spelling or grammer\n> issues in the git man pages, but it's unlikely they could actually\n> make code contributions.\n> \n> So from an open source project perspective, which is primarily run by\n> volunteers, each open source project has to make a cost-benefit\n> tradeoff as far as the *project* is concerned. Individuals do not\n> have a fundamental human right to contribute to a project. Hence, the\n> open source project doesn't owe an obligation to spend a huge amount\n> of effort supporting some kind of forge web site just because some\n> potential contributors are clammoring for it. Especially if they are\n> saying that they can't be bothered to follow the mailing list traffic\n> because it's somehow too much.\n\nThat's not to say that the mailing list traffic cannot be wrapped in\nanother interface if somebody has the motivation and spends the effort\nto do it.\n\nFor example, there used to be (and maybe still is) a bidirectional\ngateway that bridged the ruby-talk mailing list into a web forum that was\nrun by a person who thought it's a good idea, and resolved the problems\nthat came out of it.\n\ne-mails have pretty good 1:! correspondence to forum posts or forge PR\ncomments. Some features like post edits or emoji reactions do not\ntranslate, and cannot be provided with e-mail backend.\n\nHowever, presenting the mailing list through a different interface, and\nhosting the application doing the translation is a work that the person\nsuggesting the change would have to do, or hire someone to do for them,\nrather than coming and saying 'Throw away all the tools you have now,\nand install and run this thing instead to make it easy for me'.\n\nThanks\n\nMichal\n"},{"id":"487832","messageId":"xmqq1q9uu5nc.fsf@gitster.g","threadId":"60829","inReplyTo":"009601da55fa$1ecc9580$5c65c080$@nexbridge.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-02T17:39:51Z","receivedAt":"2024-02-02T17:40:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> I should have qualified this with \"free\" NNTP. I have only been able to find\n> for fee NNTP servers where I am. The search continues.\n\nThe NNTP server \"nntp.lore.kernel.org\" carries the mailing list\nserved by lore.kernel.org archives, including this list.\n"},{"id":"487834","messageId":"00a201da5600$574b1ca0$05e155e0$@nexbridge.com","threadId":"60829","inReplyTo":"xmqq1q9uu5nc.fsf@gitster.g","subject":"RE: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-02-02T17:50:36Z","receivedAt":"2024-02-02T17:50:47Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, February 2, 2024 12:40 PM, Junio wrote:\n>To: rsbecker@nexbridge.com\n>Cc: git@vger.kernel.org\n>Subject: Re: Migrate away from vger to GitHub or (on-premise) GitLab?\n> writes:\n>\n>> I should have qualified this with \"free\" NNTP. I have only been able\n>> to find for fee NNTP servers where I am. The search continues.\n>\n>The NNTP server \"nntp.lore.kernel.org\" carries the mailing list served by\n>lore.kernel.org archives, including this list.\n\nThanks. This is sufficient for git. Appreciate it.\n\n"},{"id":"487840","messageId":"xmqqa5oisn91.fsf@gitster.g","threadId":"60829","inReplyTo":"6b34d999-3da2-42ef-bfff-37c8f592347f@gmail.com","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-02T19:02:34Z","receivedAt":"2024-02-02T19:02:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n> While there are some aspects of the documentation that require a\n> familiarity with the source I don't think that is true in general. If\n> someone has a suggestion to improve part of the documentation that\n> they found hard to understand we should be encouraging them to\n> contribute a patch. There is no doubt that there are places where our\n> documentation could be improved and it is not necessary to be a C\n> programmer to contribute improvements to it.\n\nTrue. It is even possible to:\n\n - have a group of document nitpickers, whose charter is to improve\n the documentation by fixing spelling and grammar mistakes and\n mark-up mistakes, while making sure that what the original wanted\n to say is still what the updated version says.\n\n - have a gatekeeper who makes sure that the output from the above\n group is within the scope of its charter, before it is merged to\n the main tree.\n\nThen, the choice of the collaboration medium among \"document\nnitpickers\" can be delegated to the group, as long as the quality of\ntheir output is tightly controlled by the gatekeeper to meet the bar\nof the main tree. The resulting history should be consistent with\nthe rest of the system when seen in \"git shortlog\" output, for\nexample.\n\nThe above is quite similar to how the l10n team works. There is a\nl10n coordinator who acts as the gatekeeper for po/ hierarchy, and\nl10n folks coordinate among themselves without much supervision and\nreview of their output on the list. We can treat the documentation\nwork that does not involve any knowledge of what the documentation\ndescribes the same way.\n\nThanks.\n\n"},{"id":"487841","messageId":"xmqq5xz6sn5i.fsf@gitster.g","threadId":"60829","inReplyTo":"20240202161643.GD119530@mit.edu","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-02T19:04:41Z","receivedAt":"2024-02-02T19:04:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Theodore Ts'o\" writes:\n\n> So from an open source project perspective, which is primarily run by\n> volunteers, each open source project has to make a cost-benefit\n> tradeoff as far as the *project* is concerned. Individuals do not\n> have a fundamental human right to contribute to a project. Hence, the\n> open source project doesn't owe an obligation to spend a huge amount\n> of effort supporting some kind of forge web site just because some\n> potential contributors are clammoring for it. Especially if they are\n> saying that they can't be bothered to follow the mailing list traffic\n> because it's somehow too much.\n\nThanks for saying this (even though with my Devil's advocate hat on,\nI am not sure how strong our \"this is run by volunteers, so do not\ndemand\" card is these days).\n\n> (Of course, I have all of the Linux kernel mailing list flowing into\n> my inbox, and have e-mail practices that can handle that load --- so\n> it's hard for me to have much sympathy about people complaining that\n> the e-mail load for git is too large --- compared to LKML, it's\n> *nothing*. :-)\n\nTrue, too. We may have enough patch traffic but not enough reviews\non them.\n"},{"id":"487848","messageId":"20240202212809.GA36616@mit.edu","threadId":"60829","inReplyTo":"xmqq5xz6sn5i.fsf@gitster.g","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2024-02-02T21:28:09Z","receivedAt":"2024-02-02T21:28:24Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Feb 02, 2024 at 11:04:41AM -0800, Junio C Hamano wrote:\n> \"Theodore Ts'o\" writes:\n> \n> > So from an open source project perspective, which is primarily run by\n> > volunteers, each open source project has to make a cost-benefit\n> > tradeoff as far as the *project* is concerned. Individuals do not\n> > have a fundamental human right to contribute to a project. Hence, the\n> > open source project doesn't owe an obligation to spend a huge amount\n> > of effort supporting some kind of forge web site just because some\n> > potential contributors are clammoring for it. Especially if they are\n> > saying that they can't be bothered to follow the mailing list traffic\n> > because it's somehow too much.\n> \n> Thanks for saying this (even though with my Devil's advocate hat on,\n> I am not sure how strong our \"this is run by volunteers, so do not\n> demand\" card is these days).\n\nEven though a lot of open source developers these days work for\ncompanies, it's rare that engineers get to work on whatever they want.\nMore often than not, open source developeres are asked to primarily\nwork on features that have a tie to their employer's business goals.\nDifferent companies might call use different corporate-speak; for\nexample, perhaps on e company might use \"year of efficiency\" or\n\"sharpening our focus\", but the reality is that companies are asking\nengineers to spend more time of features that those companies want.\n\nWhat this tends to mean is that engineers have less time to do\ncommunity work --- such as code reviews --- or they have to do that\nwork \"on their own time\", e.g., late at night or on weekends. Those\nof us who work as project leads, or subsystem leads for open source\nprojects, are trying to push back against this dynamic, because there\nis always maintenance work that need to be done to keep the project\nhealthy, including bug scrubbing, code review, improving tests, etc.\n\nAs a Linux kernel subsystem maintainer, I am super grateful for those\nwho do code reviews and those who work test regressions, because in\ngeneral, that which doesn't get done by other developers ends up\ngetting done by the maintainers and project leads if it's going to\nhappen at all.\n\nWhen it comes to requests like \"you should migrate the project to use\nsome forge web site, because we can't be bothered to use e-mail, and\nweb interfaces are the new hotness\", the entitlement that comes from\nthat request (which is in the subject line of this thread), can\nsometimes be a bit frustrating.\n\nGoing back to the original topic of this thread, my personal\nexperience has been that the *vest* percentage of pull requests that I\nget from github tend to be drive-by pull requests that are very low\nquality, especially compared to those that I get via the mailing list.\nSo making a change to use a forge which might result in a larger\nnumber of lower quality code contributions, when code review bandwidth\nmight be more of a bottlenck, might not be as appealing as some might\nthink.\n\n\t\t\t\t\t- Ted\n"},{"id":"487893","messageId":"6dc25a1ab1531b508e844cee1c970438@manjaro.org","threadId":"60829","inReplyTo":"Zb+pQk9R3AOouFxF@ugly","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-04T15:28:58Z","receivedAt":"2024-02-04T15:29:11Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-04 16:12, Oswald Buddenhagen wrote:\n> On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:\n>> Given the open nature of lore it should be feasible to provide\n>> additional interfaces on top of it that cater to people used to PRs\n>> on popular forge web UIs without hijacking the whole project and the\n>> existing tools and interfaces. For some reason people are set on\n>> replacing it as a whole, and removing the interfaces they personally\n>> don't use,\n> \n>> calling them obosolete.\n>> \n> because they positively *are*.\n> \n> when i started, patch-based code reviews were the norm, and i'm still\n> using them for my small project with almost no external contributions.\n> \n> \n> but after working with gerrit code review for over a decade, i find it\n> mind-boggling that people are still voluntarily subjecting themselves\n> to mail-based reviews for serious high-volume work.\n> \n> it doesn't matter just how super-proficient you got with your old\n> tools. there is just no way you'll get anywhere near as efficient as\n> you would with the new ones, if you just were interested enough to\n> learn them. migrating the workflows that are worth keeping isn't such\n> a bit deal.\n\nPlease, keep in mind that not everyone lives in a web browser and\nloves to click around. Some people simply prefer to use the CLI\nutilities and to press the keys on their keyboards, and are very\nefficient while doing that.\n\n> i'll note that i don't consider github-like forges to be adequate\n> tools for serious work, as they seem to intentionally discourage\n> producing polished commits.\n> the gerrit project is unfortunately not interested in building a\n> proper forge, but luckily there is a bridge to github (hosted version\n> available at gerrithub.io).\n"},{"id":"487894","messageId":"20240204154714.GZ9696@kitsune.suse.cz","threadId":"60829","inReplyTo":"Zb+pQk9R3AOouFxF@ugly","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2024-02-04T15:47:14Z","receivedAt":"2024-02-04T15:47:16Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Sun, Feb 04, 2024 at 04:12:02PM +0100, Oswald Buddenhagen wrote:\n> On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:\n> > Given the open nature of lore it should be feasible to provide\n> > additional interfaces on top of it that cater to people used to PRs\n> > on popular forge web UIs without hijacking the whole project and the\n> > existing tools and interfaces. For some reason people are set on\n> > replacing it as a whole, and removing the interfaces they personally\n> > don't use,\n> \n> > calling them obosolete.\n> > \n> because they positively *are*.\n> \n> when i started, patch-based code reviews were the norm, and i'm still using\n> them for my small project with almost no external contributions.\n> \n> but after working with gerrit code review for over a decade, i find it\n> mind-boggling that people are still voluntarily subjecting themselves to\n> mail-based reviews for serious high-volume work.\n\nI have yet to see gerrit in action. Very few projects use it so it's\ndifficult to gauge what tradeoffs compared to e-mail based workflow it\ndoes provide.\n\n> it doesn't matter just how super-proficient you got with your old tools.\n> there is just no way you'll get anywhere near as efficient as you would with\n> the new ones, if you just were interested enough to learn them. migrating\n> the workflows that are worth keeping isn't such a bit deal.\n\nHave you migrated them to gerrit already, and tought all the git\ncontributors how to use them from gerrit?\n\nSomobody has to do it.\n\nAlso can you migrate away from gerrit once it becomes defunct or new,\nbetter alternative emerges?\n\nRecently it seems that forges offer a 'download your project data'\noption, probably as a result of GDPR. What use is such data blob though?\n\nAn e-mail archive is that: an archive. It's a medium that you can read\nwith a wealth of software today, and 100 years from now. An achivable\ndata format.\n\nCompare that with the 'download your data' blob from a forge. Can it be\nuploaded even to a diffferent instance of the same forge to restore your\nproject elsewhere? Interpreted by any tool othar than the correct\nvintage of that same forge? Deos even more than one instance of the\nforge exist?\n\nI have seen what hoops Gitea is jumping through to import data from\nother forges, and it's not pretty. Understandably, people who have seen\nrise and fall of bitkeeper are wary of any tool that keeps your data\nlocked to itself.\n\nAnd even if you do convert to gerrit it's unlikely to satisfy the \"Why\nare you not using github or gitlab\" crowd. It's not one of the big,\npopular forges they are familiar with, the UX is significantly\ndifferent.\n\nThanks\n\nMichal\n"},{"id":"487895","messageId":"20240204155107.GA9696@kitsune.suse.cz","threadId":"60829","inReplyTo":"6dc25a1ab1531b508e844cee1c970438@manjaro.org","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2024-02-04T15:51:07Z","receivedAt":"2024-02-04T15:51:10Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Sun, Feb 04, 2024 at 04:28:58PM +0100, Dragan Simic wrote:\n> On 2024-02-04 16:12, Oswald Buddenhagen wrote:\n> > On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:\n> > > Given the open nature of lore it should be feasible to provide\n> > > additional interfaces on top of it that cater to people used to PRs\n> > > on popular forge web UIs without hijacking the whole project and the\n> > > existing tools and interfaces. For some reason people are set on\n> > > replacing it as a whole, and removing the interfaces they personally\n> > > don't use,\n> > \n> > > calling them obosolete.\n> > > \n> > because they positively *are*.\n> > \n> > when i started, patch-based code reviews were the norm, and i'm still\n> > using them for my small project with almost no external contributions.\n> > \n> > \n> > but after working with gerrit code review for over a decade, i find it\n> > mind-boggling that people are still voluntarily subjecting themselves\n> > to mail-based reviews for serious high-volume work.\n> > \n> > it doesn't matter just how super-proficient you got with your old\n> > tools. there is just no way you'll get anywhere near as efficient as\n> > you would with the new ones, if you just were interested enough to\n> > learn them. migrating the workflows that are worth keeping isn't such\n> > a bit deal.\n> \n> Please, keep in mind that not everyone lives in a web browser and\n> loves to click around. Some people simply prefer to use the CLI\n> utilities and to press the keys on their keyboards, and are very\n> efficient while doing that.\n\nThe forge vendors found out, and started to provide CLI tools. That's\nnot really a general argument against forge software. Just as people\nliving on web is not general argument against e-mail - it's been brought\nto the web a long time ago.\n\nThanks\n\nMicchal\n"},{"id":"487896","messageId":"9741936d0b69369ea75a9d5d402b68de@manjaro.org","threadId":"60829","inReplyTo":"20240204155107.GA9696@kitsune.suse.cz","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-04T15:58:49Z","receivedAt":"2024-02-04T15:58:55Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"On 2024-02-04 16:51, Michal Suchánek wrote:\n> On Sun, Feb 04, 2024 at 04:28:58PM +0100, Dragan Simic wrote:\n>> On 2024-02-04 16:12, Oswald Buddenhagen wrote:\n>> > On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:\n>> > > Given the open nature of lore it should be feasible to provide\n>> > > additional interfaces on top of it that cater to people used to PRs\n>> > > on popular forge web UIs without hijacking the whole project and the\n>> > > existing tools and interfaces. For some reason people are set on\n>> > > replacing it as a whole, and removing the interfaces they personally\n>> > > don't use,\n>> >\n>> > > calling them obosolete.\n>> > >\n>> > because they positively *are*.\n>> >\n>> > when i started, patch-based code reviews were the norm, and i'm still\n>> > using them for my small project with almost no external contributions.\n>> >\n>> >\n>> > but after working with gerrit code review for over a decade, i find it\n>> > mind-boggling that people are still voluntarily subjecting themselves\n>> > to mail-based reviews for serious high-volume work.\n>> >\n>> > it doesn't matter just how super-proficient you got with your old\n>> > tools. there is just no way you'll get anywhere near as efficient as\n>> > you would with the new ones, if you just were interested enough to\n>> > learn them. migrating the workflows that are worth keeping isn't such\n>> > a bit deal.\n>> \n>> Please, keep in mind that not everyone lives in a web browser and\n>> loves to click around. Some people simply prefer to use the CLI\n>> utilities and to press the keys on their keyboards, and are very\n>> efficient while doing that.\n> \n> The forge vendors found out, and started to provide CLI tools. That's\n> not really a general argument against forge software. Just as people\n> living on web is not general argument against e-mail - it's been \n> brought\n> to the web a long time ago.\n\nPlease, don't get me wrong, I'm not against the GUI and web-based\nutilities in the sense of telling other people they're bad or shouldn't\nbe used. I love the variety and the freedom of choice, so everyone\ncan freely choose the most suitable option for them.\n\nThough, I'd also expect that everyone respect different choices made\nby other people. That's how we keep the variety available.\n"},{"id":"487909","messageId":"Zb+pQk9R3AOouFxF@ugly","threadId":"60829","inReplyTo":"20240202115004.GV9696@kitsune.suse.cz","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-02-04T15:12:02Z","receivedAt":"2024-02-05T01:35:22Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:\n>Given the open nature of lore it should be feasible to provide\n>additional interfaces on top of it that cater to people used to PRs\n>on popular forge web UIs without hijacking the whole project and the\n>existing tools and interfaces. For some reason people are set on\n>replacing it as a whole, and removing the interfaces they personally\n>don't use,\n\n>calling them obosolete.\n>\nbecause they positively *are*.\n\nwhen i started, patch-based code reviews were the norm, and i'm still\nusing them for my small project with almost no external contributions.\n\nbut after working with gerrit code review for over a decade, i find it\nmind-boggling that people are still voluntarily subjecting themselves to\nmail-based reviews for serious high-volume work.\n\nit doesn't matter just how super-proficient you got with your old tools.\nthere is just no way you'll get anywhere near as efficient as you would\nwith the new ones, if you just were interested enough to learn them.\nmigrating the workflows that are worth keeping isn't such a bit deal.\n\ni'll note that i don't consider github-like forges to be adequate tools\nfor serious work, as they seem to intentionally discourage producing\npolished commits.\nthe gerrit project is unfortunately not interested in building a proper\nforge, but luckily there is a bridge to github (hosted version available\nat gerrithub.io).\n"},{"id":"487910","messageId":"ZcA0NEb+lnjeZUBe@ugly","threadId":"60829","inReplyTo":"20240204154714.GZ9696@kitsune.suse.cz","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-02-05T01:04:52Z","receivedAt":"2024-02-05T01:35:33Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Sun, Feb 04, 2024 at 04:47:14PM +0100, Michal Suchánek wrote:\n>On Sun, Feb 04, 2024 at 04:12:02PM +0100, Oswald Buddenhagen wrote:\n>> but after working with gerrit code review for over a decade, i find\n>> it\n>> mind-boggling that people are still voluntarily subjecting themselves to\n>> mail-based reviews for serious high-volume work.\n>\n>I have yet to see gerrit in action. Very few projects use it so it's\n>difficult to gauge what tradeoffs compared to e-mail based workflow it\n>does provide.\n>\nfrom my just slightly biased perspective ;-) i can't see any significant\ntrade-offs except for some set-up cost (that will quickly pay for\nitself).\n\nin fact, my gerrit workflow is still \"e-mail based\", in that everything\nis driven by the notification mails, only that i \"branch out\" to the\nbrowser whenever something interesting happens.\n\nfor the CLI hardliners there are gertty and emacs egerrit, but i see no\npoint in using either despite being a heavy CLI and TUI user. given how\n\"much\" attention these tools get despite there being literally tens of\nthousands of regular gerrit users, i'm inclined to think that there is\nindeed very little demand.\n\ngerrit also has an incoming email gateway, but i'm not sure how advanced\nit is - at some point it required well-formed html replies as input.\n\nif one really wants to, one can install a webhook or event stream\nwatcher that posts all activity to a mailing list (and i don't mean\n_the_ list, because it would be just noise on top of everyone's\nindividual notifications).\n\n>> migrating the workflows that are worth keeping isn't such a bit deal.\n>\n>Have you migrated them to gerrit already, and t[a]ught all the git\n>contributors how to use them from gerrit?\n>\nthat challenge is sort of meaningless, because the only workflow within\nthe git project that i'm aware of that would affect \"all the git\ncontributors\" is the interaction with gerrit itself. which has a very\nsteep, but also extremely short learning curve. and there are tools to\nmeke it more pleasant - https://wiki.qt.io/Git-gpush-scripts (yep,\nshameless self-promotion here).\n\ni'm not aware of any pre-integration build bots, so nothing to do on\nthat front except for some mirroring adjustments (gerrit insists on\nbeing its own authoritative git server).\n\ngitgitgadget would just become obsolete, to be replaced by the github\nintegration plugin.\n\nmy main concern is with the maintainer workflow:\n\nthe way gerrit is usually used, the contributor determines the target\nbranch, and the changes are merged directly to it after they are\napproved. unclean merges must also be eliminated during review. that\nworks just fine, but it doesn't match the refs and merge commit messages\njunio produces. and while aggregating pending changes into `seen` would\nbe still perfectly possible (each change including its dependencies is\njust a ref), it would be somewhat awkward due to the naming and location\nof the change refs.\n\nto reproduce the existing merge workflow more faithfully,\n- junio would have to monitor incoming changes, manually create an empty\n branches for each topic, and change the target branch of all changes\n in each topic\n- the gerrit-side integration would then happen into that branch\n- junio would then proceed with manually merging the branch and\n direct-pushing (that is, not creating a review for it) the merge into\n next or maint\nthis is reallly just the current workflow, and can be equally automated,\njust with slightly different tooling. only it's ... weird for gerrit,\nartificially creating a bottleneck. the gerrit integration workflow is\nnaturally decentralized.\n\npersonally, i would just switch to the usual gerrit workflow, and at\nleast for `seen` use a merge-free workflow -- with gpick (gpush\ncomplement, see link above) it's absolutely trivial to track all\ninteresting branches stacked onto each other.\n\n>Somobody has to do it.\n>\nyes. and if nobody does, then everybody keeps paying the cost of not\ndoing it. that might incentivize Somebody (TM) with the resources and a\nvested interest.\n\n>Also can you migrate away from gerrit once it becomes defunct or new,\n>better alternative emerges?\n>\n>Recently it seems that forges offer a 'download your project data'\n>option, probably as a result of GDPR. What use is such data blob though?\n>\ncurrent gerrit keeps the meta data in (yet more) awkwardly named refs\ncontaining plain-text files, so that's no issue. one could render it\ninto a read-only view, or convert it.\n\n>An e-mail archive is that: an archive. It's a medium that you can read\n>with a wealth of software today, and 100 years from now. An achivable\n>data format.\n>\nwith a mailing list archiving the event stream, we'd have that.\n\n>Compare that with the 'download your data' blob from a forge. Can it be\n>uploaded even to a diffferent instance of the same forge to restore your\n>project elsewhere? Interpreted by any tool othar than the correct\n>vintage of that same forge? Deos even more than one instance of the\n>forge exist?\n>\na review meta-data standard is being discussed from time to time, but it\nhasn't gone anywhere yet.\n\nbut looking at it from a practical perspective, with a list-based\narchive the situation wouldn't be any worse than it is right now if\ngerrit was to suddenly disappear.\n\nduring my tenure at the qt project i established a commit policy (and\ndeployed tooling to help enforce it) that presumes that gerrit could be\nreplaced at any time, so commit messages are not supposed to refer to\nother commits by gerrit change ids or review urls. (in principle, this\nworks even for pending and abandoned changes, as each patchset (revision\nof a change) keeps its commit and therefore sha1 forever.)\nof course that's not practical for regular mailing list posts, but one\ncan't have everything ...\n\n>And even if you do convert to gerrit it's unlikely to satisfy the \"Why\n>are you not using github or gitlab\" crowd. It's not one of the big,\n>popular forges they are familiar with, the UX is significantly\n>different.\n>\ni can confirm that in the qt project this is indeed absolutely the case,\nand the last related thread isn't even cold yet.\nbut why should the people with standards care? lowering the barrier to\nentry is all dandy, but not when it causes significant detriment to the\nworkflow of those who do most work.\nnote that the original request in this thread was for \"structured\ndiscussion\", and gerrit would absolutely provide that, among other\nthings.\n"},{"id":"488043","messageId":"DB9P195MB213080E6DD9ECA0EE3D2B491E2462@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","threadId":"60829","inReplyTo":"20240202212809.GA36616@mit.edu","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Hans Meiser","fromEmail":"brille1@hotmail.com","sentAt":"2024-02-06T07:22:31Z","receivedAt":"2024-02-06T07:22:33Z","isPatch":false,"sender":{"key":"brille1@hotmail.com","avatar":null},"body":"> Please, keep in mind that not everyone lives in a web browser and\n> loves to click around. Some people simply prefer to use the CLI\n> utilities and to press the keys on their keyboards, and are very\n> efficient while doing that.\n\nYou are aware of the fact that all these Git collaboration websites are providing a REST interface? So, you are free to access any function by means of CLI?\n\n\n> As a Linux kernel subsystem maintainer, I am super grateful for those\n> who do code reviews and those who work test regressions, because in\n> general, that which doesn't get done by other developers ends up\n> getting done by the maintainers and project leads if it's going to\n> happen at all.\n> \n> When it comes to requests like \"you should migrate the project to use\n> some forge web site, because we can't be bothered to use e-mail, and\n> web interfaces are the new hotness\", the entitlement that comes from\n> that request (which is in the subject line of this thread), can\n> sometimes be a bit frustrating.\n> \n> Going back to the original topic of this thread, my personal\n> experience has been that the *vest* percentage of pull requests that I\n> get from github tend to be drive-by pull requests that are very low\n> quality, especially compared to those that I get via the mailing list.\n> So making a change to use a forge which might result in a larger\n> number of lower quality code contributions, when code review bandwidth\n> might be more of a bottlenck, might not be as appealing as some might\n> think.\n\nAgain, you are aware of the fact that Git collaboration websites provide a powerful user rights management? (https://docs.gitlab.com/ee/user/permissions.html https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)\n\nUsing Git collaboration websites you can easily control and filter who will be contributing. And you are able to focus on issues and filter out spammers. It's quite the contrary of of what you have now with your mailing list. A vanilla student from the \"axis of evil\" could bomb your mailing list in a snap by just registering a dozen new e-mail accounts and writing a script that bloated your mailing list. And you cannot thwart that at all.\n\nWith your mailing list approach you don't have ANY sort of gateway to keep away spam or \"low quality\" contributions other by means of the intrinsic clumsiness and intricateness of a mailing list. After having subscribed to your mailing list, my e-mail spam rate immediately increased significantly.\n\nAgain, on Git collaboration websites you can hide your personal access information and focus on your repository tasks rather than wasting your time on cumbersome additional and unneccessary work.\n\nI'm getting the impression that you didn't yet seriously investigate on the features these Git collaboration websites provide.\n\nLet me finish this thread from my side now. I suggested a way to improve your daily business by employing tools that have been established and proven to raise code and documentation quality and that will allow you to focus on important tasks rather than wasting time on an old fashioned workflow. Well, it's up to you now to decide whether to stick here or to migrate.\n\nCheers,\nAxel"},{"id":"488050","messageId":"aca58f5d44d48f98b464e6c4a8d637fe@manjaro.org","threadId":"60829","inReplyTo":"DB9P195MB213080E6DD9ECA0EE3D2B491E2462@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM","subject":"Re: Migrate away from vger to GitHub or (on-premise) GitLab?","fromName":"Dragan Simic","fromEmail":"dsimic@manjaro.org","sentAt":"2024-02-06T08:06:22Z","receivedAt":"2024-02-06T08:06:24Z","isPatch":false,"sender":{"key":"dsimic@manjaro.org","avatar":null},"body":"Hello Hans,\n\nOn 2024-02-06 08:22, Hans Meiser wrote:\n>> Please, keep in mind that not everyone lives in a web browser and\n>> loves to click around. Some people simply prefer to use the CLI\n>> utilities and to press the keys on their keyboards, and are very\n>> efficient while doing that.\n> \n> You are aware of the fact that all these Git collaboration websites\n> are providing a REST interface? So, you are free to access any\n> function by means of CLI?\n\nPerhaps I wasn't clear enough, so please allow me to clarify a bit.\n\nTo me, it isn't just about using the CLI or TUI utilities. It's\nactually about using standard CLI/TUI utilities, such as using git\ndirectly, instead of using some specialized CLI/TUI utilities that\nare made to interact with a forge in a forge-specific way.\n\nPerhaps you'll ask why I find using a forge such a bad thing, so\nI'll try to provide an answer in advance.\n\nGit is a widespread, standard system of utilities that isn't backed\nby some company that sees its profit as the main goal. On the other\nhand, most forges are backed by a company, and as we know, companies\ndon't last forever, and they often pivot due to business decisions.\nWhat we don't want is to tie the project into something that isn't\nexpected to virtually last forever.\n\nIt's similar to the concept of bit rot. A lot of data is poured\ninto something and it slowly starts to degrade over time. Though,\nin the case of a forge becoming no longer available it wouldn't be\na gradual decay, but an abrupt disruption that would make all the\ndata unavailable and unusable. Of course, the data perhaps can be\nexported from a forge in some format, including the discussions,\nbut who's going to sift through years worth of such data and make\nit usable through some other interface or in some other format?\nFrankly, I wouldn't see that happening.\n\nOn the other hand, discussion in form of mailing lists aren't tied\nto anything, the underlying data format has been around for decades,\nand the raw data can be accessed by any editor or viewer, such as\nless(1). It isn't tied to anything.\n\n>> As a Linux kernel subsystem maintainer, I am super grateful for those\n>> who do code reviews and those who work test regressions, because in\n>> general, that which doesn't get done by other developers ends up\n>> getting done by the maintainers and project leads if it's going to\n>> happen at all.\n>> \n>> When it comes to requests like \"you should migrate the project to use\n>> some forge web site, because we can't be bothered to use e-mail, and\n>> web interfaces are the new hotness\", the entitlement that comes from\n>> that request (which is in the subject line of this thread), can\n>> sometimes be a bit frustrating.\n>> \n>> Going back to the original topic of this thread, my personal\n>> experience has been that the *vest* percentage of pull requests that I\n>> get from github tend to be drive-by pull requests that are very low\n>> quality, especially compared to those that I get via the mailing list.\n>> So making a change to use a forge which might result in a larger\n>> number of lower quality code contributions, when code review bandwidth\n>> might be more of a bottlenck, might not be as appealing as some might\n>> think.\n> \n> Again, you are aware of the fact that Git collaboration websites\n> provide a powerful user rights management?\n> (https://docs.gitlab.com/ee/user/permissions.html\n> https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)\n> \n> Using Git collaboration websites you can easily control and filter who\n> will be contributing. And you are able to focus on issues and filter\n> out spammers. It's quite the contrary of of what you have now with\n> your mailing list. A vanilla student from the \"axis of evil\" could\n> bomb your mailing list in a snap by just registering a dozen new\n> e-mail accounts and writing a script that bloated your mailing list.\n> And you cannot thwart that at all.\n\nI don't remember such cases. It doesn't mean something like that will\nnever happen, though. Also, pretty much anyone can create dozens of\nfake accounts on a forge and do malicious things.\n\nPlease note that creating an account of any kind is often unacceptable\nto many people. I was a bit surprised to discover that.\n\n> With your mailing list approach you don't have ANY sort of gateway to\n> keep away spam or \"low quality\" contributions other by means of the\n> intrinsic clumsiness and intricateness of a mailing list. After having\n> subscribed to your mailing list, my e-mail spam rate immediately\n> increased significantly.\n\nYou must be having bad luck for some reason. Knocking on wood,\nI've received zero spam emails directed to my email address since\nsubscribing to the list.\n\n> Again, on Git collaboration websites you can hide your personal access\n> information and focus on your repository tasks rather than wasting\n> your time on cumbersome additional and unneccessary work.\n\nIf you ask me, one's identity shouldn't be hidden when one willingly\ncontributes to a public project. Taking part in the discussions is\nalso a way of contributing.\n\n> I'm getting the impression that you didn't yet seriously investigate\n> on the features these Git collaboration websites provide.\n> \n> Let me finish this thread from my side now. I suggested a way to\n> improve your daily business by employing tools that have been\n> established and proven to raise code and documentation quality and\n> that will allow you to focus on important tasks rather than wasting\n> time on an old fashioned workflow. Well, it's up to you now to decide\n> whether to stick here or to migrate.\n\nAs I noted already, these days it's expected too much that some\nutilities will do the programmer's work. Also, being unable to\nfollow a moderately busy mailing list, such as the git's, may also\nshow that one needs to improve their own skills in some areas.\n\nIn the case of high-volume mailing lists, I admit that things can\nbe different and much harder to handle. That's why I plan to work\non extending mlmmj to support muting and unmuting threads. [1]\n\n[1] \nhttps://lore.kernel.org/git/93be64af474b228e914a4c39443b5a9c@manjaro.org/\n"}]}