From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28803 invoked by alias); 18 Jan 2018 16:48:06 -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 28484 invoked by uid 89); 18 Jan 2018 16:48:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=perspective, wanting, hundred X-HELO: relay1.mentorg.com Date: Thu, 18 Jan 2018 16:48:00 -0000 From: Joseph Myers To: Samuel Thibault CC: Thomas Schwinge , Florian Weimer , , GNU C Library Subject: Re: Upstreaming the glibc Hurd port In-Reply-To: <20180118154251.ynfyugkmog7kujom@var.youpi.perso.aquilenet.fr> Message-ID: References: <20180118124537.yampmyfjsbi6wvia@var.youpi.perso.aquilenet.fr> <20180118135758.xqla2yevcrjjk7si@var.youpi.perso.aquilenet.fr> <87mv1btffy.fsf@hertz.schwinge.homeip.net> <20180118151446.zqlmpbmgg4kvs2y3@var.youpi.perso.aquilenet.fr> <20180118154251.ynfyugkmog7kujom@var.youpi.perso.aquilenet.fr> 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: 2018-01/txt/msg00620.txt.bz2 On Thu, 18 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +0000, wrote: > > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > Coding standards can be worked on by anybody, this is really something > > > that bug-hurd people can unload us from. > > > > Which is also something that having a branch with the patches is helpful > > for - > > Well, we already have that on > > git clone git.savannah.gnu.org:/srv/git/hurd/glibc.git/ > > with almost a hundred branches to be looked after... A hundred branches with many different purposes is not something at all convenient for glibc people to look over! > Not all of them are necessary for managing to build glibc. Some of them > are just hacking, others are perhaps almost ready to commit, just > missing changelogs & formatting. That's the triaging thing that takes > time, and having to do all the work including changelogs & formatting > makes it get lower in my global TODOlist. I'm still arguing on bug-standards for removing the requirement for ChangeLog format (given a public distributed version control system), but that wouldn't remove the requirement for proper explanations of patches, just mean that explanations intended to be read together with the patches themselves would suffice, without needing to duplicate the low-level details of how the patches change each affected named entity. > > (A branch close to current master also provides a basis for anyone working > > on build-many-glibcs.py support for Hurd, if you don't already have such > > support among your glibc patches.) > > That's why I suggested just committing the required patches to a branch > that we rebase regularly, so there's a master that does build. Yes, that's what I'd like to see. From the perspective of people wanting to do global changes to glibc I think the priorities would be (a) building cleanly for Hurd; (b) building for Hurd with the intended ABI exported from each library at each symbol version; (c) having ABI test baselines to verify the ABI stays as expected; (d) having all the rest of the compilation parts of the testsuite passing. Even given just (a) I might look at setting up build-many-glibcs.py support. -- Joseph S. Myers joseph@codesourcery.com