[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.

From: Greg Hogan
Subject: [bug#43425] [PATCH] gnu: openblas: Update to 0.3.10.
Date: Fri, 18 Sep 2020 10:01:40 -0400


I was aware of the dependent-count triage but not fully understanding this process. When are commits made to staging (last commit was the merge 13 days ago) and/or core-updates (one commit since merge 4 days ago)? I see you were able to revert this commit to quiet the rebuilds, does this patch now go into core-updates or is it queued somewhere else? Is there a preferred time window for submitting highly-dependent revisions? I'm not seeing 'staging' or 'core-updates' annotations among the git logs.

How often is the documentation regenerated? I see the limits changed in the repo in June but the website has not been refreshed.

Is there a threshold for marking oneself in the copyright header? Such as, a simple version and checksum revision is not copyrightable but further changes must be marked?


On Fri, Sep 18, 2020 at 8:11 AM Mathieu Othacehe <> wrote:

> Thanks for the updated version. Yes I guess it can happen but it's less
> likely. I added your copyright and edited a bit the commit message
> before applying.

Turns out this patch causes 1912 package rebuilds. This is too much to
go to "master" branch.

This patch, as well as other patches you sent, such as the python
update, shall instead target "core-updates" branch as explained here:

When it's the case do not hesitate to explicitly add "core-updates" to
the patch title so that committers forgetting to run `guix refresh -l
package`, such as myself do not choose the wrong branch :).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]