guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature branches


From: Maxim Cournoyer
Subject: Re: Feature branches
Date: Wed, 10 May 2023 09:23:11 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Mon, May 08, 2023 at 01:01:05PM -0400 schrieb Maxim Cournoyer:
>> - I'd make the team branches permanent; e.g. the 'gnome-team' branch
>>   would always exist, and get synced periodically to master (when enough
>>   built/deemed stable).  This should reduce the overhead of constantly
>>   having to adjust the Cuirass specification jobs and serve as an
>>   integration point for the team (the Cuirass job specs would be defined
>>   declaratively in the guix-maintenance repository).
>
> I would argument the other way round :)  For instance, I would now remove
> the rust-team branch so that it is clear that currently there is no work
> on rust. As soon as there is again, the team could spin off a new branch
> from master. This would avoid having branches around of which we do not
> know any more what they contain, and whether they contain unmerged changes.

My worry here would be to introduce the overhead of having to
continually adjust the Cuirass job specs either via the web interface or
declaratively via git.  But perhaps it's already possible to have it
build all the branches matching a regexp, such as '-team$' ?  That would
solve the issue.

> $ git branch -a | grep rust
>   remotes/origin/rekados-rust-queue
>   remotes/origin/rust-team
>   remotes/origin/wip-cross-built-rust
>   remotes/origin/wip-rekado-rust-team
>   remotes/origin/wip-rust
>
> Can any of these be removed? Or brought up to shape?

Feel free to remove 'wip-cross-built-rust'; I don't intend to work on
this anymore (I hit a wall where rust could not be statically built
using cargo, how ironic, it had something to do with the way macros are
implemented in Rust).

> Notice that this is independent of the cuirass specifications (I think).
> I think we could keep the specifications on cuirass, but am not totally
> sure what happens when the branch does not exist. Probably nothing. And
> then it should be picked up again once it is recreated.

We'd have to try, I would assume it may cause errors in Cuirass (it'd
make sense that it let you know: hey, you've defined a job spec that
won't build anything!)

-- 
Thanks,
Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]