Re: 02/02: gnu: libidn: Update to 1.30.

Re: 02/02: gnu: libidn: Update to 1.30.

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> commit 8462a03f2861a1b3ed33e99a6f5a886bb9093846
> Author: Andreas Enge <andreas@enge.fr>
> Date:   Tue Apr 21 22:59:50 2015 +0200
>
>     gnu: libidn: Update to 1.30.
>     
>     * gnu/packages/libidn.scm (libidn): Update to 1.30.

I reverted this because it triggered over 1330 rebuilds, and as far as I
can tell there is nothing particularly urgent or compelling in this
update.  Therefore, I think it belongs in core-updates or some other
branch.  Does that make sense?

     Thanks,
       Mark

Re: 02/02: gnu: libidn: Update to 1.30.

[Andreas Enge]

On Tue, Apr 21, 2015 at 05:53:56PM -0400, Mark H Weaver wrote:
> I reverted this because it triggered over 1330 rebuilds, and as far as I
> can tell there is nothing particularly urgent or compelling in this
> update.  Therefore, I think it belongs in core-updates or some other
> branch.  Does that make sense?

Good question. I pushed it at a time where none of our build slaves was doing
any work and thought it was a good way of occupying them. "guix refresh -l"
showed only 250 rebuilds, which, multiplied by 3 architectures, would have
given 750. It would be nice if "guix refresh -l" could be made to determine
the correct number.

Could we agree on a formal guideline of what can go into master and what
needs to go into core-updates? So far, the only official reason to use
core-updates was when touching base packages.

Should we add some limit of rebuilds? "guix refresh -l" shows less than
100 packages or so? (Then one can still use common sense depending on
the charge on hydra to renounce at a commit at a bad moment.)

Andreas