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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024.05.03 15:29, 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.
> 
> 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.

How would you feel about a doc outlining how the process changes as you
go from: A) small/medium patch series, to B) larger discussions with
(parts of) the proposal recorded in patches, to C) large discussions
with no patches? This is the structure I'm leaning towards for my V2
draft.


> (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.

Sorry, I'm not sure I understand why you wouldn't want the patch series
process documented? I'm just trying to capture the status quo, not to
propose or recommend any changes.


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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux