Mark H Weaver writes: > Hi Christopher, > > Christopher Baines writes: > >> I think the easy process change is to delete the gnuzilla-updates branch >> once you've pushed the chagnes to master. That should make it clearer >> that there's effectively nothing on that branch. > > Okay, I'll do that from now on. Awesome :) >> More generally, I think this is the kind of change that hopefully could >> be tested through QA. That would mean sending a patch series to >> guix-patches and then checking qa.guix.gnu.org for the results. Whether >> this would take more time or more work is another question though as QA >> has not been keeping up lately. > > For IceCat updates, which almost always include security fixes, it is > important to have very fast turnaround time on the test results. > ci.guix.gnu.org normally starts building the new IceCat within an hour > or so of the update being pushed to 'gnuzilla-updates', and usually > finishes the build within 4-5 hours. If, as you say, QA has not been > keeping up lately, then I'm not sure it will be fast enough for this use > case. > > Also, I'd like to maximize the likelihood that substitutes for IceCat > updates will be available *immediately* upon pushing them to 'master'. > That's another motivation for pushing them to a temporary branch that > ci.guix.gnu.org has been configured to build. > > Does that make sense? I admit that I haven't been following the > evolution of Guix development processes much in recent years, nor do I > know much about the new QA system. Please let me know if I have > misunderstood anything. Yep, what I'm trying to do with QA is bring some of this testing and substitute availability that you're doing for IceCat to all the patches that people send in. We're not quite there yet in terms of how fast the testing happens and how easy it is to understand the results, but things are getting better.