unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Guix and Continuous Integration (CI)
@ 2019-02-01 17:05 Christopher Baines
  2019-02-22 15:23 ` Pjotr Prins
  0 siblings, 1 reply; 2+ messages in thread
From: Christopher Baines @ 2019-02-01 17:05 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

So, it might be good to have a discussion about "continuous
integration", what this means, and how it applies to Guix.

I believe the term comes from the field of software development, as a
practice, it has multiple components, but I think the most significant
one comes from the name. When practising continuous integration with
software, you should continuously integrate your changes (patches),
normally this means you promptly merge all the different changes
together in your version control system.

This practice is utilised for a large proportion of changes to Guix,
they are merged to the master branch. However, the way the staging and
core-updates branches are used is an example of not following
"continuous integration". Changes can wait for a while before being
merged in to the master branch.

It seems to me that continuous integration is a related concept, but
separate to the building things (packages/system tests/...). When
thinking about continuous integration, it might be good to think about
what the ideal workflow would be for Guix changes, assuming for a moment
that the "building things" situation was perfect.

Currently, changes are held in core-updates and staging so that
substitutes can be built, but if you can build substitutes as fast as
you want, I think there would still be advantages for batching the
changes. Imagine if the changes that would go in to core-updates go in
to master, even if there are substitutes are available, it could result
in Guix users having to download large amounts of substitutes, and
depending on the change, some proportion of these changes may be
redundant as the change to the derivation wouldn't have altered the
behaviour of the software.

Therefore, for changes that affect a large number of derivations without
much functional impact on most of those affected derivations, it would
reduce the impact to batch those changes somewhat.

Anyway, there are some thoughts,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Guix and Continuous Integration (CI)
  2019-02-01 17:05 Guix and Continuous Integration (CI) Christopher Baines
@ 2019-02-22 15:23 ` Pjotr Prins
  0 siblings, 0 replies; 2+ messages in thread
From: Pjotr Prins @ 2019-02-22 15:23 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel

I am looking at https://man.sr.ht/. It is an interesting service which
may work for some of the stuff I am doing. They are supporting Nix and
they would like Guix support. 

https://mastodon.technology/@pjotrp/101634719348057236

I am particularly interested in providing containers for testing
software that we are writing and for running (bioinformatics)
workflows on demand. Not sure how it all will take shape, but I am
clear where I want to be at some point ;)

Pj.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-02-22 15:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-01 17:05 Guix and Continuous Integration (CI) Christopher Baines
2019-02-22 15:23 ` Pjotr Prins

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).