From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 0E6373858430 for ; Thu, 24 Feb 2022 07:07:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E6373858430 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id B4818342EA3; Thu, 24 Feb 2022 07:07:16 +0000 (UTC) Date: Thu, 24 Feb 2022 02:07:17 -0500 From: Mike Frysinger To: Richard Earnshaw Cc: newlib@sourceware.org, Brian Inglis Subject: Re: newlib not building (needs aclocal) Message-ID: Mail-Followup-To: Richard Earnshaw , newlib@sourceware.org, Brian Inglis References: <6e6ec1c8-70b3-5cc2-3b06-60f516a44ed0@foss.arm.com> <367ed8f2-e428-aacb-a4f9-82119d6408e4@SystematicSw.ab.ca> <5316b8e2-fd3e-0ad3-82f9-255cabd0ca1b@foss.arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g1QeZluVOvVHly63" Content-Disposition: inline In-Reply-To: <5316b8e2-fd3e-0ad3-82f9-255cabd0ca1b@foss.arm.com> X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 07:07:20 -0000 --g1QeZluVOvVHly63 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 23 Feb 2022 11:33, Richard Earnshaw wrote: > On 23/02/2022 06:01, Brian Inglis wrote: > > On 2022-02-22 04:57, Richard Earnshaw wrote: > >> PS While I appreciate what you're trying to do here, the timing=20 > >> couldn't be worse given that we're trying to stabilize a GCC release= =20 > >> and all my builds are breaking at present. > >=20 > > If you need stability, shouldn't you freeze your newlib pull at year en= d=20 > > 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just= =20 > > before Mike started his optimization and cleanup marathon, or maybe add= =20 > > an arm-gcc-dev(-11?) tag at some point in there? >=20 > Well for testing gcc-12 a freeze for gcc-11 is not very helpful. Newlib= =20 > doesn't have release branches (not really sure why not, especially when= =20 > there are potential security issues to deal with), and while I could=20 > freeze against specific tags, that would mean I never test tip-of-tree=20 > newlib. i think this is conflating things a bit. tot testing gcc against tot newlib is helpful for both projects. we want that. but if gcc is preparing a release branch, it should be freezing against a specific newlib tag (the latest at the time of that branch cut). users of a gcc release will also be grabbing newlib releases and expecting that they work together. that might mean there's still disruption for devs during the release cycle = -- tot gcc hadn't been tested against the latest newlib release previously, so bugs could pop up. but users are going to see those same bugs, so it's not like they're "false" failures. throwing builders at it would help (have tot test against tot newlib and the last newlib release), but i suspect that isn't worth the effort for the same reasons you mention -- the project normally doesn't move that fast, and the number of active devs is kind of low. > > Do you think perhaps devs doing extended or extensive work should creat= e=20 > > their own newlib, topic, or remote tracking branches (as Cygwin devs do= =20 > > for major work - see summary page heads or git ls-remote --heads=20 > > --sort=3D-creatordate | head) and commit work there, perhaps merging ba= ck=20 > > to master at intermediate points, or even not until complete? >=20 > There might be a case for this, particularly for disruptive changes.=20 > It's a matter of balance, given the size of the newlib project. practically speaking, i don't think topic branches would help that much as you highlight -- the newlib project, and number of projects/devs, is much too small to get a good signal back. it would require people to opt-in to the branch, as well as configure the various builders out there to use it. that seems pretty unlikely. which means once the topic branch is merged back into master, everything blows up. except instead of little scattered fires that are easier to pin to specific commit ranges, everything is on fire, perhaps for more than one reason, and requires multiple bisects over weeks/months of work. i'd like to think that for the regressions i've introduced (and fixed), i've made up for it with better comments & documentation. so the next person who touches things doesn't fall into the same pits. -mike --g1QeZluVOvVHly63 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIXLqUACgkQQWM7n+g3 9YFV2xAAu5hwH/iFXPsoAz1KL/vMbNs7MJ1C7nmqvxr7iZO3S118vO0qPigHP9mr IBxaEJo4vZTGV2ev9gTI/yujxSgVx9RSZba/sXMGfWF6oS0SHeK4mRqlFg2u0YEy lLXoTWMoPmBynWiXcws2+i6HWPLRs+Ekf1OultA7Z0Tw3/vl0Qs9oqY2n68o4zCq D99YSbm54GDTftY8fTwXjLSon6dJepYAu2FgrkSCl7Lj53o9o3zn657aSahW+OKZ pNu8AZ8W4pYcEY+EZrXiVWaNurymfPXA+5aiefz6yjn32cRxf4grrk7yVXzSVfuu Ymdv9s3Ameu2vpdelVZG0cPI7w3YBBNgdDVEgoySG8yG3eWBIu6exAM0LbZCgTkf vLYcyK/jfNqtzaVRV5xHr4ZZLQVi8HtlLyVcIyf4cwaKJE+hVDjByab5UbO0LqCu U3wrmMo5n0xNGvEP3MSYADj0aDX/QgNcURWs2Xl3UbEKGCZj1rzG4eftOsDc/C+t XxueA1ZD6Gg6x0xpUU6adnPhIgMH8ZXq1PRLqZ95YoYJkOSrDDBcAVtRXH9R7L3C u8zRQvEp+ZmpUGiIrqItKA1/JaklrFE1SPc1YgiN6V+BRCuKWlIRp1664NlJrYmi I1nrwavs3v+ZpACt9sI7L+d3rHVhpZaJyx9i9OdmcTzzy7NL7Mc= =uKSd -----END PGP SIGNATURE----- --g1QeZluVOvVHly63--