Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

Hi Guixers,

Andreas' detailed a nice workflow for reviewing patches in a previous thread*:

```
git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-xxxxx
git format-patch ...
then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build
```

I noticed that there is one issue with this approach after trying it.

Old tickets are not kept around.

For example, A branch for ticket 51810* does not exist anymore.

But that ticket is still open 🙃

Hi Christopher,

Would it be possible to keep around branches for any open tickets?

Should stale tickets like 51810 be automatically closed so that git.guix-patches.cbaines.net* gets comprehensive coverage of ticket/branch pairings?

best,

jgart

* https://lists.gnu.org/archive/html/guix-devel/2023-08/msg00158.html
* https://issues.guix.gnu.org/51810
* https://git.guix-patches.cbaines.net/guix-patches/

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[Andreas Enge]

Hello jgart,

Am Mon, Sep 04, 2023 at 05:48:05PM +0000 schrieb jgart:
> Old tickets are not kept around.
> For example, A branch for ticket 51810* does not exist anymore.

this is probably due to the fact that the git repo did not yet exist
at the time. The oldest issue I see is 60286 from December 2022, which
looks compatible with this hypothesis.

So this patch fell completely through the cracks! We should indeed
spend some time going through old tickets (this, for instance, at first
glance looks like it could be applied, others may simply be dropped).

Andreas

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

>> Old tickets are not kept around.

Hi,

Oh ok, old tickets were never included instead of old tickets being deleted.

I'm not familiar with this code yet.

Thanks for the clarification.

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[Christopher Baines]

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


"jgart" <jgart@dismail.de> writes:

> Hi Guixers,
>
> Andreas' detailed a nice workflow for reviewing patches in a previous thread*:
>
> ```
> git clone https://git.guix-patches.cbaines.net/guix-patches/
> git checkout issue-xxxxx
> git format-patch ...
> then in the development checkout of Guix:
> git am ...; make; ./pre-inst-env guix build
> ```
>
> I noticed that there is one issue with this approach after trying it.
>
> Old tickets are not kept around.
>
> For example, A branch for ticket 51810* does not exist anymore.
>
> But that ticket is still open 🙃
>
> Hi Christopher,
>
> Would it be possible to keep around branches for any open tickets?

Yes and no.

Currently the QA frontpage creates branches for the latest 350 [1] patch
series, and it'll remove them if they slip outside of the latest 350.

1: https://git.cbaines.net/guix/qa-frontpage/tree/scripts/guix-qa-frontpage.in#n238

Increasing that number is possible, but not really feasible at the
moment since the branch existing feeds in to data.qa.guix.gnu.org
potentially keeping data around for that revision, which has a cost in
disk space, and beid (the machine running data.qa.guix.gnu.org) is
really low on disk space at the moment (23G available out of 338G).

There's also an ongoing cost in that the QA frontpage tries to reapply
patches when big changes happen in the master branch, which involves
more work for the data serivce the more branches you're trying to
manage.

Having more hardware for data.qa.guix.gnu.org, and speeding it up would
help. Another approach would be to have the QA frontpage push these
older patch branches with a slightly different name (that the data
service would ignore), or push them to a different remote. That would
mean that the branch would still be somewhere, but the data service
would ignore it.

> Should stale tickets like 51810 be automatically closed so that
> git.guix-patches.cbaines.net* gets comprehensive coverage of
> ticket/branch pairings?

I don't think automatically closing older issues is helpful, they still
need looking at.

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

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

[jgart]

> I don't think automatically closing older issues is helpful, they still
> need looking at.

Or instead of closing them, put the patch into a state that is not open. Like an archived state or some other state that does not require action until someone takes ownership of the issue and resolves it.

I think this can prevent being overwhelmed by the number of open issues that are not high priority, lack reviewers, or are so grossly outdated and that they require completely starting from scratch in order to work on it.