Detailed symbols.map

Daniel van Vugt daniel.van.vugt at canonical.com
Thu Aug 27 03:54:08 UTC 2015


Doing it in the release process is inefficiently late. Obviously it 
would be preferable to notice breaks before the release is attempted so 
as to now slow it down.

And if abi-check is run as part of the release process, are the results 
stored anywhere? They don't seem to be in CI so it must be separate to 
that...
    https://code.launchpad.net/~mir-team/mir/0.15/+merge/269082

If anyone has any further info, please update:
    https://bugs.launchpad.net/mir/+bug/1451733


On 27/08/15 11:37, Christopher James Halse Rogers wrote:
>
>
> On Thu, Aug 27, 2015 at 1:30 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> That's the problem. We don't have abi-check automated yet. Although we
>> don't have to limit ourselves to that.
>>
>> What we do have is regular ABI breaks landing and nobody noticing. So
>> I audit the code manually and propose the missing breaks. Fortunately
>> the whole team is getting on board and noticing them more often, but
>> it's still not automated.
>
> And why is this a problem? We run abi-check as a part of the release
> process, and the ABI breaks (by and large) haven't broken CI (or the
> branch wouldn't have landed).
>
> It would be *preferable* to bump ABI along with the branch that breaks
> it, but what is the problem if it isn't?
>
> We know a *good* solution - automating abi-check - is reasonably close
> to implementable and should be reasonably cheap to implement. Is the
> problem so urgent that we should spend effort on an inferior stop-gap?
>



More information about the Mir-devel mailing list