Subject: Re: bug#76640: Request for merging games-updates branch

From: Greg Hogan <[email-masked]>
Date: Tue, 6 May 2025 11:29:16 -0400

On Tue, May 6, 2025 at 10:49 AM Steve George <[email-masked]> wrote:
>
> Hi Greg,
>
> On  6 May, Greg Hogan wrote:
> > On Sun, Mar 2, 2025 at 12:34 AM Maxim Cournoyer
> > <[email-masked]> wrote:
> (...)
> > > Since they are leaf packages, if they build and run fine (and ideally
> > > have been reviewed), I'd say go for it!
> (...)
> > Is QA able to process this branch, which has not been rebased since
> > the end of February? Also, these patches should have been (and still
> > could be) applied directly to master. From the manual [0]:
> >
> > The QA infrastructure recognizes such issues and lists the merge
> > requests on its main page. The following points apply to managing
> > these branches:
> > [...]
> > 2. Any changes that can be made on the master branch, should be made
> > on the master branch. If a commit can be split to apply part of the
> > changes on master, this is good to do.
> > [...]
> >
> > [0] https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
>
> I was hoping QA would process them eventually, but it never gets there due to our hardware constraints. So I'll apply them directly to master and get rid of the branch.
>
> I appreciate the manual says to do things on master, but I personally don't like it - I'd like to build on a feature branch, have QA confirm I haven't messed anything up (plus get substitutes) and then put the successful branch onto master. That feels safer to me - but yeah, our QA/CI infrastructure isn't sufficient.
>
> Thanks for the interest!
>
> Steve / Futurile

I wholeheartedly agree. Would having a games-team specification on CI
serve a similar purpose? That cluster seems more able to keep up (and
currently mostly idle).