This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Separate patch reviews for support/ additions?
- From: Florian Weimer <fweimer at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 3 Nov 2017 23:01:07 +0100
- Subject: Re: Separate patch reviews for support/ additions?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C9964356D7
- References: <xnmv43111e.fsf@greed.delorie.com>
On 11/03/2017 10:54 PM, DJ Delorie wrote:
Florian Weimer <fweimer@redhat.com> writes:
Do we want separate patch reviews for any new support/ functions? Or
should we just add them along with test cases that need them?
If the question is, "should we review new things in support/?" I think
the answer is obviously yes.
We currently backport support/ directory updates in bulk, so the
question of backporting does not arise. Otherwise, separate commits
would make sense. I do not propose to change procedure here.
(Nothing in support/ has any ABI impact, so these backports are low
risk, except for new compilation failures, but those are easily remedied
on a case-by-case basis and hard to spot in reviews anyway.)
But I assume the question is, "should they be reviewed separately, or
bundled?" I prefer bundled - we have a large enough patch backlog
already without artificially increasing traffic. Also, seeing the
context might help with the review. It would certainly short-circuit
the "why do we need this?" questions ;-)
Agreed.
Florian