This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add new script

On 03/05/2015 05:03 PM, Roland McGrath wrote:
>> 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.
>> Thoughts?
> 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.

Right, you would use trybot once we get it.

I'm arguing Florian's script is 50% of a solution. I've had to update
the abi files and it's annoying. Similarly Florian probably has also.

You really want:

(a) `make all-update-abi` to propagate `make update-abi` changes to all
    machine abis.


(b) A trybot that you can use to scrape the results of `make update-abi`
    which gives you perfect confidence that things are working as


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]