On Tue, May 6, 2025 at 10:49 AM Steve George <[email protected]> wrote: > > Hi Greg, > > On 6 May, Greg Hogan wrote: > > On Sun, Mar 2, 2025 at 12:34 AM Maxim Cournoyer > > <[email protected]> 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).
