On 03/14/2018 04:37 PM, Carlos O'Donell wrote:
On 03/14/2018 09:23 AM, Florian Weimer wrote:
> On 03/09/2018 07:33 PM, Carlos O'Donell wrote:
>> On 03/09/2018 10:15 AM, Florian Weimer wrote:
>>> On 03/07/2018 06:11 PM, Carlos O'Donell wrote:
>>>> Would we create an upstream Fedora branch that is based on the
>>>> glibc release, and then layer the ABI baselines there?
>>>
>>> Yes, we could have an abi/ directory tree with those files
>>> there. Any ABI change would also have to update the baseline
>>> files. That may not work so well for rawhide, though.
>>
>> What would not work well?
>>
>> What are the "baseline" files?
>>
>> If we went with upstream branches I would assume they would look
>> like this:
>>
>> master (glibc) -> master (rawhide)
>>
>> Here master (rawhide) has an abi/ directory, but it isn't verified
>> against.
>>
>> When master (glibc) freezes we start doing ABI verification on
>> rawhide spec files.
>
> Oh, I thought you wanted to do continuous verification during
> development.
I do. I didn't want to suggest it upfront though until we'd worked
a bit more with verification at the individual release phases.
> Then the problem is that if you merge from rawhide, you need to make
> ABI edits at the same time, and it won't be clear which changes in
> the merge commit come from the upstream changes, and which are due to
> adjustments of downstream-only (internal) ABI adjustments as the
> result of resolving (semantic) merge conflicts.
I don't follow. Could you expand on this?
When and what do we merge from rawhide?
Sorry, I meant to write “when we merge changes from upstream master into
rawhide”.
Thanks,
Florian