From: ludo@gnu.org (Ludovic Courtès)
To: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: wip-refactor-emacs-ui and Hydra interface
Date: Mon, 21 Dec 2015 22:16:49 +0100 [thread overview]
Message-ID: <87egefijsu.fsf@gnu.org> (raw)
In-Reply-To: <8760zv4mhz.fsf@gmail.com> (Alex Kost's message of "Fri, 18 Dec 2015 21:53:12 +0300")
[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]
Alex Kost <alezost@gmail.com> skribis:
> Ludovic Courtès (2015-12-18 01:23 +0300) wrote:
>
>> Hi Alex!
>>
>> Sorry for the late reply. I wanted to take the time to sit back, relax,
>> and enjoy the new stuff… and I haven’t been disappointed! :-)
>
> Great, thanks for giving your time to this!
>
>> This is awesome. Some queries seem to take longer on Hydra than others
>> (for instance, getting the list of builds of a given jobset is slow,
>> whereas getting the list of latest builds, queued builds, etc. is pretty
>> fast.)
>
> Yes, I also noticed that processing complex queries takes longer time.
> Perhaps SQL queries that stand behind this Hydra API are not efficient,
> dunno :-)
>
>> Perhaps one small improvement would be to add links from Package Info
>> buffers to the corresponding Guix Hydra Build Info?
>
> Do you mean a button that will do the same as "B" key in "Package List"?
>
> Anyway, I think eventually I'll add more various buttons to "Package
> Info" buffers (like "Hydra Builds", "Build Log", "Size", "Graph"), and
> more keys to "Package List" buffers for the same things.
>
>> I haven’t looked at the code yet, but it’s your area of expertise and
>> I’m confident. :-) I skim over it when you think it’s ready; are there
>> parts you’d like to be reviewed more carefully?
>
> Well, I always feel uncomfortable with commit messages. But I think the
> main part that should be reviewed is documentation (in commit 731f5e4).
So, regarding the documentation:
+@node Emacs Hydra
+@section Hydra
+
+Guix also provides an interface for @code{hydra.gnu.org} (Guix build
+farm) that allows to display Hydra builds and jobsets. This interface
+is mostly the same as the ``list''/``info'' interface for displaying
+packages and generations (@pxref{Emacs Package Management}).
I would suggest adding a bit of context, like this:
The continuous integration server at @code{hydra.gnu.org} builds all
the distribution packages on the supported architectures and serves
them as substitutes (@pxref{Substitutes}). Continuous integration is
currently orchestrated by @uref{https://nixos.org/hydra/, Hydra}.
This section describes an Emacs interface to query Hydra to know the
build status of specific packages, discover recent and ongoing builds,
view build logs, and so on. This interface is mostly the same as …
WDYT?
I would also add a cross-reference like:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 779 bytes --]
diff --git a/doc/guix.texi b/doc/guix.texi
index 06d70ba..bf523aa 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1568,7 +1568,9 @@ also result from derivation builds, can be available as substitutes.
The @code{hydra.gnu.org} server is a front-end to a build farm that
builds packages from the GNU distribution continuously for some
-architectures, and makes them available as substitutes. This is the
+architectures, and makes them available as substitutes (@pxref{Emacs
+Hydra}, for information on how to query the continuous integration
+server). This is the
default source of substitutes; it can be overridden by passing the
@option{--substitute-urls} option either to @command{guix-daemon}
(@pxref{daemon-substitute-urls,, @code{guix-daemon --substitute-urls}})
[-- Attachment #3: Type: text/plain, Size: 677 bytes --]
> As for the changes in code, they are huge (and I would say
> "unskimmable"), and I think no one will want to look at them :-)
Well, yeah. :-)
>> Anyway, let me know what you think and how you’d like to proceed.
>
> OK, I have done some final changes and rebased the branch on master, so
> (from my point of view) it is ready for merging. Should I spam the list
> with these (37) patches?
I don’t think so. :-)
AFAICS only elisp code is touched, and the rest of the Emacs code is
supposed to be functionally equivalent, right?
I’m tempted to punt on this one and let you push the whole series.
What do people think?
Thank you!
Ludo’.
next prev parent reply other threads:[~2015-12-21 21:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 11:45 wip-refactor-emacs-ui and Hydra interface Alex Kost
2015-12-17 22:23 ` Ludovic Courtès
2015-12-18 18:53 ` Alex Kost
2015-12-21 21:16 ` Ludovic Courtès [this message]
2015-12-29 8:52 ` Alex Kost
2015-12-30 15:40 ` Ludovic Courtès
2015-12-29 9:02 ` Alex Kost
2015-12-30 15:40 ` Ludovic Courtès
2015-12-31 20:09 ` Alex Kost
2016-01-01 15:53 ` Ludovic Courtès
2016-01-02 14:27 ` Alex Kost
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=87egefijsu.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=alezost@gmail.com \
--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.