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

Re: Our cumbersome mailing list workflow

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 1, 2014, 02:46 UTC
Message-ID
<xmqqh9xgrssc.fsf@gitster.dls.corp.google.com>
In-Reply-To
<547895F1.1010307@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 10 quoted lines
> 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?

As a reviewer / contributor (not speaking as the top maintainer), I would say that everything in one place, and for that one place mailbox is preferrable.

"Somebody commented on (this instance of | the central) Gerrit, come look at it" is not usable; sending that comment out to those who work in their MUA, and allowing them to respond via their MUA probably adding their response as a new comment to Gerrit) would be usable.

When I had to view a large-ish series by Ronnie on Gerrit, it was fairly painful. The interaction on an individual patch might be more convenient and efficient using a system like Gerrit than via e-mailed patch with reply messages, but as a vehicle to review a large series and see how the whole thing fits together, I did not find pages that made it usable (I am avoiding to say "I found it unusable", as that impression may be purely from that I couldn't find a more suitable pages that showed the same information in more usable form, i.e. user inexperience).

Speaking of the "whole picture", I am hesitant to see us pushed into the "here is a central system (or here are federated systems) to handle only the patch reviews" direction; our changes result after discussing unrelated features, wishes, or bugs that happen outside of any specific patches with enough frequency, and that is why I prefer "everything in one place" aspect of the development based on the mailing list. That is not to say that the "one place" has forever to be the mailing list, though. But the tooling around an e-mail based workflow (e.g. marking threads as "worth revisiting" for later inspection, saving chosen messages into a mailbox and running "git am" on it) is already something I am used to. Whatever system we might end up migrating to, the convenience it offers has to beat the convenience of existing workflow to be worth switching to, at least to me as a reviewer/contributor.

As the maintainer, I am not worried too much. As long as the mechanism can (1) reach "here is a series that is accepted by reviewers whose opinions are trusted" efficiently, and (2) allow me to queue the result without mistakes, I can go along with anything reasonable.

Previous: brian m. carlsonNext: Stefan Beller
Message 52 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.