Hi,

On Monday, August 8, 2022 5:01:31 AM EDT Liliana Marie Prikler wrote:
> You should really split this into two patches.  One to add Zuo, one to
> upgrade the Racket stuff.  Maybe you need even more steps if Zuo
> depends on parts of the racket bootstrap.
> 
> You will probably have to parameterize the Racket origin in a bunch of
> packages to get things going.  As an upside, this added flexibility
> hopefully comes in handy with the next Racket upgrade.
> 

I am especially reluctant to split this patch apart.

If I had to, I could make one patch adding the Zuo package with an origin 
inheriting from the previous %racket-origin, but adjusting the patches, 
commit, file name, and checksum to make the %racket-origin in this patch. (As I 
wrote in the patch, Zuo has no dependencies, it's just `cc -o zuo zuo.c`.) 
Then, a second patch would make %racket-origin as it is in this package, 
change Zuo to use it, and update the other packages.

But I do not see the benefit in doing so. I would still need a commit changing 
the same set of packages, short of leaving some of them broken. And adding, 
then immediately removing, a temporary origin for Zuo would seem to me to make 
reviewing this harder, not easier, both now and when reviewing these changes 
in the future.

The packages developed in the main Racket Git repository are very tightly 
linked. They are developed there precisely to make sure they are all always at 
consistent versions. Fighting against that is just going to cause difficulty 
with every Racket update. For example, there is no commitment that the version 
of Zuo released with Racket 8.5 will be able to build Racket 8.6.

I think this patch is better as a single commit, and at lease as justified as 
commits like b97f549b14402421fcfb360ddd4cff7de93b9af0.

-Philip