On 05/14/2018 10:26 AM, Florian Weimer wrote:
On 03/14/2018 09:56 PM, Carlos O'Donell wrote:
> On 03/14/2018 09:38 AM, Florian Weimer wrote:
>>>> 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.
>>
>> Sorry, I meant to write “when we merge changes from upstream
>> master into rawhide”.
>
> I see two cases:
>
> (a) Upstream has an abi/ directory.
>
> (b) Upstream does not have an abi/ directory.
>
> I also assume that we will be rebasing rawhide against upstream
> master, keeping our changes ahead of the upstream master.
>
> In the case of (a), any downstream changes to the ABI file would be
> made in the same individual commits that made changes to code. So
> during the rebase you would have to consider just one commit at a
> time as you reapplied them to your new rebased position.
>
> If they were just additions, we could simplify this by moving the
> additions to <xi:include>'d files that existed only in downstream.
>
> I have filed this RFE
>
https://sourceware.org/bugzilla/show_bug.cgi?id=22971
>
> In the case of (b) we have several options. My favorite is just to
> consider abi/ of rawhide to be the point at which *we* start
> tracking ABI, and so nothing special needs to be done until we get
> our work upstream and we're in situation (a), using libabigail
> upstream to do our ABI tracking instead of our bespoke ad-hoc
> symbol lists.
I find (b) rather burdensome because the ABI update has to happen as
part of the merge commit. So you have to do the merge, do a build,
figure out the ABI differences, applied that to the real merge, and
then build again. This is not my idea of a good development
process.
What is your baseline for the reference of "burdensome?"
What would define as "good?"
The process you describe is largely mechanical, and easy enough to
automate.
Today my process is like this:
(1) Do the merge.
(2) Scratch build.
(3) Verify scratch build.
(4) Commit.
(5) Do the final build.
The ABI baseline update and merge commit both happen at (4).
If you poll the rest of the glibc team I'd argue you find the rest of us
are doing something very similar. I never omit (2) and (3), and if you're
going to do a scratch build, then you just do this:
(1) Do the merge.
(2) Scratch build + ABI verify mode.
(3) Verify scratch build + Verify and update ABI.
(4) Commit.
(5) Do the final build.
The number of steps are the same.
Yes, our automated sync script omits (2) and (3), but it need not, and
it would just be a mechanical process of waiting a bit longer on a sync
to get the results, and slightly safer in the long run?
--
Cheers,
Carlos.