Re: branch master updated (2bea3f2562 -> 6745d692d4)

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Christopher Baines]

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

guix-commits@gnu.org writes:

> rekado pushed a change to branch master
> in repository guix.
>
>     from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>      new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.

...

>      new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>      new 6f95883d01 FIXUP r-infercnv
>      new 1b6f915a88 gnu: r-rcppspdlog: Update to 0.0.17.

...

>      new babafe251c gnu: r-icellnet: Update to 2.2.1-1.e10ee4a.
>      new ba8d10c65a FIXUP r-bigmelon
>      new 6745d692d4 gnu: rcas-web: Update to latest commit.
>
> The 670 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

Were these changes meant to be pushed to master?

These changes from r-updates have effectively jumped the queue past
those on the core-updates and gnome-team branches, and since there was
never a "Request for merging" issue opened [1], the bordeaux build farm
is going to be delayed in building gnome-team as it tries to catch up
with master.

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

Also, there appears to be a couple of FIXUP commits that were pushed.

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

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Ricardo Wurmus]

Hi,

> guix-commits@gnu.org writes:
>
>> rekado pushed a change to branch master
>> in repository guix.
>>
>>     from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>>      new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.
>
> ...
>
>>      new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>>      new 6f95883d01 FIXUP r-infercnv
>>      new 1b6f915a88 gnu: r-rcppspdlog: Update to 0.0.17.
>
> ...
>
>>      new babafe251c gnu: r-icellnet: Update to 2.2.1-1.e10ee4a.
>>      new ba8d10c65a FIXUP r-bigmelon
>>      new 6745d692d4 gnu: rcas-web: Update to latest commit.
>>
>> The 670 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>
> Were these changes meant to be pushed to master?

Yes, they had been built on ci.guix.gnu.org in the r-updates jobset.

> These changes from r-updates have effectively jumped the queue past
> those on the core-updates and gnome-team branches, and since there was
> never a "Request for merging" issue opened [1], the bordeaux build farm
> is going to be delayed in building gnome-team as it tries to catch up
> with master.
>
> 1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

Oh, this is new to me.  I've just read it.  (Good to know also for the
upcoming merge of the python-team branch!)

My apologies for not following this process for r-updates.  I'm hearing
about this for the first time now.  (I hope the previous wip-python-team
didn't cause too many problems for bordeaux.)

> Also, there appears to be a couple of FIXUP commits that were pushed.

Yeah, it's very annoying that I missed these two FIXUP commits :-/

-- 
Ricardo

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Christopher Baines]

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

Ricardo Wurmus <rekado@elephly.net> writes:

>> These changes from r-updates have effectively jumped the queue past
>> those on the core-updates and gnome-team branches, and since there was
>> never a "Request for merging" issue opened [1], the bordeaux build farm
>> is going to be delayed in building gnome-team as it tries to catch up
>> with master.
>>
>> 1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
>
> Oh, this is new to me.  I've just read it.  (Good to know also for the
> upcoming merge of the python-team branch!)
>
> My apologies for not following this process for r-updates.  I'm hearing
> about this for the first time now.  (I hope the previous wip-python-team
> didn't cause too many problems for bordeaux.)

Is there anything you can think of that can be done to better
communicate about process changes in the future?

This is particularly relevant at the moment since there is a patch being
discussed [2].

2: https://issues.guix.gnu.org/70549

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

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Ricardo Wurmus]

Christopher Baines <mail@cbaines.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> These changes from r-updates have effectively jumped the queue past
>>> those on the core-updates and gnome-team branches, and since there was
>>> never a "Request for merging" issue opened [1], the bordeaux build farm
>>> is going to be delayed in building gnome-team as it tries to catch up
>>> with master.
>>>
>>> 1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
>>
>> Oh, this is new to me.  I've just read it.  (Good to know also for the
>> upcoming merge of the python-team branch!)
>>
>> My apologies for not following this process for r-updates.  I'm hearing
>> about this for the first time now.  (I hope the previous wip-python-team
>> didn't cause too many problems for bordeaux.)
>
> Is there anything you can think of that can be done to better
> communicate about process changes in the future?

Simon proposed an RFC process, which presumably would also result in
RFC-specific announcements separate from the deluge of emails on
guix-devel, which I cannot keep up with.

-- 
Ricardo

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[kiasoc5]

On 5/9/24 16:34, Ricardo Wurmus wrote:
> Hi,
> 
>> guix-commits@gnu.org writes:
>>
>>> rekado pushed a change to branch master
>>> in repository guix.
>>>
>>>      from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>>>       new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.
>>
>> ...
>>
>>>       new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>>>       new 6f95883d01 FIXUP r-infercnv
>>>       new 1b6f915a88 gnu: r-rcppspdlog: Update to 0.0.17.
>>
>> ...
>>
>>>       new babafe251c gnu: r-icellnet: Update to 2.2.1-1.e10ee4a.
>>>       new ba8d10c65a FIXUP r-bigmelon
>>>       new 6745d692d4 gnu: rcas-web: Update to latest commit.
>>>
>>> The 670 revisions listed above as "new" are entirely new to this
>>> repository and will be described in separate emails.  The revisions
>>> listed as "add" were already present in the repository and have only
>>> been added to this reference.
>>
>> ...
> 
>> Also, there appears to be a couple of FIXUP commits that were pushed.
> 
> Yeah, it's very annoying that I missed these two FIXUP commits :-/
> 

Seeing that these are the only 2 FIXUP commits on the master branch 
history so far, would it make sense to force push and edit the history? 
Yes, it would mess up everyone's local checkout, but if editing the 
history for Guix would ever be justified, I feel like this would be one 
such scenario.

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Tomas Volf]

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

On 2024-05-10 11:28:48 -0400, kiasoc5 wrote:
> > Yeah, it's very annoying that I missed these two FIXUP commits :-/
> >
>
> Seeing that these are the only 2 FIXUP commits on the master branch history
> so far, would it make sense to force push and edit the history? Yes, it
> would mess up everyone's local checkout

And *every* installation that already pulled those commits.  So it would affect
not only developers, but also users. At least as far I understand it.

> , but if editing the history for Guix
> would ever be justified, I feel like this would be one such scenario.

I do not believe that is a bridge that should be crossed, definitely not in this
case.  The commits look bit ugly, but practically speaking do little harm (in my
opinion).  Yes, they might break bisect, but so do other commits from time to
time.

We will just have to live with it.

But that is just like, my opinion. :)

Have a nice day,
Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

On Fri, May 10 2024, Ricardo Wurmus wrote:

> Christopher Baines writes:

> specific announcements separate from the deluge of emails on
> guix-devel, which I cannot keep up with.

As an alternative, I soon hope to offer a Debbugs clone that publishes
bug reports via NNTP.  Any news reader could then subscribe to bug
reports, which is currently not possible.  That should reduce the length
and frequency of discussions here to clerical pointers to any relevant
discussions.

> kiasoc5 writes:

> Seeing that these are the only 2 FIXUP commits on the master branch
> history so far, would it make sense to force push and edit the
> history?

I do not know what FIXUP commits are, but generally a Git history should
be broken only for inappropriate or illegal content, such as private
information or offensive imagery.

Kind regards
Felix

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Ricardo Wurmus]

kiasoc5 <kiasoc5@disroot.org> writes:

>>> Also, there appears to be a couple of FIXUP commits that were pushed.
>> Yeah, it's very annoying that I missed these two FIXUP commits :-/
>> 
>
> Seeing that these are the only 2 FIXUP commits on the master branch
> history so far, would it make sense to force push and edit the
> history? Yes, it would mess up everyone's local checkout, but if
> editing the history for Guix would ever be justified, I feel like this
> would be one such scenario.

I don't see how one would consider something as drastic as rewriting
history justified in this case.

The commits are not bad.  They are not wrong.  The opposite is the case:
they fix mistakes introduced by previous commits.  They only have the
wrong commit message, and they only have the wrong message because they
are so small that I had planned to meld them with the then unpublished
commits that introduced the bugs.

Rewriting history would be a colossal overreaction.  Instead these
commits should be a visible reminder that even contributors of many
thousand commits over the past decade may still fumble the ball and mess
up.  (Alas, this is not a reminder I personally need...)

-- 
Ricardo

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Attila Lendvai]

> I do not know what FIXUP commits are, but generally a Git history should

a fixup is just a regular commit that was meant to be squashed on another commit before pushing.

maybe the git hook could be extended to grep for 'fixup', 'squash me', 'KLUDGE', etc in the commit message?

not sure whether to stick only to the formal annotations added by programs, or use a more heuristic set of words and then ask for a y/n (if feasible from the hook).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Uniquely in us, nature opens her eyes and sees that she exists.”
	— Raymond Tallis (1946–)