Re: newlib not building (needs aclocal)

Mike Frysinger <[email protected]> Thu, 24 Feb 2022 02:07:17 -0500
Newsgroups	gmane.comp.lib.newlib
Message-ID	<Yhcupdhx8v10vElR@vapier>
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 
> >> couldn't be worse given that we're trying to stabilize a GCC release 
> >> and all my builds are breaking at present.
> > 
> > If you need stability, shouldn't you freeze your newlib pull at year end 
> > 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just 
> > before Mike started his optimization and cleanup marathon, or maybe add 
> > an arm-gcc-dev(-11?) tag at some point in there?
> 
> Well for testing gcc-12 a freeze for gcc-11 is not very helpful.  Newlib 
> doesn't have release branches (not really sure why not, especially when 
> there are potential security issues to deal with), and while I could 
> freeze against specific tags, that would mean I never test tip-of-tree 
> 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 create 
> > their own newlib, topic, or remote tracking branches (as Cygwin devs do 
> > for major work - see summary page heads or git ls-remote --heads 
> > --sort=-creatordate | head) and commit work there, perhaps merging back 
> > to master at intermediate points, or even not until complete?
> 
> There might be a case for this, particularly for disruptive changes. 
> 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
signature.asc (application/pgp-signature, 833 B)