GNU bug report logs - #76640
Request for merging "games-updates" branch

Previous Next

Full log

Message #16 received at 76640 <at> debbugs.gnu.org (full text, mbox):

From: Steve George <steve <at> futurile.net>
To: Greg Hogan <code <at> greghogan.com>
Cc: 76640 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#76640: Request for merging games-updates branch
Date: Tue, 6 May 2025 15:48:48 +0100

Hi Greg,

On  6 May, Greg Hogan wrote:
> On Sun, Mar 2, 2025 at 12:34 AM Maxim Cournoyer
> <maxim.cournoyer <at> gmail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.