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

Re: [RFC PATCH] doc: describe the project's decision-making process

From
Taylor Blau <me@ttaylorr.com>
Date
May 3, 2024, 19:29 UTC
Message-ID
<ZjU7CWdwb+xKubul@nand.local>
In-Reply-To
<xmqqfruy7oq8.fsf@gitster.g>
On Fri, May 03, 2024 at 11:08:15AM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> > Yes, sorry for silence on this thread. I am working on a V2 but
> > probably won't have it ready today.
>
> Don't be sorry; the message was not addressed to you, but for wider
> community participants---especially the ones with more "clout" (or
> "long timers" or whatever word we would use to describe those whose
> opinions are trusted by others and count more) need to buy in if we
> were to first agree on that it is good to have a set of written
> rules, and to then agree on what rules to adopt.

I have been meaning to respond to this thread since I was mentioned in it by Emily, but have been unsure of what to say.

On one hand, I think the document basically outlines the status-quo of decision making for issues that are larger than the scope of a single patch series (think "should we use Rust?", "what is our platform support policy?", or "how should we approach libification?" not "is this particular patch (series) correct?").

So in that sense, I think that the document is a good starting point, and I think that it reasonably captures the status quo.

But I wish that we didn't have to have such a document in the first place. In my opinion, I would much rather see decisions like "what is our platform policy?" made according to discussions on a patch that defines what that policy is. That way such decisions can be treated in the same way as ordinary review is today, and we can avoid the need for a separate process.

(For what it's worth, I thought that the SHA-256 transition was a good example of this. The RFC was posted, and the discussion was had on the patch series itself).

Another way of thinking about this is that I would be extremely reluctant to see a similar document proposed for reviewing at the patch series level. In my opinion, the system of reviewers and participants discussing the series and the maintainer solely determining whether or not consensus has been reached is a good one, and I would be extremely hesitant to recommend changing it.

And I would advocate for a similar approach to decisions that have implications beyond a single patch series.

Thanks, Taylor

Previous: Junio C HamanoNext: Patrick Steinhardt
Message 11 of 44 in “doc: describe the project's decision-making process”
  1. doc: describe the project's decision-making processJosh Steadmon, Apr 15, 2024
  2. Junio C HamanoApr 16, 2024
  3. Josh SteadmonApr 22, 2024
  4. Junio C HamanoApr 22, 2024
  5. Junio C HamanoApr 23, 2024
  6. Enrico MrassApr 17, 2024
  7. Junio C HamanoApr 17, 2024
  8. Junio C HamanoMay 3, 2024
  9. Josh SteadmonMay 3, 2024
  10. Junio C HamanoMay 3, 2024
  11. Taylor BlauMay 3, 2024
  12. Patrick SteinhardtMay 6, 2024
  13. Taylor BlauMay 6, 2024
  14. Josh SteadmonMay 6, 2024
  15. Taylor BlauMay 6, 2024
  16. Emily ShafferApr 22, 2024
  17. Junio C HamanoApr 22, 2024
  18. Emily ShafferApr 22, 2024
  19. Junio C HamanoApr 23, 2024
  20. doc: describe the project's decision-making processJosh Steadmon, May 9, 2024
  21. Junio C HamanoMay 9, 2024
  22. Junio C HamanoMay 9, 2024
  23. 0/2 Describe patch-flow better in SubmittingPatchesJunio C Hamano, May 9, 2024
  24. 1/2 SubmittingPatches: move the patch-flow section earlierJunio C Hamano, May 9, 2024
  25. 2/2 SubmittingPatches: extend the "flow" sectionJunio C Hamano, May 9, 2024
  26. Karthik NayakMay 10, 2024
  27. Junio C HamanoMay 10, 2024
  28. Karthik NayakMay 10, 2024
  29. 0/2 Describe life cycle of a patch seriesJunio C Hamano, May 10, 2024
  30. 1/2 SubmittingPatches: move the patch-flow section earlierJunio C Hamano, May 10, 2024
  31. 2/2 SubmittingPatches: extend the "flow" sectionJunio C Hamano, May 10, 2024
  32. decisions: focus on larger scale issuesJunio C Hamano, May 10, 2024
  33. Josh SteadmonMay 15, 2024
  34. Junio C HamanoMay 15, 2024
  35. Josh SteadmonMay 15, 2024
  36. doc: describe the project's decision-making processJosh Steadmon, May 16, 2024
  37. Junio C HamanoMay 16, 2024
  38. Josh SteadmonMay 17, 2024
  39. Patrick SteinhardtMay 17, 2024
  40. Junio C HamanoMay 17, 2024
  41. Patrick SteinhardtMay 21, 2024
  42. doc: describe the project's decision-making processJosh Steadmon, May 17, 2024
  43. Junio C HamanoMay 17, 2024
  44. Patrick SteinhardtMay 21, 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.