From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Josh Steadmon <steadmon@google.com>,
git@vger.kernel.org, avarab@gmail.com,
christian.couder@gmail.com, Enrico Mrass <emrass@google.com>,
Emily Shaffer <nasamuffin@google.com>
Subject: Re: [RFC PATCH] doc: describe the project's decision-making process
Date: Mon, 6 May 2024 09:12:15 +0200 [thread overview]
Message-ID: <ZjiCz4_2KABLshLx@tanuki> (raw)
In-Reply-To: <ZjU7CWdwb+xKubul@nand.local>
[-- Attachment #1: Type: text/plain, Size: 5030 bytes --]
On Fri, May 03, 2024 at 03:29:13PM -0400, Taylor Blau wrote:
> On Fri, May 03, 2024 at 11:08:15AM -0700, Junio C Hamano wrote:
> > > 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.
Fair enough. Given that I have been contributing quite a bit more
recently I'll feel myself addressed here.
> 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.
With "such a document", do you refer to the one documenting the process
to do such changes or the RFC-style document?
If you mean the former I disagree and think that it would be great to
document reasonable approaches for how to get to an agreement with the
Git community. It's especially helpful for newcomers to the commuinity,
and I do get questions around "How to reach consensus in Git" all the
time at GitLab.
Now the important part to me is that we should retain flexibility and
allow us to adapt. It should rather be a helpful resource to newcomers
than a rigid set of requirements that everyone has to follow, in my
opinion.
If it's the latter (no need for an RFC-style document) I somewhat agree.
I'm of the opinion that patches are the best way to trigger a more
informed discussion because participants will know how something will
end up looking like. I also tend to send patch series for controversial
topics upstream without prior discussion, but my intent here is never to
force the result, but rather to force the discussion itself. This of
course comes with the big downside that you may end up wasting quite a
lot of your own time in case the community disagrees with your approach,
but that's acceptable to me most of the time.
It's only part of the story though. There are bigger changes that simply
don't make a ton of sense to propose in the above form, mostly because
their sheer scope is much larger. As you point out further down, things
like the SHA256 transition are in that realm.
Here I very much think that having a central place where such large
projects are tracked. Given that we have no issue tracker, I think the
next-best place to do this would be the Git repository itself. We
already do this for some larger topics, but I feel like the bar is quite
high right now. It doesn't make a ton of sense for example to have a
huge RFC for the removal of `the_repository`.
So something that I'd really love to see is if we adopted the micro
projects document [1] into Git itself and generalized it such that we
can add smallish sections for new large-scale projects. Ideally, such
projects could also have trailers that indicate who is interested in
those projects such that folks knew whom to reach out to if they want to
start contributing to the project. This would help us to document
consensus around new projects, and would help newcomers of the
community to pick up new projects.
Patrick
[1]: https://git.github.io/SoC-2024-Microprojects/
> (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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-05-06 7:12 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 23:20 [RFC PATCH] doc: describe the project's decision-making process Josh Steadmon
2024-04-16 0:24 ` Junio C Hamano
2024-04-22 21:10 ` Josh Steadmon
2024-04-22 21:30 ` Junio C Hamano
2024-04-23 22:41 ` Junio C Hamano
2024-04-17 16:32 ` Enrico Mrass
2024-04-17 16:58 ` Junio C Hamano
2024-05-03 14:45 ` Junio C Hamano
2024-05-03 15:48 ` Josh Steadmon
2024-05-03 18:08 ` Junio C Hamano
2024-05-03 19:29 ` Taylor Blau
2024-05-06 7:12 ` Patrick Steinhardt [this message]
2024-05-06 20:14 ` Taylor Blau
2024-05-06 19:36 ` Josh Steadmon
2024-05-06 20:17 ` Taylor Blau
2024-04-22 18:41 ` Emily Shaffer
2024-04-22 19:18 ` Junio C Hamano
2024-04-22 21:12 ` Emily Shaffer
2024-04-23 1:10 ` Junio C Hamano
2024-05-09 0:01 ` [PATCH v2] " Josh Steadmon
2024-05-09 18:10 ` Junio C Hamano
2024-05-09 19:20 ` Junio C Hamano
2024-05-09 21:13 ` [PATCH 0/2] Describe patch-flow better in SubmittingPatches Junio C Hamano
2024-05-09 21:13 ` [PATCH 1/2] SubmittingPatches: move the patch-flow section earlier Junio C Hamano
2024-05-09 21:13 ` [PATCH 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 10:08 ` Karthik Nayak
2024-05-10 15:59 ` Junio C Hamano
2024-05-10 19:09 ` Karthik Nayak
2024-05-10 16:55 ` [PATCH v2 0/2] Describe life cycle of a patch series Junio C Hamano
2024-05-10 16:55 ` [PATCH v2 1/2] SubmittingPatches: move the patch-flow section earlier Junio C Hamano
2024-05-10 16:55 ` [PATCH v2 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 16:56 ` [PATCH] decisions: focus on larger scale issues Junio C Hamano
2024-05-15 20:36 ` Josh Steadmon
2024-05-15 20:50 ` Junio C Hamano
2024-05-15 20:35 ` [PATCH v2 0/2] Describe life cycle of a patch series Josh Steadmon
2024-05-16 21:20 ` [PATCH v3] doc: describe the project's decision-making process Josh Steadmon
2024-05-16 22:01 ` Junio C Hamano
2024-05-17 20:18 ` Josh Steadmon
2024-05-17 6:29 ` Patrick Steinhardt
2024-05-17 16:40 ` Junio C Hamano
2024-05-21 5:56 ` Patrick Steinhardt
2024-05-17 20:35 ` [PATCH v4] " Josh Steadmon
2024-05-17 22:12 ` Junio C Hamano
2024-05-21 5:58 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjiCz4_2KABLshLx@tanuki \
--to=ps@pks.im \
--cc=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=emrass@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=nasamuffin@google.com \
--cc=steadmon@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).