From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 3F1EE3858D39 for ; Fri, 19 May 2023 12:41:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F1EE3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 8F5B492009D; Fri, 19 May 2023 14:41:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 87E0292009B; Fri, 19 May 2023 13:41:09 +0100 (BST) Date: Fri, 19 May 2023 13:41:09 +0100 (BST) From: "Maciej W. Rozycki" To: YunQiang Su cc: YunQiang Su , binutils@sourceware.org, xry111@xry111.site, richard.sandiford@arm.com, jiaxun.yang@flygoat.com Subject: Re: [PATCH] gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA In-Reply-To: Message-ID: References: <20230505092716.885338-1-yunqiang.su@cipunited.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 19 May 2023, YunQiang Su wrote: > > > It is added since 2016 by > > > Add support for .MIPS.abiflags and .gnu.attributes sections > > > b52717c0e104eb603e8189c3c0d3658ef5d903f5 > > > But never documented. > > > > Hmm, I can see this has been committed, but who has actually approved > > this change? > > > > Yes. I believe this change is an "obvious" change, as descripted in > > Read-write Git access - GNU Project: https://gcc.gnu.org/gitwrite.html Under this rule you can push a commit right away as long as you post the change committed to our mailing list afterwards, or if you post beforehand mentioning that you intend to push unless you hear objections within some reasonable time, but you do need to state there that the change has been or will be committed under the "obviously correct" rule. Also your change is actually not obviously correct, because it has a defect in formatting: an overlong line that exceeds 79 columns (staying within 74 is preferred where feasible). Finally for a non-native English speaker it's always good to have documentation changes reviewed as this is what our users will read, and the last thing we want is documentation that seems unprofessional. In this case you have an inconsistency between the two cases: one uses the singular and the other one uses the plural form of the noun, which is bad style. I find the style of the commit description so-so as well. Being internal only it's less of a problem, albeit unfixable once pushed. Maciej