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

Re: Our cumbersome mailing list workflow

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Nov 28, 2014, 15:34 UTC
Message-ID
<547895F1.1010307@alum.mit.edu>
In-Reply-To
<20141127225334.GA29203@dcvr.yhbt.net>
On 11/27/2014 11:53 PM, Eric Wong wrote:
Show 11 quoted lines
> Torsten Bögershausen <tboegi@web.de> wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>>> [...]
>> In short:
>> We can ask every contributor, if the patch send to the mailing list
>> is available on a public Git-repo, and what the branch name is,
>> like _V2.. Does this makes sense ?
> 
> Not unreasonable.  I hope that won't give folks an excuse to refuse
> to mail patches, though.  Some folks read email offline and can't
> fetch repos until they're online again.

My ideal would be to invert the procedure. Let the patches in a public Git repository somewhere be the primary artifact, and let the review process be focused there. Let email be an alternative interface to the central review site:

* Generate patch emails (similar to the current format) when pull
requests are submitted.
* Generate notification emails when people comment on the patches.
* Allow people to respond to the patch and notification emails via
email. The central review site should associate those comments with the
patches that they apply to, and present them along with other review
comments received via other interfaces.
Show 7 quoted lines
>> I like Gerrit as well.
>> But it is less efficient to use, a WEB browser is slower (often), and
>> you need to use the mouse...
> 
> IMNSHO, development of non-graphical software should never depend on
> graphical software.  Also, I guess there is no way to comment on Gerrit
> via email (without registration/logins?).

The days of the vt52 are over. I'm an old neckbeard myself and have used *real* vt52s. But these days even my *cellphone* is able to handle the GitHub website [1]. Rejecting modern technology is not intrinsically virtuous; it only makes sense if the old technology is really superior. And it is not enough for it to be superior only for neckbeards; it should be superior when averaged over all of the people whose participation we would like to have in the Git project.

And by the way, there are text-only clients for interacting with GitHub [1].
> Lately, I've been trying to think of ways to make collaboration less
> centralized.  Moving to more centralized collaboration tools is a step
> back for decentralized VCS.

If an efficient decentralized collaboration system existed, then I'd love to give it a chance. But as far as I know, the existing systems are all embryonic.

Don't forget that even our current system is centralized to some extent. There is a single mailing list through which all emails pass. There are a few email archives that we de facto rely on (and it is a brittle dependency--if Gmane were to disappear, we would have an awful lot of broken URLs in our emails that would be impossible to fix).

It seems like a few desirable features are being talked about here, and summarizing the discussion as "centralized" vs "decentralized" is too simplistic. What is really important?

1. Convenient and efficient, including for newcomers
2. Usable while offline
3. Usable in pure-text mode
4. Decentralized
Something else?

In my opinion, a central system with good Git integration (helps with 1) and both a straightforward web UI (also helps 1) and a good email interface (which gives both 2 and 3) and the ability to export the review history (which avoids lockin, the most important aspect of 4) would be perfect. Is there such a thing?

Michael

[1] ...probably other websites too. I'm really not trying to flog GitHub here; it's just the one I have the most experience with. In fact, I kindof assume that the Git project would choose a service that is itself based on open-source software.

-- 
Michael Haggerty
mhagger@alum.mit.edu
Previous: Eric WongNext: brian m. carlson
Message 50 of 61 in “refs.c: use a stringlist for repack_without_refs”
  1. refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 18, 2014
  2. Junio C HamanoNov 18, 2014
  3. Junio C HamanoNov 18, 2014
  4. Jonathan NiederNov 18, 2014
  5. Stefan BellerNov 19, 2014
  6. refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 19, 2014
  7. Junio C HamanoNov 19, 2014
  8. refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 19, 2014
  9. Jonathan NiederNov 19, 2014
  10. refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 19, 2014
  11. refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 19, 2014
  12. Jonathan NiederNov 20, 2014
  13. Junio C HamanoNov 20, 2014
  14. 1/1 refs.c: use a stringlist for repack_without_refsStefan Beller, Nov 20, 2014
  15. refs.c: repack_without_refs may be called without error string bufferStefan Beller, Nov 20, 2014
  16. Ronnie SahlbergNov 20, 2014
  17. Jonathan NiederNov 20, 2014
  18. Ronnie SahlbergNov 20, 2014
  19. Stefan BellerNov 20, 2014
  20. Jonathan NiederNov 20, 2014
  21. Jonathan NiederNov 20, 2014
  22. Junio C HamanoNov 20, 2014
  23. Stefan BellerNov 20, 2014
  24. refs.c: use a string_list for repack_without_refsStefan Beller, Nov 20, 2014
  25. Jonathan NiederNov 20, 2014
  26. 0/6 repack_without_refs(): convert to string_listMichael Haggerty, Nov 21, 2014
  27. 1/6 prune_remote(): exit early if there are no stale referencesMichael Haggerty, Nov 21, 2014
  28. Jonathan NiederNov 22, 2014
  29. 2/6 prune_remote(): initialize both delete_refs lists in a single loopMichael Haggerty, Nov 21, 2014
  30. 3/6 prune_remote(): sort delete_refs_list references en masseMichael Haggerty, Nov 21, 2014
  31. Junio C HamanoNov 21, 2014
  32. Michael HaggertyNov 25, 2014
  33. Michael HaggertyNov 25, 2014
  34. Jonathan NiederNov 22, 2014
  35. 4/6 repack_without_refs(): make the refnames argument a string_listMichael Haggerty, Nov 21, 2014
  36. Jonathan NiederNov 22, 2014
  37. Michael HaggertyNov 25, 2014
  38. 5/6 prune_remote(): rename local variableMichael Haggerty, Nov 21, 2014
  39. Jonathan NiederNov 22, 2014
  40. 6/6 prune_remote(): iterate using for_each_string_list_item()Michael Haggerty, Nov 21, 2014
  41. Jonathan NiederNov 22, 2014
  42. Michael HaggertyNov 21, 2014
  43. Junio C HamanoNov 21, 2014
  44. Stefan BellerNov 21, 2014
  45. Our cumbersome mailing list workflow (was: Re: [PATCH 0/6] repack_without_refs(): convert to string_list)Michael Haggerty, Nov 25, 2014
  46. Torsten BögershausenNov 27, 2014
  47. Matthieu MoyNov 27, 2014
  48. Philip OakleyNov 28, 2014
  49. Eric WongNov 27, 2014
  50. Michael HaggertyNov 28, 2014
  51. brian m. carlsonNov 28, 2014
  52. Junio C HamanoDec 1, 2014
  53. Stefan BellerDec 3, 2014
  54. Jonathan NiederDec 3, 2014
  55. Junio C HamanoDec 3, 2014
  56. Torsten BögershausenDec 3, 2014
  57. Michael HaggertyNov 28, 2014
  58. Marc BranchaudNov 28, 2014
  59. Damien RobertNov 28, 2014
  60. Philip OakleyDec 3, 2014
  61. Stefan BellerDec 4, 2014

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.