Cleaning up branches on savannah

Cleaning up branches on savannah

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

Hey,

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.

I'm ignoring all the version-* and wip-* branches, which leaves the
following sets of branches.

These relate to core-updates, so can be deleted once core-updates is
merged:

 - core-updates
 - core-updates-glibc-2.39
 - old-core-updates

These branches are waiting to be merged as well:

 - tex-team
 - lisp-team
 - python-team

Most of the changes on guile-dameon are in #70494, maybe I'll rename the
branch to wip-guile-daemon though:

 - guile-daemon

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
 - go-team
 - haskell-team
 - hurd-team
 - install-doc-overhaul
 - kernel-updates
 - node-18-updates
 - node-reproducibility
 - old-guix-wip-file-offset-bits-64-sledgehammer
 - r-team
 - r-updates
 - rust-team

If anyone knows if any of these branches can be deleted, please go
ahead. If they do want merging, please open a "Request for merging"
issue. For the ones that still have changes, but we're not looking to
merge right now, I think the easist thing to do is rename them adding
the wip- prefix.

Beyond saving QA data service disk space, this should put us in a good
situation where all the non wip- branches are things that there are open
guix-patches "Request for merging" issues [1].

1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

Any thoughts?

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Cleaning up branches on savannah

[Lars-Dominik Braun]

Hi Christopher,

> 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.
> 
>  - haskell-team

I will open a request to merge this branch after I updated to the latest
possible Stackage release, which is hopefully soon™.

Lars

Re: Cleaning up branches on savannah

[Mark H Weaver]

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.

      Thanks,
        Mark

Re: Cleaning up branches on savannah

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Cleaning up branches on savannah

[Mark H Weaver]

Hi Christopher,

Christopher Baines <mail@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

Re: Cleaning up branches on savannah

[Andreas Enge]

Hello Mark,

Am Tue, Jun 11, 2024 at 11:16:59AM -0400 schrieb Mark H Weaver:
> 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.

concerning the second paragraph, this will also be the case for going
through QA: It will build the package on the bordeaux build farm, the
substitutes of which are now activated by default on Guix installations.

For the first part, I would still recommend to go with cuirass on berlin,
as it has more build power, and apparently picks up the Icecat build
much faster.

Andreas

Re: Cleaning up branches on savannah

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

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

> Hi Christopher,
>
> Christopher Baines <mail@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.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Cleaning up branches on savannah

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> 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
>  - go-team
>  - haskell-team
>  - hurd-team
>  - install-doc-overhaul
>  - kernel-updates
>  - node-18-updates
>  - node-reproducibility
>  - old-guix-wip-file-offset-bits-64-sledgehammer
>  - r-team
>  - r-updates
>  - rust-team
>
> If anyone knows if any of these branches can be deleted, please go
> ahead. If they do want merging, please open a "Request for merging"
> issue. For the ones that still have changes, but we're not looking to
> merge right now, I think the easist thing to do is rename them adding
> the wip- prefix.

I've added wip- prefixes to the following 4 branches now, mostly as
these were the oldest ones processed by data.qa:

 - go-team
 - node-reproducibility
 - node-18-updates
 - r-team

Maybe we can look again at the other branches once the merge backlog has
gone down a bit.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]