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

[Greg Hogan <code@greghogan.com>]

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

Mathieu,

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?

Greg

On Fri, Sep 18, 2020 at 8:11 AM Mathieu Othacehe <othacehe@gnu.org> 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:
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html.
>
> 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 :).
>
> Thanks,
>
> Mathieu
>

[-- Attachment #2: Type: text/html, Size: 2279 bytes --]