Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)
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.
Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)
Hi Leo, Leo Famulari writes: > On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote: >> I just noticed that 'glib' is still grafted on the 'wip-ungrafting' >> branch. Was that intentional? >> >> https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting=e12210dc92098d8581cea3007d57dbb6be16bb41#n171 > > Yes. For that branch I only selected grafts that I judged to be > "simple". There are many other grafts still in place on that branch. Okay, thanks for the explanation. > My criteria for simplicity are grafts that either apply one or two > patches, or are minor version upgrades of projects that are known to > care about ABI compatibility. 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. Anyway, it makes no difference to me; I'll continue doing my own thing on my private branch. I just wanted to make sure that it wasn't an oversight. Thanks, Mark
Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)
On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote: > I just noticed that 'glib' is still grafted on the 'wip-ungrafting' > branch. Was that intentional? > > https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting=e12210dc92098d8581cea3007d57dbb6be16bb41#n171 Yes. For that branch I only selected grafts that I judged to be "simple". There are many other grafts still in place on that branch. My criteria for simplicity are grafts that either apply one or two patches, or are minor version upgrades of projects that are known to care about ABI compatibility. We want to ungraft as much as possible for the upcoming release, to improve performance of package operations. However, we lack the time and humanpower to validate the ungrafting of the more complicated grafts in time for the release. Some of the remaining grafts should never have been made, in my opinion, and I want to discuss our policies on this subject — after the release. In any case, I'm not confident that we will include wip-ungrafting in the release. The build failure rate of the wip-ungrafting branch is higher than 10%, which I think is too high: https://ci.guix.gnu.org/jobset/ungrafting signature.asc Description: PGP signature
Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)
I just noticed that 'glib' is still grafted on the 'wip-ungrafting' branch. Was that intentional? https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting=e12210dc92098d8581cea3007d57dbb6be16bb41#n171 Mark
