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

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

[Hans Meiser]

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

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

[Antonin Delpeuch]

Hi Hans,

As a new contributor I have also been wondering about that and I found
the notes of the 2023 contributor summit very interesting in this regard:

https://docs.google.com/document/d/1GKoYtVhpdr_N2BAonYsxVTpPToP1CgCS9um0K7Gx9gQ/edit#heading=h.bdw77tvsksnr

There is a section on "Project management practices" which touches on
this topic, with the idea of using a bug tracker being raised for
instance. So you are not the only one thinking about it at least.

For what it's worth, I have written up a small report about my
contribution experience (which covers project management practices):

https://antonin.delpeuch.eu/posts/contribution-experience-report-git/

Best,

Antonin

On 01/02/2024 13:10, Hans Meiser wrote:
> 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

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

[Kristoffer Haugsbakk]

Hi

On Thu, Feb 1, 2024, at 13:10, Hans Meiser wrote:
> Hi,
>
> Regards,
> Axel Dahmen

A relevant discussion seems to be “Improving new contrib onboarding”[1]

There’s GitGitGadget for people who want to use GitHub as a bridge[2]

There’s an unofficial issue tracker for project ideas (not for bugs)[3]

That’s what I know.

🔗 1: https://lore.kernel.org/git/ZRrgMDacYpj41DcO@nand.local/
🔗 2: https://gitgitgadget.github.io/
🔗 3: https://github.com/gitgitgadget/git/issues

-- 
Kristoffer Haugsbakk

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

[Dragan Simic]

Hello,

On 2024-02-01 13:10, 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.
> 
> Are you consideration for migrating?

Perhaps it would be good to also know that many people simply don't
live in a web browser, so to speak, and live in the CLI instead.  For
such people, having to use a web browser for development is simply,
well, awkward and inefficient.

In other words, as much as not using some more modern, web-based
tools may drive some people away, there's also exactly the opposite
reaction that should also be considered.

There was recently some similar discussion for another open-source
project, but I simply can't find it now. :/

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

[Konstantin Ryabitsev]

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.

Best regards,
-K

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

[Dragan Simic]

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.

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

[Dragan Simic]

On 2024-02-01 17:54, Dragan Simic wrote:
> 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.

s/your time/the time/

Sorry for the noise.

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

[Hans Meiser]

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.

Cheers,
AxelD

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

[Hans Meiser]

Hi Kristoffer,

thanks for sharing these very helpful links to GitGitGadget! Love it!

Best regards,
AxelD

--
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Sent: Thursday, February 1, 2024 13:21
To: Hans Meiser <brille1@hotmail.com>
Cc: git@vger.kernel.org <git@vger.kernel.org>
Subject: Re: Migrate away from vger to GitHub or (on-premise) GitLab?
 
Hi

On Thu, Feb 1, 2024, at 13:10, Hans Meiser wrote:
> Hi,
>
> Regards,
> Axel Dahmen

A relevant discussion seems to be “Improving new contrib onboarding”[1]

There’s GitGitGadget for people who want to use GitHub as a bridge[2]

There’s an unofficial issue tracker for project ideas (not for bugs)[3]

That’s what I know.

🔗 1: https://lore.kernel.org/git/ZRrgMDacYpj41DcO@nand.local/
🔗 2: https://gitgitgadget.github.io/
🔗 3: https://github.com/gitgitgadget/git/issues

--
Kristoffer Haugsbakk

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

[Kristoffer Haugsbakk]

(Disclaimer that I’m relatively inexperienced with this project
workflow)

My impression is that the email workflow is very flexible and
tool-agnostic.[1] On the other hand it’s hard to get set up in a way
that makes contributing to a project as easy as contributing to a
project that is hosted on GitHub.[2]

† 1: Konstantin’s reply here seems to confirm this. And thanks by the
    way for all your emails on this workflow subject, which I always
    enjoy reading. And for your work on tooling that of course other
    email-based projects than Linux can use.
† 2: With the assumption that you already have an account there

What would really “sell” the email workflow would be to have some sort
of program which can set everything up for you so that you can track
your contributions as easily as a PR on GitHub. Of course people use all
kinds of different platforms, but let’s say that it only was for the
latest Mac OS (this is all hypothetical anyway). All you would need to
do was to give your email credentials and whatever other technical email
things that are required. Just install one program and track all your
patches as well as the replies on them. More concretely: maybe it would
have an email client which would make sure that all your outgoing emails
are done correctly. Including things like not mangling patches in your
reply because of hard-wrapping or something. (I created a support ticket
for that on Fastmail yesterday.) Or: let you immediately inline a
“scissor lines” patch into your current message based on a commit or
just your current working tree.[3]

Also: never having to copy–paste message ids manually. :)

(Again, all hypothetical for the sake of the argument)

This program could be very opinionated and dictate a very rigid
workflow; the point would be that there *is* a way to have a setup which
is as easy as GitHub (modulo email credentials/technical
things). Because then if you want to customize your workflow you are
still totally free to put together your own tools just like what
apparently many people do right now.

If this was even just hypothetically possible—I dunno—then that would be
a strong argument in favor of this kind of project workflow.

I think that would be the best of both worlds.

† 3: That also sounds more convenient than pushing to a GitHub repo. in
    order to make a PR

-- 
Kristoffer Haugsbakk

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

[Nico Williams]

On Thu, Feb 01, 2024 at 10:39:04AM -0500, Konstantin Ryabitsev wrote:
> [excellent discussion of e-mail workflows elided]

It would surely help if the e-mail interfaces of forges were not
terrible.  But they really have to be as good as the mailing list
approach.

I envision that the "issues" and "PRs" could be webmail-ish thread
trackers that auto-close on prolonged silence.  One could open issues/
PRs by e-mail, close them by e-mail, etc., all e-mails going to the same
[forge-run?] list address, but still have a forge-style view of a PR's
commits, still have a forge-style code review web UI (with all comments
going to e-mail too, and with e-mail being first-class, not an
afterthought), still have a CI checks UI, and still have a big
rebase-and-merge button for maintainers.

I.e., forge e-mail UI as first-class equivalent of forge web UI.

The forges tend to be run by people who prioritize users who are not
heavy e-mail workflow devs.  It makes economic sense, given how few
users demand e-mail as a first-class forge UI.  Still, it would be quite
awesome if some forge did this.

> - How to avoid a vendor lock-in? [...]

Assuming some forge exists with an e-mail UI on the same footing as its
web UI, and also good enough for kernel/git/... devs, you could maintain
mirrors on all the other forges, naturally, and always fallback on
e-mail only if the primary forge disappears or becomes too expensive.

> - How to avoid centralization and single points of failure? [...]

It's all forks, all the time.  It'd be good if the kernel maintainers
maintained non-forge git servers as mirror/staging/primary repos.

> - How to avoid alienating these hundreds of key maintainers who are now
>   extremely proficient at their query-based workflows? [...]

The only answer is to stick to the current workflow until some forge
provide an equivalently first-class e-mail interface.  New participants
just have to get used to it.  IMO.

Nico
-- 

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

[Dragan Simic]

On 2024-02-01 18:28, Hans Meiser wrote:
> 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?

Of course it isn't.

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

Could you, please, clarify what kind of git documentation are you
referring to?  Are you having git man pages in mind?

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

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.

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

[Hans Meiser]

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

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

[Dragan Simic]

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.

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

[rsbecker]

On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:
>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.

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.

--Randall

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

[Dragan Simic]

On 2024-02-01 21:01, rsbecker@nexbridge.com wrote:
> 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.

Good point, I agree that the value of the discussions on the mailing
list is extremely high.  We should also keep in mind that the risk of
a vendor lock-in is even higher when it comes to the discussions.

Frankly, the resilience of email as a service and the openness of its
format can hardly be beaten.

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

On 2024-02-01 at 18:36:48, 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.

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.

AsciiDoc supports converting into all of those things either directly or
through DocBook, and it's flexible enough to allow a decent amount of
customization, which we take advantage of.  It also has relatively
little variation.  Both of these are part of the reason that Git LFS
moved from Markdown to AsciiDoc.

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

Yes, and that would be someone at kernel.org, which is a nonprofit.
Maintaining a busy Git server takes server resources and sufficient
staffing to ensure that things work properly and that problems are
resolved in a timely manner.  It also comes with potential security
risks.  The mail-based approach will likely remain for the Linux kernel,
so someone will have to maintain this in addition.  Are you offering to
provide long-term funding to kernel.org to provide the necessary
resources and staffing?

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

[0] Pandoc is built in Haskell using GHC, which has decent architecture
support, but quite poor OS support outside of the most common platforms.
Relying on it would be a serious regression in terms of documentation
support.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

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. It's a rather unique limitation that no other project out there
will really have. I don't think this has to completely rule out the use
of a forge. But in my opinion it completely rules out any forge that is
run by a for-profit company and that isn't completely open source. So
GitLab, GitHub and Bitbucket are not really an option in my opinion.

That still leaves other forges like SourceHut, Gogs or Forgejo. But the
benefit becomes at least a bit more questionable as the barrier for
entry is again higher in that context -- after all most people only know
about the large forges out there, and creating a new account raises the
bar.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Hans Meiser]

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

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

[Hans Meiser]

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

I 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?

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

[Hans Meiser]

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

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

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

Moreover, Markdown commonly accepts a restricted set of HTML tags, so you may even extend Markdown inline for anything fancy.

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

[Hans Meiser]

> Actually, there a plenty of converters out there converting Markdown to anything.

You may even want to convert Markdown to AsciiDoc:
https://matthewsetter.com/technical-documentation/asciidoc/convert-markdown-to-asciidoc-with-kramdoc/

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

[Dragan Simic]

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.

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

[Phillip Wood]

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.

Best Wishes

Phillip

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

[Dragan Simic]

On 2024-02-02 12:07, Phillip Wood wrote:
> 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.

Sure, but there has to be someone with intimate knowledge of the git
source code in the entire chain, if you agree, to make sure that 
improving
the readability or style doesn't diverge the man pages from the truth.

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

[Phillip Wood]

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.

Best Wishes

Phillip

Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?)

[Dragan Simic]

Hello everyone,

I went ahead and contacted the mlmmj project, which runs the vger 
mailing
lists, [1] with an idea to implement a new command/feature that allows
threads to be muted or unmuted.  For example, that would allow receiving
only the replies to one's patch that was sent to a list.

The initial reactions are good, but various concerns have been raised
regarding the actual implementation.  I'll think about the way to 
implement
it in an efficient and simple way.  I think this would make using 
mailing
lists much more friendly to many users.

All suggestions and thoughts are welcome, of course.

[1] https://people.kernel.org/monsieuricon/subspace-mailing-list-server


On 2024-02-02 11:54, Dragan Simic wrote:
> 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.

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

[Michal Suchánek]

Hello,

On Fri, Feb 02, 2024 at 11:15:26AM +0000, Phillip Wood wrote:
> 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.

In this context using lore is basically also a forge choice. It is built
on top of git, and expands the functionality of what the project git
repository alone provides.

Unlike most other forge software it is based completely on open
standards such as e-mail headers and git itself, very open and modular,
and does not in any way tie the project git repository to this
additional functionality provided by lore.

This open and separate nature of lore is what makes it the tool of
choice for Linux and git, and any forge that aims to replace lore should
aim at similar level of openness. Of the forges I am aware of only
sourcehut comes close in terms of planned functionality but it's nowhere
near completed as far as I am aware.

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.

Thanks

Michal

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

[Dragan Simic]

On 2024-02-02 12:50, 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.
> 
> 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.

Totally agreed.  Augmenting the traditional interfaces and workflows,
instead of declaring them obsolete and killing them, should be the way
to go.  Having different options available is always good.

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

[Sergey Organov]

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.

HTH

-- 
Sergey Organov

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

[rsbecker]

On Friday, February 2, 2024 9:49 AM, Sergey Organov wrote:
>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.

Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love that idea, but it has a limited lifespan.

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

[Theodore Ts'o]

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.

(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*.  :-)

						- Ted

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

[Junio C Hamano]

<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 will be ending, support to gateway between them.  The suggestion
was to read these articles over NNTP instead of subscribing to the
list, which does not involve anything Google would (or wouldn't) do.

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

[rsbecker]

On Friday, February 2, 2024 11:42 AM, Junio C Hamano wrote:
><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
will be
>ending, support to gateway between them.  The suggestion was to read these
>articles over NNTP instead of subscribing to the list, which does not
involve
>anything Google would (or wouldn't) do.

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.

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

[Michal Suchánek]

On Fri, Feb 02, 2024 at 11:16:43AM -0500, Theodore Ts'o wrote:
> 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.

That's not to say that the mailing list traffic cannot be wrapped in
another interface if somebody has the motivation and spends the effort
to do it.

For example, there used to be (and maybe still is) a bidirectional
gateway that bridged the ruby-talk mailing list into a web forum that was
run by a person who thought it's a good idea, and resolved the problems
that came out of it.

e-mails have pretty good 1:! correspondence to forum posts or forge PR
comments. Some features like post edits or emoji reactions do not
translate, and cannot be provided with e-mail backend.

However, presenting the mailing list through a different interface, and
hosting the application doing the translation is a work that the person
suggesting the change would have to do, or hire someone to do for them,
rather than coming and saying 'Throw away all the tools you have now,
and install and run this thing instead to make it easy for me'.

Thanks

Michal

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

[Junio C Hamano]

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

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

[rsbecker]

On Friday, February 2, 2024 12:40 PM, Junio wrote:
>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.

Thanks. This is sufficient for git. Appreciate it.

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

[Junio C Hamano]

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

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

True.  It is even possible to:

 - have a group of document nitpickers, whose charter is to improve
   the documentation by fixing spelling and grammar mistakes and
   mark-up mistakes, while making sure that what the original wanted
   to say is still what the updated version says.

 - have a gatekeeper who makes sure that the output from the above
   group is within the scope of its charter, before it is merged to
   the main tree.

Then, the choice of the collaboration medium among "document
nitpickers" can be delegated to the group, as long as the quality of
their output is tightly controlled by the gatekeeper to meet the bar
of the main tree.  The resulting history should be consistent with
the rest of the system when seen in "git shortlog" output, for
example.

The above is quite similar to how the l10n team works.  There is a
l10n coordinator who acts as the gatekeeper for po/ hierarchy, and
l10n folks coordinate among themselves without much supervision and
review of their output on the list.  We can treat the documentation
work that does not involve any knowledge of what the documentation
describes the same way.

Thanks.

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

[Junio C Hamano]

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

> (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*.  :-)

True, too.  We may have enough patch traffic but not enough reviews
on them.

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

[Theodore Ts'o]

On Fri, Feb 02, 2024 at 11:04:41AM -0800, Junio C Hamano wrote:
> "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).

Even though a lot of open source developers these days work for
companies, it's rare that engineers get to work on whatever they want.
More often than not, open source developeres are asked to primarily
work on features that have a tie to their employer's business goals.
Different companies might call use different corporate-speak; for
example, perhaps on e company might use "year of efficiency" or
"sharpening our focus", but the reality is that companies are asking
engineers to spend more time of features that those companies want.

What this tends to mean is that engineers have less time to do
community work --- such as code reviews --- or they have to do that
work "on their own time", e.g., late at night or on weekends.  Those
of us who work as project leads, or subsystem leads for open source
projects, are trying to push back against this dynamic, because there
is always maintenance work that need to be done to keep the project
healthy, including bug scrubbing, code review, improving tests, etc.

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.

					- Ted

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

[Oswald Buddenhagen]

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

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

[Dragan Simic]

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.

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

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

[Michal Suchánek]

On Sun, Feb 04, 2024 at 04:12:02PM +0100, 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.

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.

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

Have you migrated them to gerrit already, and tought all the git
contributors how to use them from gerrit?

Somobody has to do it.

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?

An e-mail archive is that: an archive. It's a medium that you can read
with a wealth of software today, and 100 years from now. An achivable
data format.

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?

I have seen what hoops Gitea is jumping through to import data from
other forges, and it's not pretty.  Understandably, people who have seen
rise and fall of bitkeeper are wary of any tool that keeps your data
locked to itself.

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.

Thanks

Michal

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

[Michal Suchánek]

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.

Thanks

Micchal

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

[Dragan Simic]

On 2024-02-04 16:51, Michal Suchánek wrote:
> 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.

Please, don't get me wrong, I'm not against the GUI and web-based
utilities in the sense of telling other people they're bad or shouldn't
be used.  I love the variety and the freedom of choice, so everyone
can freely choose the most suitable option for them.

Though, I'd also expect that everyone respect different choices made
by other people.  That's how we keep the variety available.

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

[Oswald Buddenhagen]

On Sun, Feb 04, 2024 at 04:47:14PM +0100, Michal Suchánek wrote:
>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.
>
from my just slightly biased perspective ;-) i can't see any significant
trade-offs except for some set-up cost (that will quickly pay for
itself).

in fact, my gerrit workflow is still "e-mail based", in that everything
is driven by the notification mails, only that i "branch out" to the
browser whenever something interesting happens.

for the CLI hardliners there are gertty and emacs egerrit, but i see no
point in using either despite being a heavy CLI and TUI user. given how
"much" attention these tools get despite there being literally tens of
thousands of regular gerrit users, i'm inclined to think that there is
indeed very little demand.

gerrit also has an incoming email gateway, but i'm not sure how advanced
it is - at some point it required well-formed html replies as input.

if one really wants to, one can install a webhook or event stream
watcher that posts all activity to a mailing list (and i don't mean
_the_ list, because it would be just noise on top of everyone's
individual notifications).

>> 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?
>
that challenge is sort of meaningless, because the only workflow within
the git project that i'm aware of that would affect "all the git
contributors" is the interaction with gerrit itself. which has a very
steep, but also extremely short learning curve. and there are tools to
meke it more pleasant - https://wiki.qt.io/Git-gpush-scripts (yep,
shameless self-promotion here).

i'm not aware of any pre-integration build bots, so nothing to do on
that front except for some mirroring adjustments (gerrit insists on
being its own authoritative git server).

gitgitgadget would just become obsolete, to be replaced by the github
integration plugin.

my main concern is with the maintainer workflow:

the way gerrit is usually used, the contributor determines the target
branch, and the changes are merged directly to it after they are
approved. unclean merges must also be eliminated during review. that
works just fine, but it doesn't match the refs and merge commit messages
junio produces. and while aggregating pending changes into `seen` would
be still perfectly possible (each change including its dependencies is
just a ref), it would be somewhat awkward due to the naming and location
of the change refs.

to reproduce the existing merge workflow more faithfully,
- junio would have to monitor incoming changes, manually create an empty
   branches for each topic, and change the target branch of all changes
   in each topic
- the gerrit-side integration would then happen into that branch
- junio would then proceed with manually merging the branch and
   direct-pushing (that is, not creating a review for it) the merge into
   next or maint
this is reallly just the current workflow, and can be equally automated,
just with slightly different tooling. only it's ... weird for gerrit,
artificially creating a bottleneck. the gerrit integration workflow is
naturally decentralized.

personally, i would just switch to the usual gerrit workflow, and at
least for `seen` use a merge-free workflow -- with gpick (gpush
complement, see link above) it's absolutely trivial to track all
interesting branches stacked onto each other.

>Somobody has to do it.
>
yes. and if nobody does, then everybody keeps paying the cost of not
doing it. that might incentivize Somebody (TM) with the resources and a
vested interest.

>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?
>
current gerrit keeps the meta data in (yet more) awkwardly named refs
containing plain-text files, so that's no issue. one could render it
into a read-only view, or convert it.

>An e-mail archive is that: an archive. It's a medium that you can read
>with a wealth of software today, and 100 years from now. An achivable
>data format.
>
with a mailing list archiving the event stream, we'd have that.

>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?
>
a review meta-data standard is being discussed from time to time, but it
hasn't gone anywhere yet.

but looking at it from a practical perspective, with a list-based
archive the situation wouldn't be any worse than it is right now if
gerrit was to suddenly disappear.

during my tenure at the qt project i established a commit policy (and
deployed tooling to help enforce it) that presumes that gerrit could be
replaced at any time, so commit messages are not supposed to refer to
other commits by gerrit change ids or review urls. (in principle, this
works even for pending and abandoned changes, as each patchset (revision
of a change) keeps its commit and therefore sha1 forever.)
of course that's not practical for regular mailing list posts, but one
can't have everything ...

>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.
>
i can confirm that in the qt project this is indeed absolutely the case,
and the last related thread isn't even cold yet.
but why should the people with standards care? lowering the barrier to
entry is all dandy, but not when it causes significant detriment to the
workflow of those who do most work.
note that the original request in this thread was for "structured
discussion", and gerrit would absolutely provide that, among other
things.

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

[Hans Meiser]

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

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

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.

Cheers,
Axel

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

[Dragan Simic]

Hello Hans,

On 2024-02-06 08:22, Hans Meiser wrote:
>> 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?

Perhaps I wasn't clear enough, so please allow me to clarify a bit.

To me, it isn't just about using the CLI or TUI utilities.  It's
actually about using standard CLI/TUI utilities, such as using git
directly, instead of using some specialized CLI/TUI utilities that
are made to interact with a forge in a forge-specific way.

Perhaps you'll ask why I find using a forge such a bad thing, so
I'll try to provide an answer in advance.

Git is a widespread, standard system of utilities that isn't backed
by some company that sees its profit as the main goal.  On the other
hand, most forges are backed by a company, and as we know, companies
don't last forever, and they often pivot due to business decisions.
What we don't want is to tie the project into something that isn't
expected to virtually last forever.

It's similar to the concept of bit rot.  A lot of data is poured
into something and it slowly starts to degrade over time.  Though,
in the case of a forge becoming no longer available it wouldn't be
a gradual decay, but an abrupt disruption that would make all the
data unavailable and unusable.  Of course, the data perhaps can be
exported from a forge in some format, including the discussions,
but who's going to sift through years worth of such data and make
it usable through some other interface or in some other format?
Frankly, I wouldn't see that happening.

On the other hand, discussion in form of mailing lists aren't tied
to anything, the underlying data format has been around for decades,
and the raw data can be accessed by any editor or viewer, such as
less(1).  It isn't tied to anything.

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

I don't remember such cases.  It doesn't mean something like that will
never happen, though.  Also, pretty much anyone can create dozens of
fake accounts on a forge and do malicious things.

Please note that creating an account of any kind is often unacceptable
to many people.  I was a bit surprised to discover that.

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

You must be having bad luck for some reason.  Knocking on wood,
I've received zero spam emails directed to my email address since
subscribing to the list.

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

If you ask me, one's identity shouldn't be hidden when one willingly
contributes to a public project.  Taking part in the discussions is
also a way of contributing.

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

As I noted already, these days it's expected too much that some
utilities will do the programmer's work.  Also, being unable to
follow a moderately busy mailing list, such as the git's, may also
show that one needs to improve their own skills in some areas.

In the case of high-volume mailing lists, I admit that things can
be different and much harder to handle.  That's why I plan to work
on extending mlmmj to support muting and unmuting threads. [1]

[1] 
https://lore.kernel.org/git/93be64af474b228e914a4c39443b5a9c@manjaro.org/