git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Theodore Ts'o <tytso@mit.edu>
Date
Feb 2, 2024, 21:28 UTC
Message-ID
<20240202212809.GA36616@mit.edu>
In-Reply-To
<xmqq5xz6sn5i.fsf@gitster.g>
On Fri, Feb 02, 2024 at 11:04:41AM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> "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
Previous: Junio C HamanoNext: Hans Meiser
Message 42 of 48 in “Migrate away from vger to GitHub or (on-premise) GitLab?”
  1. Hans MeiserFeb 1, 2024
  2. Kristoffer HaugsbakkFeb 1, 2024
  3. Hans MeiserFeb 1, 2024
  4. Antonin DelpeuchFeb 1, 2024
  5. Dragan SimicFeb 1, 2024
  6. Konstantin RyabitsevFeb 1, 2024
  7. Dragan SimicFeb 1, 2024
  8. Dragan SimicFeb 1, 2024
  9. Hans MeiserFeb 1, 2024
  10. Dragan SimicFeb 1, 2024
  11. Hans MeiserFeb 1, 2024
  12. Dragan SimicFeb 1, 2024
  13. rsbecker@nexbridge.comFeb 1, 2024
  14. Dragan SimicFeb 1, 2024
  15. Hans MeiserFeb 2, 2024
  16. Hans MeiserFeb 2, 2024
  17. Dragan SimicFeb 2, 2024
  18. Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?)Dragan Simic, Feb 2, 2024
  19. Phillip WoodFeb 2, 2024
  20. Dragan SimicFeb 2, 2024
  21. Junio C HamanoFeb 2, 2024
  22. brian m. carlsonFeb 2, 2024
  23. Patrick SteinhardtFeb 2, 2024
  24. Phillip WoodFeb 2, 2024
  25. Michal SuchánekFeb 2, 2024
  26. Dragan SimicFeb 2, 2024
  27. Oswald BuddenhagenFeb 4, 2024
  28. Dragan SimicFeb 4, 2024
  29. Michal SuchánekFeb 4, 2024
  30. Dragan SimicFeb 4, 2024
  31. Michal SuchánekFeb 4, 2024
  32. Oswald BuddenhagenFeb 5, 2024
  33. Hans MeiserFeb 2, 2024
  34. Hans MeiserFeb 2, 2024
  35. Nico WilliamsFeb 1, 2024
  36. Kristoffer HaugsbakkFeb 1, 2024
  37. Sergey OrganovFeb 2, 2024
  38. rsbecker@nexbridge.comFeb 2, 2024
  39. Theodore Ts'oFeb 2, 2024
  40. Michal SuchánekFeb 2, 2024
  41. Junio C HamanoFeb 2, 2024
  42. Theodore Ts'oFeb 2, 2024
  43. Hans MeiserFeb 6, 2024
  44. Dragan SimicFeb 6, 2024
  45. Junio C HamanoFeb 2, 2024
  46. rsbecker@nexbridge.comFeb 2, 2024
  47. Junio C HamanoFeb 2, 2024
  48. rsbecker@nexbridge.comFeb 2, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.