linux-kernel - Re: [PATCH] Documentation: riscv: add patch acceptance guidelines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 25 Nov 2019 08:57:56 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Paul Walmsley <paul.walmsley@...ive.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        linux-riscv@...ts.infradead.org, palmer@...belt.com,
        aou@...s.berkeley.edu, krste@...keley.edu,
        waterman@...s.berkeley.edu,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH] Documentation: riscv: add patch acceptance guidelines

On Sun, 24 Nov 2019 18:48:54 -0800 (PST)
Paul Walmsley <paul.walmsley@...ive.com> wrote:

> On Sat, 23 Nov 2019, Dan Williams wrote:
> 
> > I'm open to updating the headers to make a section heading that
> > matches what you're trying to convey, however that header definition
> > should be globally agreed upon. I don't want the document that tries
> > to clarify per-subsystem behaviours itself to have per-subsystem
> > permutations. I think we, subsystem maintainers, at least need to be
> > able to agree on the topics we disagree on.  
> 
> Unless you're planning to, say, follow up with some kind of automated 
> process working across all of the profile documents in such a way that it 
> would make technical sense for the different sections to be standardized, 
> I personally don't see any need at all for profile document 
> standardization.  As far as I can tell, these documents are meant for 
> humans, rather than computers, to read.  And in the absence of a strong 
> technical rationale to limit how maintainers express themselves here, I 
> don't think it's justified.

Patch changelogs are (mostly) meant for humans to read too, but we have
some standards for how we want them formatted.  I don't think the
maintainer profiles should be all that tightly specified, but it would be
a whole lot better if cross-subsystem developers knew where to look to
quickly find the information they need.  So I'd prefer it if we could find
a way to conform to a set of loose guidelines for these files.

Thanks,

jon