From: Efraim Flashner <efraim@flashner.co.il>
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: Dealing with mass rebuilds
Date: Wed, 21 Oct 2015 10:27:06 +0300 [thread overview]
Message-ID: <20151021102706.339f0758@debian-netbook> (raw)
In-Reply-To: <20151020214716.GA7835@debian>
[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]
On Tue, 20 Oct 2015 23:47:16 +0200
Andreas Enge <andreas@enge.fr> wrote:
> On Tue, Oct 20, 2015 at 09:45:54PM +0200, Ludovic Courtès wrote:
> > The Nixpkgs folks have a ‘staging’ branch for changes that cause mass
> > rebuilds but are well tested, such that they can be merged into ‘master’
> > anytime². Perhaps something we should do as well?
>
> Would that be different from your suggestion that if the curl update caused
> a rebuild of too many packages (whatever that would mean, which is a separate
> discussion) it should not be done on core-updates, but on its own branch,
> for instance, curl-update? One practical advantage I see in a staging
> branch, if I understand your suggestion correctly, is that one would not need
> to modify the set of jobs on hydra to now also build curl-update, and then
> maybe giflib-update, and then xyz-update, but it would always be called
> "staging".
>
> Now the "well tested" assumption is dubious. I actually do not know whether
> the curl update will go through. I tried to build one of the packages shown
> by "guix refresh -l curl" that looked simple (mpd), but it turned out it
> was not simple at all and needed a lot of rebuilds (including texlive).
> Admittedly, I could have spent more time searching a direct dependency,
> probably by using one of your recent graph drawing commands. So in case
> a problem turns up, would we revert a curl update on the staging branch
> and do more local work before proposing it again?
>
> And if Efraim wished to do a gitlib update after my curl update, what would
> be the protocol? Would he be expected to wait until the hydra build of the
> curl update has finished? Or at least until it has finished on x86_64?
> Otherwise, we would again face the risk of the staging branch becoming
> an update-the-world branch with unforeseen ramifications.
>
> Andreas
>
>
How much build infrastructure does nix have? (do they build all of staging
all the time?) Would it be possible to identify the subset of packages that
are immediately dependant on the updated package, and build only those as a
test on hydra? That would be faster, but if something broke it'd be harder to
track down, a la 白い熊's conkeror issue.
--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-10-21 7:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151020161651.4759.8347@vcs.savannah.gnu.org>
[not found] ` <E1ZoZal-0001Fl-M5@vcs.savannah.gnu.org>
2015-10-20 18:17 ` 01/01: gnu: curl: Update to 7.45.0 Mark H Weaver
2015-10-20 19:45 ` Dealing with mass rebuilds Ludovic Courtès
2015-10-20 19:56 ` Efraim Flashner
2015-10-20 21:47 ` Andreas Enge
2015-10-21 7:27 ` Efraim Flashner [this message]
2015-10-21 16:41 ` Ludovic Courtès
2015-10-21 16:45 ` Ludovic Courtès
2015-10-22 20:11 ` Paul van der Walt
2015-10-25 21:34 ` Ludovic Courtès
2015-10-22 18:20 ` Mark H Weaver
2015-10-22 18:32 ` Andreas Enge
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151021102706.339f0758@debian-netbook \
--to=efraim@flashner.co.il \
--cc=andreas@enge.fr \
--cc=guix-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.