Re: Should commits rather be buildable or small

[John Kehayias <john.kehayias@protonmail.com>]

Hi,

Apologies for the delay. I would like to get things rolling on
mesa-updates and building, including the vulkan updates, so a choice
will have to be made :)

Thanks for the input so far!

On Tue, Mar 05, 2024 at 06:19 AM, Liliana Marie Prikler wrote:

> Hi,
>
> Am Montag, dem 04.03.2024 um 21:38 +0000 schrieb John Kehayias:
>> [...]
>> 1. Essentially squash to one commit where all of vulkan is updated in
>> one commit. The main upside is that nothing should break (within
>> vulkan, dependents to be fixed as needed) and it shows as "one"
>> change; the main downside is that the proposed changes are not just
>> trivial version bumps. Harder to then disentangle as needed.
>>
>> 2. Make each commit updating a package, but don't use the variable
>> %vulkan-sdk-version, updating each package with a version as it is
>> done. Then do a commit where all the versions are replaced by the
>> variable. This seems like unnecessary work to me and while it stops
>> the obvious breaking (source hashes don't match once variable is
>> updated but package hasn't yet) versions are still mixed which is
>> likely a problem.
>>
>> 3. Go with the series as proposed: this means after the first commit
>> for sure all other vulkan packages and dependents don't build, as the
>> source hashes won't match until the commit that updates that package.
>> Along with version mixing, this perhaps doesn't give you a helpful
>> git bisect either?
>>
>> None are perfect. What do people think?
> I think 1 would be workable if the changes to the packages are minimal.
> You should also check whether you can just do the version bumps and
> then the other changes – or flip the order.
>

As currently proposed, the changes are not minimal.

dan: Do you know if just a version/hash bump is at least buildable? Or
are the changes necessary for the packages to build/function at all?
Or I guess if the non-version changes are applicable to the current
version first?

> I don't really see the benefit with 2.  Normally, we'd have "-next"
> variants to catch nontrivial updates (among other things), but those
> don't seem a good approach here.
>
> If nothing else works, 3 is indeed an option to fall back to, albeit
> begrudgingly.  As noted for 1, you could check whether bumping all the
> hashes and then only fixing whatever else for the builds is an option
> here.
>

That's what I'll have to do I think, unless indeed the versions
changes can be made separately and still build. I can mark each patch
in the commit log that it is part of a series updating all the vulkan
packages. That might be something worth doing in general for cases
like this, to help out future time travelers and when e.g. searching
the log and finding a commit.

> Alternative 4 would be to build those -next variants and then replace
> the base vulkan all at once.  This has the advantage of not doing any
> version mixing in-between IIUC.
>

That's also an idea. Add a %vulkan-version-next or something like
that, and -next variants of all the packages using that version
instead. A bit clumsy and perhaps convoluted with the extra work for
maybe minimal gain.

I'll wait to see if dan has any information of what changes can be
made independently, but I guess I'll just have to make a decision on
mesa-updates.

Thanks!

John