Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)

[Leo Famulari <leo@famulari.name>]

On Thu, Apr 22, 2021 at 12:27:52PM -0400, Mark H Weaver wrote:
> I don't understand why it's relevant how many patches are involved.  It
> sounds like if I had concatenated all of the CVE-2021-27219 patches into
> a single file, you would have judged that as "simple", and therefore
> ungrafted it, although it makes no substantive difference.

I know you understand the subtle risks of grafting, compared to
rebuilding packages with the grafted changes. Just because something
works as a graft, or seems to work as a graft, there is no guarantee
that it will continue to work when we absorb the graft and rebuild all
dependent packages.

I decided to use this "simple change" heuristic based on my own
experience working with grafts. Experience grants intuition, and my
intuition tells that me that grafts with fewer lines of changed code are
less likely to cause build failures or to change the behaviour of a
package beyond the desired security fix.

Remember, the goal of this branch was to attempt to *quickly* absorb
some grafts. I had to use a heuristic approach. Both in deciding which
grafts to absorb, and in explaining my decisions to you (I did not
expect you to misunderstand).

I could have told you that I selected these grafts based on "number of
lines of changed code", but it was easier to write "number of patches".

If you had concatenated those patches, I would have noticed that the
file was gigantic and chosen not to ungraft it at this time.

And to preempt the reply that you are sure to send, yes, I actually
looked at the content of the patches when making my decisions.