GNU bug report logs - #65130
Request for merging "elogind-updates" branch

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65130 in the body.
You can then email your comments to 65130 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: guix-patches <guix-patches <at> gnu.org>
Subject: Request for merging "elogind-updates" branch
Date: Mon, 07 Aug 2023 13:36:21 -0400

Hi,

I think this branch is ready to go.  I've tested a Guix System using it
on a x200 and it behaves correctly.

-- 
Thanks,
Maxim

Message #8 received at 65130 <at> debbugs.gnu.org (full text, mbox):

From: 宋文武 <iyzsong <at> envs.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 65130 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#65130: Request for merging "elogind-updates" branch
Date: Sun, 13 Aug 2023 13:41:10 +0800

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi,
>
> I think this branch is ready to go.  I've tested a Guix System using it
> on a x200 and it behaves correctly.

Hello, we currently have 3 request for merging (rust-team,
elogind-updates, kde-updates) now, should we do the merge in order by:

1. merge master into rust-team (if needed), wait it build, merge
   rust-team into master.
2. merge master into elogind-updates, then wait it build on CI, merge
   elogind-updates into master.
3. merge master into kde-updates, then wait it build on CI, merge
   kde-updates into master.
   
Or merge both rust-team, elogind-updates and master into kde-updates,
and merge it once into master?  Give changes in those 3 are isolated but
require rebuilding a lot, I think to merge them into master once can
save a little work for us and CI.

Thanks.

Message #11 received at 65130 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 65130 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#65130: Request for merging "elogind-updates" branch
Date: Sun, 13 Aug 2023 17:11:14 +0300

[Message part 1 (text/plain, inline)]

On Sun, Aug 13, 2023 at 01:41:10PM +0800, 宋文武 wrote:
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> 
> > Hi,
> >
> > I think this branch is ready to go.  I've tested a Guix System using it
> > on a x200 and it behaves correctly.
> 
> Hello, we currently have 3 request for merging (rust-team,
> elogind-updates, kde-updates) now, should we do the merge in order by:
> 
> 1. merge master into rust-team (if needed), wait it build, merge
>    rust-team into master.
> 2. merge master into elogind-updates, then wait it build on CI, merge
>    elogind-updates into master.
> 3. merge master into kde-updates, then wait it build on CI, merge
>    kde-updates into master.
>    
> Or merge both rust-team, elogind-updates and master into kde-updates,
> and merge it once into master?  Give changes in those 3 are isolated but
> require rebuilding a lot, I think to merge them into master once can
> save a little work for us and CI.

For the rust-team branch we have ~7500 packages for x86_64 and aarch64
and almost 0 for the other architectures. IIRC there are no non- rust-*
packages touched in this round of the rust-team branch. Based on my own
previous testing I'm not expecting any breakages of packages based on
the branch.  I have no issue with merging the rust-team with one or more
other branches in order to decrease the sheer number of CI builds.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 65130 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 65130 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#65130: Request for merging "elogind-updates" branch
Date: Sun, 13 Aug 2023 11:04:01 -0400

Hi,

宋文武 <iyzsong <at> envs.net> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Hi,
>>
>> I think this branch is ready to go.  I've tested a Guix System using it
>> on a x200 and it behaves correctly.
>
> Hello, we currently have 3 request for merging (rust-team,
> elogind-updates, kde-updates) now, should we do the merge in order by:
>
> 1. merge master into rust-team (if needed), wait it build, merge
>    rust-team into master.
> 2. merge master into elogind-updates, then wait it build on CI, merge
>    elogind-updates into master.
> 3. merge master into kde-updates, then wait it build on CI, merge
>    kde-updates into master.
>    
> Or merge both rust-team, elogind-updates and master into kde-updates,
> and merge it once into master?  Give changes in those 3 are isolated but
> require rebuilding a lot, I think to merge them into master once can
> save a little work for us and CI.

Since rust-team is already mostly built at this point, I'd merge it
as-is.

I think we should keep the branch separated to preserve as much insights
into new failures as we can from the QA tooling.

-- 
Thanks,
Maxim

Message #17 received at 65130 <at> debbugs.gnu.org (full text, mbox):

From: 宋文武 <iyzsong <at> envs.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 65130 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#65130: Request for merging "elogind-updates" branch
Date: Mon, 14 Aug 2023 17:49:56 +0800

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi,
>
> 宋文武 <iyzsong <at> envs.net> writes:
>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>
>>> Hi,
>>>
>>> I think this branch is ready to go.  I've tested a Guix System using it
>>> on a x200 and it behaves correctly.
>>
>> Hello, we currently have 3 request for merging (rust-team,
>> elogind-updates, kde-updates) now, should we do the merge in order by:
>>
>> 1. merge master into rust-team (if needed), wait it build, merge
>>    rust-team into master.
>> 2. merge master into elogind-updates, then wait it build on CI, merge
>>    elogind-updates into master.
>> 3. merge master into kde-updates, then wait it build on CI, merge
>>    kde-updates into master.
>>    
>> Or merge both rust-team, elogind-updates and master into kde-updates,
>> and merge it once into master?  Give changes in those 3 are isolated but
>> require rebuilding a lot, I think to merge them into master once can
>> save a little work for us and CI.
>
> Since rust-team is already mostly built at this point, I'd merge it
> as-is.
>
> I think we should keep the branch separated to preserve as much insights
> into new failures as we can from the QA tooling.

Okay, then I'll wait rust-team and elogind-updates to be merged first.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.