John Kehayias writes: >>> Or does the section about branch building for once patches are pushed >>> to a branch on Savannah? >> >> I'm not sure what you're asking here. > > I'm confused myself over my wording, but I remember what I was trying > to get at: > > Currently QA doesn't build patches if they cause a large number of > rebuilds correct? So for building a branch that requires this, will > that only happen on Cuirass with a new jobspec for the branch? Or will > this be addressed through changes to how QA builds? (Maybe this > answered below actually.) Yep, for issues there's a cap of 300 builds per system. QA does build the branch at the front of the queue to be merged though, currently that's ruby-team [1]. 1: https://qa.guix.gnu.org/ >>> Does that mean pushing to a branch should follow the same 1-2 week >>> review allowing QA builds? I guess patch series are always built >>> together on QA but wondering if there is anything else to be aware of >>> or needs mentioning to keep things tidy and clear. >> >> Those durations mentioned in the commit policy [1] are intended to allow >> for human review. For QA, it doesn't need to be time based as it can >> report it's progress. Obviously it does need a bit of time to check >> things, but I prefer to leave it up to people to assess the changes and >> any information provided by QA and decide when it's appropriate to push. >> >> 1: >> > > A separate issue which I wanted to get at was about pushing changes to > any branch on Savannah. Do we expect those to be at the same state as > anything that would go directly to master, just pending the testing of > builds basically? So, after the usual review period? Or can those be > more WIP and not polished yet? I suppose this is for a team/people > working on a branch to discuss and how it will then be merged to > master. The latter. Non-master branches can be in whatever state is useful. >> On keeping things clear, I think with branches I'm hoping the issue >> tracker can help with this, which is why there's now a strong >> requirement to create a guix-patches issue when you want to merge a >> branch, and use those issues to manage the timing. >> >> For those issues, there's currently a convention of using the following >> title: `Request for merging "XXXX" branch` e.g. [2]. That helps QA find >> these issues and act accordingly, but of course if someone comes up with >> a better way of naming these issues, we can just adjust the code in the >> qa-frontpage. >> > > I see, that's a nice way to then group up discussion if a branch has a > bunch of separate patch threads. Looks like a good idea! > > So, to be concrete, with the mesa patch I just sent, > I can open a merge request issue for > QA to process the branch, once the branch is actually created on > Savannah? I assume with the pretty trivial version change here I could > do that to see how the builds go, but I'll hold off pending the thread > I just started about this branch/team. Currently QA just builds the branch at the front of the queue, but yes.