This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add new script add-abilist.py
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 5 Mar 2015 14:03:13 -0800 (PST)
- Subject: Re: [PATCH] Add new script add-abilist.py
- Authentication-results: sourceware.org; auth=none
- References: <20150302080300 dot B464D4242A0BE at oldenburg dot str dot redhat dot com> <20150302201942 dot AC9532C39F1 at topped-with-meat dot com> <54F4CCCC dot 3070500 at redhat dot com> <20150302205928 dot C13FE2C3A08 at topped-with-meat dot com> <54F4CFCE dot 1020700 at redhat dot com> <54F8AED7 dot 2090109 at redhat dot com> <54F8C425 dot 8070501 at redhat dot com> <54F8CD76 dot 8030704 at redhat dot com>
> Could we have a `make all-update-abi` target that ran `make update-abi`
> and then ran your script to propagate all the changes to all other
> targets? That's the only useful case I can come up with where your
> script helps.
Anything with a manually-controlled step still assumes that the human gets
the details right. Of course it would be caught eventually if they don't,
but it still seems like false security to me.
If we get to where we have a buildbot (even compile-only) for each
maintained configuration, then we can arrange to have the bot logs show
check-abi diffs in a digestible fashion. Then one can commit the change
including the 'make update-abi'-created changes for every machine one
personally built for, wait for all the bots to cycle, and run some
bot-log-scraping script that has the effect of producing the same changes
'make update-abi' would do if you were able to build it locally. Of course
that leaves a window of commit history where check-abi is in a failing
state for some subset of configurations, which is less than ideal.