Hi Andreas,
Andreas Enge writes:
> Am Wed, May 10, 2023 at 03:40:31PM +0200 schrieb Andreas Enge:
>> I just deleted the rust-team branch, we will see what happens.
>
> Apparently nothing. Here is an excerpt of /var/log/cuirass.log:
> 2023-05-10 15:44:10 Fetching channels for spec 'gnuzilla-updat
Am Wed, May 10, 2023 at 03:40:31PM +0200 schrieb Andreas Enge:
> I just deleted the rust-team branch, we will see what happens.
Apparently nothing. Here is an excerpt of /var/log/cuirass.log:
2023-05-10 15:44:10 Fetching channels for spec 'gnuzilla-updates'.
2023-05-10 15:44:19 Fetching channels f
Am Wed, May 10, 2023 at 09:23:11AM -0400 schrieb Maxim Cournoyer:
> Feel free to remove 'wip-cross-built-rust'
Done!
> 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!)
I just dele
Hi Andreas,
Andreas Enge 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 sho
Andreas Enge writes:
> Am Mon, May 08, 2023 at 10:15:56AM -0700 schrieb Felix Lechner:
>> How about requiring prior to merging a feature branch that substitutes
>> exist for all changed derivations? It would prevent build failures and
>> preempt local builds, and thereby improve the experience f
ed to be
> authorized as can be done following
> https://issues.guix.gnu.org/63375).
> I don't think team branches should be merged together at any point,
> ideally, to avoid loosing the benefits of feature branches (limited
> scope).
Agreed, if we start branching from branches
Am Mon, May 08, 2023 at 10:15:56AM -0700 schrieb Felix Lechner:
> How about requiring prior to merging a feature branch that substitutes
> exist for all changed derivations? It would prevent build failures and
> preempt local builds, and thereby improve the experience for average
> users.
Taken ab
Hi,
On Mon, May 8, 2023 at 9:34 AM Andreas Enge wrote:
>
> This does not yet explain how the branches interact with continuous
> integration.
How about requiring prior to merging a feature branch that substitutes
exist for all changed derivations? It would prevent build failures and
preempt loca
is does not solve the problem of limited build power in our
> two build farms. Having feature branches that regroup several related
> changes should help in not rebuilding too often. In principle it could
> also be okay to regroup unrelated changes (mesa and gcc, for instance),
> as long
farms. Having feature branches that regroup several related
changes should help in not rebuilding too often. In principle it could
also be okay to regroup unrelated changes (mesa and gcc, for instance),
as long as responsibilities are clear. It should be known who is going
to act on what when
On Mon, Feb 13, 2023 at 03:07:58PM +0100, Andreas Enge wrote:
> Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> > 4. staging merge happens, and the branch gets deleted.
>
> I failed to compile my profile on staging, since rust-rav1e, a dependency
> of ffmpeg, failed to build; s
Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> 4. staging merge happens, and the branch gets deleted.
I failed to compile my profile on staging, since rust-rav1e, a dependency
of ffmpeg, failed to build; see bug #61475.
Andreas
Hi,
On Sun, 12 Feb 2023 at 22:13, Josselin Poiret wrote:
> 1. Document this workflow in the manual, in a dedicated node, with a
>rationale as well. One thing worth mentioning would be how to handle
>grafting/ungrafting now. Also remove the staging/core-updates
>criterion.
Maybe it
Hello Josselin,
Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> For a potential roadmap (doesn't have to be sequential):
> 1. Document this workflow in the manual, in a dedicated node, with a
>rationale as well. One thing worth mentioning would be how to handle
>grafti
stead of a hodgepodge of unrelated patches that no one wants to
debug. These feature branches would be managed by teams, with one person
from the team being responsible for the feature and it getting merged
into master. Those features could be ephemeral or long-running and each
team would be fr
15 matches
Mail list logo
