Mark H Weaver <mhw@netris.org> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> There are quite a few branches on savannah, and it would be nice to
>> remove them if they're unnecessary, at least because that will prompt
>> the QA data service to delete the data, saving on disk space.
> [...]
>> The following branches all seem to have commits that haven't made it to
>> master yet, although I haven't checked if the changes were applied but
>> just with different commit ids.
>>
>>  - gnuzilla-updates
>
> The changes to 'gnuzilla-updates' were applied to 'master' but with
> different commit ids.
>
> In general, whenever there's an update to IceCat, which typically
> happens about once per month, I delete the 'gnuzilla-updates' branch and
> then immediately push a new one that is current 'master' plus the
> untested commit(s) for the IceCat update.  This triggers the
> 'gnuzilla-updates' jobset on ci.guix.gnu.org to build the new IceCat.
> Later, when I'm satisfied that the new IceCat works, I push the update
> to 'master' as separate commits.  Usually, the new commit(s) on 'master'
> are precisely the same as the ones on the 'gnuzilla-updates' branch
> except for the commit log message.
>
> If there's a better way to do this that does not entail much more work
> for me, please let me know.

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. This shouldn't cause
any problems for ci.guix.gnu.org (it hasn't when this has been tested in
the past).

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.

Thanks,

Chris