Hi Christopher,
Christopher Baines <m...@cbaines.net> 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.
> This shouldn't cause any problems for ci.guix.gnu.org (it hasn't when
> this has been tested in the past).
This was my main worry about deleting the branch, but based on what you
wrote above, I'll assume for now that it will not cause problems for
ci.guix.gnu.org.
> 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.
Best regards,
Mark
