On 05/14/2018 10:50 AM, Florian Weimer wrote:
On 05/14/2018 04:38 PM, Carlos O'Donell wrote:
> The process you describe is largely mechanical, and easy enough to
> automate.
If everything is mechanical and easy to automate, why is it that the
only person regularly releasing Fedora updates is me?
My apologies, I did not intend to make it sound like this was a trivial
process. In fact the merge is difficult.
Before you arrived on the team, we just didn't do updates, because we
didn't have the resources. And I hope that with your scripts, and the
rest of the team we can have a schedule that works so you don't have to
do that :-)
> 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).
Do you do a scratch build on all architectures? I don't think this is feasible
because it turns every update into a multi-day effort.
I do a scratch build on architectures all the time.
My experience is that this does not turn every update into a multi-day effort.
Yes, you have to wait, you kick it off early, and then go do something else.
> 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.
This would need something that dumps out the ABI differences in a
base64 blob (similar to what we use to exfiltrate coredumps). Is
this included in your patches? I didn't see it there.
Look at patch 3 (cleaned up and matches your suggestion about SONAME
verification and storage for ABI files).
There are 3 binary toggles:
- Are we verifying ABI? If so, check it, and issue an error if we don't match.
- Are we in ABI warning mode only? If so, convert errors to warnings. Build continues.
- Are we in ABI saving mode? If so, collect the result of the ABI in a distinct file and
store in the rpms.
Yes, you have to alter the spec file and issue a build with an altered
spec file that is in "ABI saving mode + ABI warning mode" and you'll get
the best results in term of information about the build itself.
I think what you suggests requires local builds, not scratch builds
in Koji. This means that one needs to reserve a machine capable of
building the relevant Fedora branch. This is currently difficult to
automate for various reasons.
I suggest scratch builds in koji, which can be
automated, and anyone
outside of Red Hat can do in Fedora.
What benefit do local builds have? And if we did do local builds, we
don't need Fedora, just a machine that can run a Fedora mock build?
--
Cheers,
Carlos.