Migrate away from vger to GitHub or (on-premise) GitLab?

> Hi,
>
> is there any current discussion about moving Git development away from using a mailing list to some modern form of collaboration?
>
> 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.
>
> Are you consideration for migrating?
>
> Regards,
> Axel Dahmen

> is there any current discussion about moving Git development away from
> using a mailing list to some modern form of collaboration?
> 
> 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.
> 
> Are you consideration for migrating?

> is there any current discussion about moving Git development away from using
> a mailing list to some modern form of collaboration?
> 
> 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.

> On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:
>> is there any current discussion about moving Git development away from 
>> using
>> a mailing list to some modern form of collaboration?
>> 
>> 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.
> 
> Here's a perspective from the world of Linux kernel, where this 
> discussion is
> continuously raging. Funny enough, the main objection a lot of kernel
> maintainers have to forges is that it makes it really hard to find 
> relevant
> discussions once the volume goes above a certain threshold. These folks 
> have
> become *extremely* efficient at querying and filtering the mailing list
> traffic, to the point where all they ever see are just those 
> discussions
> relevant to their work. They love the fact that it all arrives into the 
> same
> place (their inbox) without having to go and click on various websites, 
> each
> with their own login information, UI, and preferred workflow.
> 
> The kernel maintainers are able to review tens of thousands of patches 
> monthly
> with only about a hundred or so top maintainers. To them, this system 
> is
> working great, especially now that some tools allow easy ways to query,
> retrieve, verify, and apply patches (shameless plug for lore, lei, and 
> b4
> here).
> 
> The obvious problem, of course, is that these folks are FOSS's 
> "marathon
> runners" who got really good at their workflow, but the situation is 
> different
> for anyone else who is just starting out. Any new kernel maintainer 
> stepping
> up obviously finds this overwhelming, because they aren't yet so good 
> at
> filtering the huge volume of the mailing list traffic and to them it's 
> just a
> torrent of mostly irrelevant patches.
> 
>> Are you consideration for migrating?
> 
> Yes, of course, this is constantly under consideration. There isn't 
> some sort
> of anti-forge cabal that is preventing things from going forward, but 
> there
> are some serious hurdles and considerations to consider:
> 
> - How to avoid a vendor lock-in? Those of us who have been around for a 
> while
>   have seen forges bloom, and then shrink into irrelevance (e.g. 
> bitkeeper)
>   or slowly ensh*ttify to the point of unusability (sourceforge). 
> GitHub is a
>   proprietary service owned by a single company who are currently
>   FOSS-friendly, but have certainly been extremely FOSS-hostile in the 
> past.
>   GitLab is open-core, and the current record for open-core projects 
> isn't
>   very encouraging (Puppet open-cored themselves into irrelevance, 
> Terraform
>   has gone full-proprietary, among most recent examples). Full-FOSS
>   alternatives exist, but people aren't really that enthused about 
> using
>   less-popular solutions like Forgejo, because they hate unfamiliar UIs 
> almost
>   as much, or even more than they hate unfiltered mailing lists.
> 
> - How to avoid centralization and single points of failure? If Linux or 
> Git
>   move to a self-hosted forge, how do we ensure that an adversary can't 
> stop
>   all development on a project by knocking it offline for weeks? This 
> has
>   literally just happened to Sourcehut and Codeberg -- and as far as 
> anyone
>   can tell, the attacker was just bored and knocked them out just 
> because they
>   could. Yes, you can knock out vger, but this will only impact the 
> mailing
>   list -- people can still send around patches and hold discussions by
>   temporarily moving to alternative hosts. With the distributed nature 
> of the
>   mailing list archives, this can even be largely transparent to anyone 
> using
>   lei-queries.
> 
> - How to avoid alienating these hundreds of key maintainers who are now
>   extremely proficient at their query-based workflows? We're talking 
> about an
>   extremely finely-tuned engine that is performing remarkably well -- 
> we don't
>   want to disrupt development for months just to try things out with a 
> forge
>   and find that it isn't working out.
> 
> Finally, there's also the consideration of current trends. One upside 
> of "AI"
> (LLM, really) technologies is that they are extremely good at taking in 
> a huge
> source of data and finding relevant information based on natural 
> language
> queries. I can very easily see a mechanism spring up in the next year 
> or less
> where you can issue a query like "send me any threads about reftables 
> or
> promissory remotes if they contain follow-ups from Junio" and reasonaly 
> expect
> this to work and work great -- all while keeping things decentralized 
> in
> addition to distributed.
> 
> Above all, this isn't a "forges are terrible and shouldn't be used" 
> response
> -- they are clearly useful, especially when it comes to CI 
> integrations. A
> large part of my work is bridging forges with mailing lists and 
> vice-versa,
> which I hope I'll be able to do in the near future (GitGitGadget 
> already does
> it with GitHub, but my goal is to have a pluggable multi-forge 
> solution). I
> just wanted to highlight the aspects that aren't necessarily obvious or
> visible from the outside.

> Hello Konstantin,
> 
> On 2024-02-01 16:39, Konstantin Ryabitsev wrote:
>> On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:
>>> is there any current discussion about moving Git development away 
>>> from using
>>> a mailing list to some modern form of collaboration?
>>> 
>>> 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.
>> 
>> Here's a perspective from the world of Linux kernel, where this 
>> discussion is
>> continuously raging. Funny enough, the main objection a lot of kernel
>> maintainers have to forges is that it makes it really hard to find 
>> relevant
>> discussions once the volume goes above a certain threshold. These 
>> folks have
>> become *extremely* efficient at querying and filtering the mailing 
>> list
>> traffic, to the point where all they ever see are just those 
>> discussions
>> relevant to their work. They love the fact that it all arrives into 
>> the same
>> place (their inbox) without having to go and click on various 
>> websites, each
>> with their own login information, UI, and preferred workflow.
>> 
>> The kernel maintainers are able to review tens of thousands of patches 
>> monthly
>> with only about a hundred or so top maintainers. To them, this system 
>> is
>> working great, especially now that some tools allow easy ways to 
>> query,
>> retrieve, verify, and apply patches (shameless plug for lore, lei, and 
>> b4
>> here).
>> 
>> The obvious problem, of course, is that these folks are FOSS's 
>> "marathon
>> runners" who got really good at their workflow, but the situation is 
>> different
>> for anyone else who is just starting out. Any new kernel maintainer 
>> stepping
>> up obviously finds this overwhelming, because they aren't yet so good 
>> at
>> filtering the huge volume of the mailing list traffic and to them it's 
>> just a
>> torrent of mostly irrelevant patches.
>> 
>>> Are you consideration for migrating?
>> 
>> Yes, of course, this is constantly under consideration. There isn't 
>> some sort
>> of anti-forge cabal that is preventing things from going forward, but 
>> there
>> are some serious hurdles and considerations to consider:
>> 
>> - How to avoid a vendor lock-in? Those of us who have been around for 
>> a while
>>   have seen forges bloom, and then shrink into irrelevance (e.g. 
>> bitkeeper)
>>   or slowly ensh*ttify to the point of unusability (sourceforge). 
>> GitHub is a
>>   proprietary service owned by a single company who are currently
>>   FOSS-friendly, but have certainly been extremely FOSS-hostile in the 
>> past.
>>   GitLab is open-core, and the current record for open-core projects 
>> isn't
>>   very encouraging (Puppet open-cored themselves into irrelevance, 
>> Terraform
>>   has gone full-proprietary, among most recent examples). Full-FOSS
>>   alternatives exist, but people aren't really that enthused about 
>> using
>>   less-popular solutions like Forgejo, because they hate unfamiliar 
>> UIs almost
>>   as much, or even more than they hate unfiltered mailing lists.
>> 
>> - How to avoid centralization and single points of failure? If Linux 
>> or Git
>>   move to a self-hosted forge, how do we ensure that an adversary 
>> can't stop
>>   all development on a project by knocking it offline for weeks? This 
>> has
>>   literally just happened to Sourcehut and Codeberg -- and as far as 
>> anyone
>>   can tell, the attacker was just bored and knocked them out just 
>> because they
>>   could. Yes, you can knock out vger, but this will only impact the 
>> mailing
>>   list -- people can still send around patches and hold discussions by
>>   temporarily moving to alternative hosts. With the distributed nature 
>> of the
>>   mailing list archives, this can even be largely transparent to 
>> anyone using
>>   lei-queries.
>> 
>> - How to avoid alienating these hundreds of key maintainers who are 
>> now
>>   extremely proficient at their query-based workflows? We're talking 
>> about an
>>   extremely finely-tuned engine that is performing remarkably well -- 
>> we don't
>>   want to disrupt development for months just to try things out with a 
>> forge
>>   and find that it isn't working out.
>> 
>> Finally, there's also the consideration of current trends. One upside 
>> of "AI"
>> (LLM, really) technologies is that they are extremely good at taking 
>> in a huge
>> source of data and finding relevant information based on natural 
>> language
>> queries. I can very easily see a mechanism spring up in the next year 
>> or less
>> where you can issue a query like "send me any threads about reftables 
>> or
>> promissory remotes if they contain follow-ups from Junio" and 
>> reasonaly expect
>> this to work and work great -- all while keeping things decentralized 
>> in
>> addition to distributed.
>> 
>> Above all, this isn't a "forges are terrible and shouldn't be used" 
>> response
>> -- they are clearly useful, especially when it comes to CI 
>> integrations. A
>> large part of my work is bridging forges with mailing lists and 
>> vice-versa,
>> which I hope I'll be able to do in the near future (GitGitGadget 
>> already does
>> it with GitHub, but my goal is to have a pluggable multi-forge 
>> solution). I
>> just wanted to highlight the aspects that aren't necessarily obvious 
>> or
>> visible from the outside.
> 
> Thank you very much for taking your time to write this down!
> Much appreciated.

> Thank you for enlightening me and elaborating on all of these very
> important facts!
> 
> Just to make sure: So "git" is considered part of the kernel? And the
> "git documentation" is considered part of the kernel, too?

> Shouldn't these topics be separated then into separate repositories,
> particularly the git documentation?
> 
> For 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.)

> With 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.
> 
> Setting 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.

>> Could you, please, clarify what kind of git documentation are you
>> referring to?  Are you having git man pages in mind?
> 
> Yes, these in particular.
> 
> From 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.

>> Quite frankly, I think you've missed some important points from the
>> Konstantin's message.  To sum it up a bit, not having continuous 
>> support
>> is simply unacceptable for any kind of a long-term project.
> 
> As 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.

> In 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/
> 
> In 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.
> 
> Many 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.

>On 2024-02-01 19:36, Hans Meiser wrote:
>>> Could you, please, clarify what kind of git documentation are you
>>> referring to?  Are you having git man pages in mind?
>>
>> Yes, these in particular.
>>
>> From 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.
>
>Please keep in mind that editing the git man pages requires very intimate knowledge
>of the related git source code.  Many times even small changes to the language style
>can change the meaning and diverge the man pages from the source code, making
>the man pages useless.
>
>>> Quite frankly, I think you've missed some important points from the
>>> Konstantin's message.  To sum it up a bit, not having continuous
>>> support is simply unacceptable for any kind of a long-term project.
>>
>> As 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.
>
>A git server?  I was under impression that you proposed running an own instance of
>GitLab or something similar.

>> In 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/
>>
>> In 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.
>>
>> Many 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.

> On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:
>> On 2024-02-01 19:36, Hans Meiser wrote:
>>>> Quite frankly, I think you've missed some important points from the
>>>> Konstantin's message.  To sum it up a bit, not having continuous
>>>> support is simply unacceptable for any kind of a long-term project.
>>> 
>>> As 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.
>> 
>> A git server?  I was under impression that you proposed running an own 
>> instance of
>> GitLab or something similar.
> 
> Git is unique, as a project, given that everything (! Not everything
> but a whole lot) is managed using git, including the enterprise git
> server platforms.
> 
> A 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.

>>> In 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/
>>> 
>>> In 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.
>>> 
>>> Many 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.

>> Please keep in mind that editing the git man pages requires very
>> intimate knowledge of the related git source code.  Many times even
>> small changes to the language style can change the meaning and diverge
>> the man pages from the source code, making the man pages useless.
> 
> Sure. 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.

>> A git server?  I was under impression that you proposed running an
>> own instance of GitLab or something similar.
> 
> Basically, 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).

> On 2024-02-02 11:18, Hans Meiser wrote:
>>> Please keep in mind that editing the git man pages requires very
>>> intimate knowledge of the related git source code.  Many times even
>>> small changes to the language style can change the meaning and 
>>> diverge
>>> the man pages from the source code, making the man pages useless.
>> 
>> Sure. 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.
> 
> That might work out in some places, but I'm not really sure about the
> overall effectiveness.  The git man pages don't document function 
> calls.
> 
>>> A git server?  I was under impression that you proposed running an
>>> own instance of GitLab or something similar.
>> 
>> Basically, 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).
> 
> The plus brings additional issues.  It's been already noted that 
> favoring
> any of those solutions actually wouldn't be in the interest of git 
> itself
> as a project, because it wants to remain neutral.
> 
> IMHO, these days too much is expected to be handled by "something 
> else",
> instead of the developers handling that.  It's like offloading the 
> basically
> unavoidable complexity to some utility, and expecting that the 
> complexity
> will somehow go away.
> 
> In other words, a developer has to keep quite a lot in their short-term
> memory, and a lot in their long-term memory, to be able to accomplish 
> some
> task, and hardly any utility is going to make that significantly 
> easier.
> The same principle, in general, applies to a group of developers 
> working
> on the same task.

> On 2024-02-01 19:36, Hans Meiser wrote:
> Please keep in mind that editing the git man pages requires very
> intimate knowledge of the related git source code.  Many times even
> small changes to the language style can change the meaning and diverge
> the man pages from the source code, making the man pages useless.

> On 01/02/2024 19:00, Dragan Simic wrote:
>> On 2024-02-01 19:36, Hans Meiser wrote:
>> Please keep in mind that editing the git man pages requires very
>> intimate knowledge of the related git source code.  Many times even
>> small changes to the language style can change the meaning and diverge
>> the man pages from the source code, making the man pages useless.
> 
> While there are some aspects of the documentation that require a
> familiarity with the source I don't think that is true in general. If
> someone has a suggestion to improve part of the documentation that
> they found hard to understand we should be encouraging them to
> contribute a patch. There is no doubt that there are places where our
> documentation could be improved and it is not necessary to be a C
> programmer to contribute improvements to it.

> While there are some aspects of the documentation that require a
> familiarity with the source I don't think that is true in general. If
> someone has a suggestion to improve part of the documentation that
> they found hard to understand we should be encouraging them to
> contribute a patch. There is no doubt that there are places where our
> documentation could be improved and it is not necessary to be a C
> programmer to contribute improvements to it.

> > Could you, please, clarify what kind of git documentation are you
> > referring to?  Are you having git man pages in mind?
> 
> Yes, these in particular.
> 
> From 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.

> >Quite frankly, I think you've missed some important points from the
> > Konstantin's message.  To sum it up a bit, not having continuous support
> > is simply unacceptable for any kind of a long-term project.
> 
> As 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.

> > In 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/
> 
> The Git project has tried for a long time to be neutral on any
> particular external piece of software.  Installing a GitLab server as
> our preferred development platform would promote GitLab as the preferred
> forge to other users.  Similarly, moving to GitHub would prefer GitHub
> over other forges.  That's not a thing we want to do.
> 
> We also don't accept patches or features for the benefit of one
> particular forge or external project.  Patches and features must be
> of general benefit to the project at large.

> On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:
>> On 2024-02-01 at 18:36:48, Hans Meiser wrote:
> [snip]
>>> In 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/
>>
>> The Git project has tried for a long time to be neutral on any
>> particular external piece of software.  Installing a GitLab server as
>> our preferred development platform would promote GitLab as the preferred
>> forge to other users.  Similarly, moving to GitHub would prefer GitHub
>> over other forges.  That's not a thing we want to do.
>>
>> We also don't accept patches or features for the benefit of one
>> particular forge or external project.  Patches and features must be
>> of general benefit to the project at large.
> 
> I think this point is indeed really important in the context of the Git
> project.

> On 02/02/2024 05:10, Patrick Steinhardt wrote:
> > On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:
> > > On 2024-02-01 at 18:36:48, Hans Meiser wrote:
> > [snip]
> > > > In 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/
> > > 
> > > The Git project has tried for a long time to be neutral on any
> > > particular external piece of software.  Installing a GitLab server as
> > > our preferred development platform would promote GitLab as the preferred
> > > forge to other users.  Similarly, moving to GitHub would prefer GitHub
> > > over other forges.  That's not a thing we want to do.
> > > 
> > > We also don't accept patches or features for the benefit of one
> > > particular forge or external project.  Patches and features must be
> > > of general benefit to the project at large.
> > 
> > I think this point is indeed really important in the context of the Git
> > project.
> 
> Agreed, thank you for making it brian. If we did decide to use a forge we'd
> need to be very clear in our decision making that it was selected based on
> the specific needs of this project and was not a general endorsement of one
> product over another. We'd also need to address the important practical
> problems of finding resources to maintain the infrastructure and software to
> run it.

> Given the open nature of lore it should be feasible to provide
> additional interfaces on top of it that cater to people used to PRs
> on popular forge web UIs without hijacking the whole project and the
> existing tools and interfaces. For some reason people are set on
> replacing it as a whole, and removing the interfaces they personally
> don't use, calling them obosolete.
> 
> In a project with large numger of collaborators with varying 
> backgrounds
> that's not going to work well. There are many people working on git
> using different workflows, and adding support for new workflow by
> removing a number of existing ones will cause problems. The goal of
> changing the forge software should be to be more open, supporting more
> users with more varying workflows and needs, not less.

>Given the open nature of lore it should be feasible to provide
>additional interfaces on top of it that cater to people used to PRs
>on popular forge web UIs without hijacking the whole project and the
>existing tools and interfaces. For some reason people are set on
>replacing it as a whole, and removing the interfaces they personally
>don't use,

> On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:
>> Given the open nature of lore it should be feasible to provide
>> additional interfaces on top of it that cater to people used to PRs
>> on popular forge web UIs without hijacking the whole project and the
>> existing tools and interfaces. For some reason people are set on
>> replacing it as a whole, and removing the interfaces they personally
>> don't use,
> 
>> calling them obosolete.
>> 
> because they positively *are*.
> 
> when i started, patch-based code reviews were the norm, and i'm still
> using them for my small project with almost no external contributions.
> 
> 
> but after working with gerrit code review for over a decade, i find it
> mind-boggling that people are still voluntarily subjecting themselves
> to mail-based reviews for serious high-volume work.
> 
> it doesn't matter just how super-proficient you got with your old
> tools.  there is just no way you'll get anywhere near as efficient as
> you would with the new ones, if you just were interested enough to
> learn them.  migrating the workflows that are worth keeping isn't such
> a bit deal.

> i'll note that i don't consider github-like forges to be adequate
> tools for serious work, as they seem to intentionally discourage
> producing polished commits.
> the gerrit project is unfortunately not interested in building a
> proper forge, but luckily there is a bridge to github (hosted version
> available at gerrithub.io).

> On 2024-02-04 16:12, Oswald Buddenhagen wrote:
> > On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:
> > > Given the open nature of lore it should be feasible to provide
> > > additional interfaces on top of it that cater to people used to PRs
> > > on popular forge web UIs without hijacking the whole project and the
> > > existing tools and interfaces. For some reason people are set on
> > > replacing it as a whole, and removing the interfaces they personally
> > > don't use,
> > 
> > > calling them obosolete.
> > > 
> > because they positively *are*.
> > 
> > when i started, patch-based code reviews were the norm, and i'm still
> > using them for my small project with almost no external contributions.
> > 
> > 
> > but after working with gerrit code review for over a decade, i find it
> > mind-boggling that people are still voluntarily subjecting themselves
> > to mail-based reviews for serious high-volume work.
> > 
> > it doesn't matter just how super-proficient you got with your old
> > tools.  there is just no way you'll get anywhere near as efficient as
> > you would with the new ones, if you just were interested enough to
> > learn them.  migrating the workflows that are worth keeping isn't such
> > a bit deal.
> 
> Please, keep in mind that not everyone lives in a web browser and
> loves to click around.  Some people simply prefer to use the CLI
> utilities and to press the keys on their keyboards, and are very
> efficient while doing that.

> On Sun, Feb 04, 2024 at 04:28:58PM +0100, Dragan Simic wrote:
>> On 2024-02-04 16:12, Oswald Buddenhagen wrote:
>> > On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:
>> > > Given the open nature of lore it should be feasible to provide
>> > > additional interfaces on top of it that cater to people used to PRs
>> > > on popular forge web UIs without hijacking the whole project and the
>> > > existing tools and interfaces. For some reason people are set on
>> > > replacing it as a whole, and removing the interfaces they personally
>> > > don't use,
>> >
>> > > calling them obosolete.
>> > >
>> > because they positively *are*.
>> >
>> > when i started, patch-based code reviews were the norm, and i'm still
>> > using them for my small project with almost no external contributions.
>> >
>> >
>> > but after working with gerrit code review for over a decade, i find it
>> > mind-boggling that people are still voluntarily subjecting themselves
>> > to mail-based reviews for serious high-volume work.
>> >
>> > it doesn't matter just how super-proficient you got with your old
>> > tools.  there is just no way you'll get anywhere near as efficient as
>> > you would with the new ones, if you just were interested enough to
>> > learn them.  migrating the workflows that are worth keeping isn't such
>> > a bit deal.
>> 
>> Please, keep in mind that not everyone lives in a web browser and
>> loves to click around.  Some people simply prefer to use the CLI
>> utilities and to press the keys on their keyboards, and are very
>> efficient while doing that.
> 
> The forge vendors found out, and started to provide CLI tools. That's
> not really a general argument against forge software. Just as people
> living on web is not general argument against e-mail - it's been 
> brought
> to the web a long time ago.

> On Fri, Feb 02, 2024 at 12:50:04PM +0100, Michal Suchánek wrote:
> > Given the open nature of lore it should be feasible to provide
> > additional interfaces on top of it that cater to people used to PRs
> > on popular forge web UIs without hijacking the whole project and the
> > existing tools and interfaces. For some reason people are set on
> > replacing it as a whole, and removing the interfaces they personally
> > don't use,
> 
> > calling them obosolete.
> > 
> because they positively *are*.
> 
> when i started, patch-based code reviews were the norm, and i'm still using
> them for my small project with almost no external contributions.
> 
> but after working with gerrit code review for over a decade, i find it
> mind-boggling that people are still voluntarily subjecting themselves to
> mail-based reviews for serious high-volume work.

>On Sun, Feb 04, 2024 at 04:12:02PM +0100, Oswald Buddenhagen wrote:
>> but after working with gerrit code review for over a decade, i find
>> it
>> mind-boggling that people are still voluntarily subjecting themselves to
>> mail-based reviews for serious high-volume work.
>
>I have yet to see gerrit in action. Very few projects use it so it's
>difficult to gauge what tradeoffs compared to e-mail based workflow it
>does provide.
>

>> migrating the workflows that are worth keeping isn't such a bit deal.
>
>Have you migrated them to gerrit already, and t[a]ught all the git
>contributors how to use them from gerrit?
>

>Also can you migrate away from gerrit once it becomes defunct or new,
>better alternative emerges?
>
>Recently it seems that forges offer a 'download your project data'
>option, probably as a result of GDPR. What use is such data blob though?
>

>Compare that with the 'download your data' blob from a forge. Can it be
>uploaded even to a diffferent instance of the same forge to restore your
>project elsewhere? Interpreted by any tool othar than the correct
>vintage of that same forge? Deos even more than one instance of the
>forge exist?
>

>And even if you do convert to gerrit it's unlikely to satisfy the "Why
>are you not using github or gitlab" crowd. It's not one of the big,
>popular forges they are familiar with, the UX is significantly
>different.
>

> We've discussed moving to Markdown.  Unfortunately, while Markdown is
> great for HTML, it's pretty terrible for things that are not HTML.
> Certainly there are tools that convert Markdown to other formats, but
> I'm not aware of any single tool (outside of Pandoc[0]) that does so into
> all the formats we offer, including HTML, PDF, Texinfo, and manual
> pages.  Markdown also comes in a large variety of variants and writing
> documentation to please any substantial number of tools is very
> difficult.

> 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.

>Hans Meiser <brille1@hotmail.com> writes:
>
>> Hi,
>>
>> is there any current discussion about moving Git development away from
>> using a mailing list to some modern form of collaboration?
>
>Yes, now there is (again).
>
>> 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.
>
>Did you consider to rather read the list through gmane.comp.version-control.git
>nntp newsgroup?
>
>This way you get only very specific mails in your mail-box, those where you are
>explicitly CC'ed, and you usually get more support for structuring from NNTP
>readers than from mail clients.

> >
> >Did you consider to rather read the list through
> >gmane.comp.version-control.git nntp newsgroup?
> >
> >This way you get only very specific mails in your mail-box, those
> >where you are explicitly CC'ed, and you usually get more support
> >for structuring from NNTP readers than from mail clients.
> 
> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
> that idea, but it has a limited lifespan.

> On Fri, Feb 02, 2024 at 10:22:18AM -0500, rsbecker@nexbridge.com wrote:
> > >
> > >Did you consider to rather read the list through
> > >gmane.comp.version-control.git nntp newsgroup?
> > >
> > >This way you get only very specific mails in your mail-box, those
> > >where you are explicitly CC'ed, and you usually get more support
> > >for structuring from NNTP readers than from mail clients.
> > 
> > Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
> > that idea, but it has a limited lifespan.
> 
> Google might be dropping Usenix NNTP updates, but news.gmaine.io and
> nntp.lore.kernel.org are not not run by Google.  So whether or not
> Google groups are supporting NNTP is not really supporting.
> 
> One other thing I would note that is that if someone isn't interested
> in following most of the git mailing list, it's unclear how much they
> can actually contribute.  Maybe they could fix spelling or grammer
> issues in the git man pages, but it's unlikely they could actually
> make code contributions.
> 
> So from an open source project perspective, which is primarily run by
> volunteers, each open source project has to make a cost-benefit
> tradeoff as far as the *project* is concerned.  Individuals do not
> have a fundamental human right to contribute to a project.  Hence, the
> open source project doesn't owe an obligation to spend a huge amount
> of effort supporting some kind of forge web site just because some
> potential contributors are clammoring for it.  Especially if they are
> saying that they can't be bothered to follow the mailing list traffic
> because it's somehow too much.

> So from an open source project perspective, which is primarily run by
> volunteers, each open source project has to make a cost-benefit
> tradeoff as far as the *project* is concerned.  Individuals do not
> have a fundamental human right to contribute to a project.  Hence, the
> open source project doesn't owe an obligation to spend a huge amount
> of effort supporting some kind of forge web site just because some
> potential contributors are clammoring for it.  Especially if they are
> saying that they can't be bothered to follow the mailing list traffic
> because it's somehow too much.

> (Of course, I have all of the Linux kernel mailing list flowing into
> my inbox, and have e-mail practices that can handle that load --- so
> it's hard for me to have much sympathy about people complaining that
> the e-mail load for git is too large --- compared to LKML, it's
> *nothing*.  :-)

> "Theodore Ts'o" <tytso@mit.edu> writes:
> 
> > So from an open source project perspective, which is primarily run by
> > volunteers, each open source project has to make a cost-benefit
> > tradeoff as far as the *project* is concerned.  Individuals do not
> > have a fundamental human right to contribute to a project.  Hence, the
> > open source project doesn't owe an obligation to spend a huge amount
> > of effort supporting some kind of forge web site just because some
> > potential contributors are clammoring for it.  Especially if they are
> > saying that they can't be bothered to follow the mailing list traffic
> > because it's somehow too much.
> 
> Thanks for saying this (even though with my Devil's advocate hat on,
> I am not sure how strong our "this is run by volunteers, so do not
> demand" card is these days).

> As a Linux kernel subsystem maintainer, I am super grateful for those
> who do code reviews and those who work test regressions, because in
> general, that which doesn't get done by other developers ends up
> getting done by the maintainers and project leads if it's going to
> happen at all.
> 
> When it comes to requests like "you should migrate the project to use
> some forge web site, because we can't be bothered to use e-mail, and
> web interfaces are the new hotness", the entitlement that comes from
> that request (which is in the subject line of this thread), can
> sometimes be a bit frustrating.
> 
> Going back to the original topic of this thread, my personal
> experience has been that the *vest* percentage of pull requests that I
> get from github tend to be drive-by pull requests that are very low
> quality, especially compared to those that I get via the mailing list.
> So making a change to use a forge which might result in a larger
> number of lower quality code contributions, when code review bandwidth
> might be more of a bottlenck, might not be as appealing as some might
> think.

>> Please, keep in mind that not everyone lives in a web browser and
>> loves to click around.  Some people simply prefer to use the CLI
>> utilities and to press the keys on their keyboards, and are very
>> efficient while doing that.
> 
> You 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?

>> As a Linux kernel subsystem maintainer, I am super grateful for those
>> who do code reviews and those who work test regressions, because in
>> general, that which doesn't get done by other developers ends up
>> getting done by the maintainers and project leads if it's going to
>> happen at all.
>> 
>> When it comes to requests like "you should migrate the project to use
>> some forge web site, because we can't be bothered to use e-mail, and
>> web interfaces are the new hotness", the entitlement that comes from
>> that request (which is in the subject line of this thread), can
>> sometimes be a bit frustrating.
>> 
>> Going back to the original topic of this thread, my personal
>> experience has been that the *vest* percentage of pull requests that I
>> get from github tend to be drive-by pull requests that are very low
>> quality, especially compared to those that I get via the mailing list.
>> So making a change to use a forge which might result in a larger
>> number of lower quality code contributions, when code review bandwidth
>> might be more of a bottlenck, might not be as appealing as some might
>> think.
> 
> Again, 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)
> 
> Using 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.

> With 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.

> I'm getting the impression that you didn't yet seriously investigate
> on the features these Git collaboration websites provide.
> 
> Let 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.

>>Did you consider to rather read the list through gmane.comp.version-control.git
>>nntp newsgroup?
>>
>>This way you get only very specific mails in your mail-box, those where you are
>>explicitly CC'ed, and you usually get more support for structuring from NNTP
>>readers than from mail clients.
>
> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would
> love that idea, but it has a limited lifespan.

><rsbecker@nexbridge.com> writes:
>
>>>Did you consider to rather read the list through
>>>gmane.comp.version-control.git nntp newsgroup?
>>>
>>>This way you get only very specific mails in your mail-box, those
>>>where you are explicitly CC'ed, and you usually get more support for
>>>structuring from NNTP readers than from mail clients.
>>
>> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
>> that idea, but it has a limited lifespan.
>
>You do not have to read NNTP newsgroup via Google Groups, which has, but

>To: rsbecker@nexbridge.com
>Cc: git@vger.kernel.org
>Subject: Re: Migrate away from vger to GitHub or (on-premise) GitLab?
><rsbecker@nexbridge.com> writes:
>
>> I should have qualified this with "free" NNTP. I have only been able
>> to find for fee NNTP servers where I am. The search continues.
>
>The NNTP server "nntp.lore.kernel.org" carries the mailing list served by
>lore.kernel.org archives, including this list.