unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Andreas Enge <andreas@enge.fr>
Cc: Christopher Baines <mail@cbaines.net>,  guix-devel@gnu.org
Subject: Re: Feature branches
Date: Wed, 10 May 2023 09:23:11 -0400	[thread overview]
Message-ID: <87lehwqq0w.fsf@gmail.com> (raw)
In-Reply-To: <ZFtiDCQ7BAQPwUQ0@jurong> (Andreas Enge's message of "Wed, 10 May 2023 11:21:16 +0200")

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	other threads:[~2023-05-10 13:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <168347913021.32190.10808857919894440138@vcs2.savannah.gnu.org>
     [not found] ` <20230507170531.26A00C22F14@vcs2.savannah.gnu.org>
2023-05-08  1:41   ` 04/09: gnu: mesa: Update to 23.0.3 Christopher Baines
2023-05-08 12:08     ` Maxim Cournoyer
2023-05-08 12:56       ` Christopher Baines
2023-05-08 15:01         ` Maxim Cournoyer
2023-05-08 16:33           ` Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3) Andreas Enge
2023-05-08 17:01             ` Feature branches Maxim Cournoyer
2023-05-10  9:21               ` Andreas Enge
2023-05-10 13:23                 ` Maxim Cournoyer [this message]
2023-05-10 13:40                   ` Andreas Enge
2023-05-10 13:55                     ` Andreas Enge
2023-05-11  4:49                       ` Maxim Cournoyer
2023-05-08 17:15             ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-05-10  9:11               ` Andreas Enge
2023-05-10 11:30                 ` Christopher Baines
2023-05-08 16:39           ` 04/09: gnu: mesa: Update to 23.0.3 Christopher Baines
2023-05-09  4:37     ` John Kehayias
2023-05-09  8:39       ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lehwqq0w.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).