Re: Should commits rather be buildable or small

[Liliana Marie Prikler]

Am Sonntag, dem 10.12.2023 um 17:28 +0200 schrieb Saku Laesvuori:
> > Hi Saku,
> > 
> > Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori:
> > > Hi,
> > > 
> > > I'm planning on refreshing Guix's haskell packages as my fix for
> > > https://issues.guix.gnu.org/66347 requires rebuilding all of them
> > > anyway. Should I try to keep commits small with only one update
> > > per commit (which is more work but managable if I don't care
> > > about the commits being buildable) or should I try to keep them
> > > buildable (i.e. update everything in one commit)? It is quite
> > > certain that most of them will not build after updating ghc or a
> > > subset of their dependencies, so making many small commits would
> > > cause nearly all of them to be unbuildable.
> > 
> > Define "buildable" and "unbuildable".
> 
> I used these definitions: a buildable commit does not have build
> failures (or at least no new ones). An unbuildable commit introduces
> new build failures (in this case a lot of them).
> 
> Buildable commits are safe spots to land on with time-machine in the
> sense that the packages defined in them can be used. I expect it
> would be very painful to try jumping to past commits with time-
> machine if a large portion of the commits in Guix were unbuildable.
Yeah, it's not really good commit etiquette to drop a bunch of world-
breaking builds on top of master.  We mostly use feature branches for
larger changes.  OTOH, if it rebuilds less than 300 packages, it really
is your call – the number of breakages is limited in that case too :)

> > Depending on the context, it may be fine or even required to break
> > dependant packages for a short while and update them along a longer
> > series.
> 
> I guess "required" here means that in some cases Guix's policy is to
> prefer small commits over buildable commits (with the previous
> definition). I at least don't see any technical reasons why it would
> be required. The question then becomes whether that policy applies in
> this case.
This is typically allowed when branching off, as few people will time-
machine into an intermediate commit on an off-master branch safe for
debugging some very arcane failures.  

> > However, in each commit at least the package touched in that
> > commit ought to build.
> 
> This should, of course, be theoretically possible with at least one
> update order but I don't know how would I discover that order (more
> efficiently than by trial and error. I don't want to try ~800²
> different combinations).
A reasonable way is to plan according to guix graph.  Tackle the low-
level nodes first and stack the high-level nodes on top.  If two
packages share immediate dependencies, but neither relies on the other,
then any order is fine between these two.

Cheers