Re: Should commits rather be buildable or small

[Liliana Marie Prikler]

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.

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.

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.


Cheers