From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Saku Laesvuori <saku@laesvuori.fi>
Cc: guix-devel@gnu.org
Subject: Re: Should commits rather be buildable or small
Date: Sun, 10 Dec 2023 16:50:14 +0100 [thread overview]
Message-ID: <7dbd09bea2e157f6fa739d9637d5bb87a44ab892.camel@gmail.com> (raw)
In-Reply-To: <baafvkmdhdyeevcd6jwric4qg7e7g5lmfq2f7lhzp3aumxh3ow@3bnc5vcgab2w>
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
next prev parent reply other threads:[~2023-12-10 15:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 8:42 Should commits rather be buildable or small Saku Laesvuori
2023-12-08 11:41 ` Tomas Volf
2023-12-08 12:05 ` Lars-Dominik Braun
2023-12-08 16:35 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-12-08 15:44 ` Liliana Marie Prikler
2023-12-10 15:28 ` Saku Laesvuori
2023-12-10 15:50 ` Liliana Marie Prikler [this message]
2023-12-10 17:02 ` Attila Lendvai
2023-12-10 17:50 ` Ricardo Wurmus
2023-12-10 23:20 ` Attila Lendvai
2023-12-10 23:56 ` Philip McGrath
2023-12-11 10:51 ` Attila Lendvai
2023-12-11 11:51 ` Ricardo Wurmus
2024-03-04 21:38 ` John Kehayias
2024-03-05 4:32 ` dan
2024-03-05 5:19 ` Liliana Marie Prikler
2024-03-25 1:15 ` John Kehayias
2024-03-25 3:23 ` dan
2024-03-25 3:23 ` [bug#69461] " dan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7dbd09bea2e157f6fa739d9637d5bb87a44ab892.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=guix-devel@gnu.org \
--cc=saku@laesvuori.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).