From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120523 invoked by alias); 11 May 2017 00:12:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 120485 invoked by uid 89); 11 May 2017 00:12:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Thu, 11 May 2017 00:12:00 -0000 From: Joseph Myers To: Zack Weinberg CC: , , , , , Subject: Re: [PATCH 00/10] All of my not-yet-reviewed patches In-Reply-To: <20170509154103.11973-1-zackw@panix.com> Message-ID: References: <20170509154103.11973-1-zackw@panix.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-05/txt/msg00270.txt.bz2 On Tue, 9 May 2017, Zack Weinberg wrote: > I think that patches 1 through 7 should be good to go as is, but they > all do still need careful review, they're all touching old, dusty code > with API and ABI implications. Patches 8, 9, and 10 are more > experimental; patch 8 in particular is a deliberate API (but not ABI, > I think) break. As I see it, patches 5, 7, 8, 9 and 10 would need NEWS entries if accepted. Patch 5 is adding a new feature (error_t enumeration being made available on non-Hurd), patch 7 is adding a new public header sys/uio_ext.h and declaring it to be the main home for certain extensions (which is something that really needs considering carefully, apart from the more routine cleanups in that patch), while patches 8, 9 and 10 are removing public interfaces (you can argue about the extent to which any public interface is involved in patches 9 and 10, but I'd say that __USE_STRING_INLINES and __NO_STRING_INLINES are currently public interfaces, whose effects are being removed). -- Joseph S. Myers joseph@codesourcery.com