Re: Emacs next variants

[Andrew Tropin]

On 2023-04-26 18:52, Mekeor Melire wrote:

> 2023-03-10 16:39 zimon.touto...@gmail.com:
>
>> As far I know, this branch does not contain the feature 
>> Tree-sitter. Instead, the feature Tree-sitter is in the branch 
>> "master", which will be branched later as Emacs 30 and somehow 
>> will be the next next release of Emacs.
>
> 2023-03-12 12:47 and...@trop.in:
>
>> Sure, I think [...] after emacs-30 release we will include 
>> tree-sitter in emacs package itself and also we will be able to 
>> move emacs-next-pgtk to emacs-pgtk.
>
> Emacs 29.1 will support tree-sitter. This mail-thread seems to 
> have been mislead by the wrong assumption that Emacs 30 will be 
> the first version to support tree-sitter.
>
> Feel free to check "etc/NEWS" within branch "emacs-29" of Emacs' 
> repository and correct me if I'm wrong: 
> https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29#n36

You are right, thank you for the note!  BTW, Liliana is working on Emacs
29 preparation right now and adjusting respective emacs packages here:

https://issues.guix.gnu.org/63984

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: About donation to GNU Guix project

[Leo Famulari]

On Sun, Jun 11, 2023 at 09:43:52PM -0400, Maxim Cournoyer wrote:
> Donating hardware is a bit tricky because it needs to be hosted
> somewhere, but it can be discussed and welcome, especially if the
> hosting can also be provided somehow (we have a couple machines running
> in people's home connecting via a WireGuard tunnel to the build farm
> from which we can get packages built via Cuirass).

+1

Donation of hosting may be more impactful than donating hardware.

Thanks for your interest!

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Leo Famulari]

On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
> I'm not sure how that'd work, since Git only allows a single PGP
> signature per commit, as far as I can tell.  When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are replaced with new ones generated from your key.

Is it so bad to re-sign commits on feature branches that we should lose
the easy-to-read history of rebased branches?

To me, it's much easier to understand and review a branch that has been
updated by rebasing rather than merging. I think that counts for a lot.
Do many people feel the same way?

Re-signing the commits is messy but I don't think there's even been a
consensus that it's very bad.

I think that re-signing commits while rebasing is consistent with our
security model which (as I understand it) considers committers' and their
machines to be trusted. And that the meaning of the signature is merely
that the committed changeset was definitively made by someone with the
key.

Re: Changes to the branching/commit policy

[Christopher Baines]

Christopher Baines  writes:

> The changes in #63459 have strayed now in to touching the commit policy
> [1]. My intent was to simplify the guidance by grouping it better, but I
> think the significant change here is that the commit policy now
> references the entire branching strategy, rather than just talking about
> sending patches for review.
>
> 1: 
> https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Policy
>
> That new branching strategy makes some "should" requirements on sending
> patches for review and pushing to topic branches for larger changes. It
> also makes a "must" requirement on opening guix-patches issues to track
> and manage merging branches.
>
> I'd like to merge these changes next week since they've been up for a
> few weeks, so do comment if you have any thoughts or if you'd like more
> time to review them.

I've now merged these changes as
0ea096ae23fa81f05ce97e5e61c15647c0a475ec.

You can now see the updated Commit Policy on the website [1] (you might
need to force a refresh), as well as the new section on managing patches
and branches [2].

1: 
https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Policy
2: 
https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

Thanks,

Chris


signature.asc
Description: PGP signature

Re: rust-build-system from antioxidant

[Development of GNU Guix and the GNU System distribution.]

Hi Vagrant,

On Mon, Jun 12, 2023 at 8:09 AM Vagrant Cascadian  wrote:
>
> everything kind of has a social component!

Thank you for pointing that out! Many technical discussions about
project governance claim high moral ground but remain incomplete.

Maxime possibly felt some righteous indignation because Maxim's
well-intended reference to consensus does not actually apply in Guix
that often. (I have to be careful to keep both your names in order.)
It would be ignorant to claim that there are no power structures.

Not all of them are official, but they are there. [1] Hierarchies are
human, and they are not always bad.

During the past year, I made some ambitious proposals that did not
resonate with the general public or any of the folks in power. (I am a
member of the general public.) Some committers told me privately that
nothing big happens without the maintainer collective.

Someone in the maintainer collective told me that nothing truly
important (like legal stuff) happens without Ludo'.

Of course, that expectation places an extraordinary burden on Ludo',
who already works very hard. I don't think he (or maybe "they") even
wants all that responsibility. Personally, I find Ludo' measured and
generous.

That being said, everyone makes mistakes. Sometimes, words are
misunderstood. At other times, the merit of an argument is overlooked.
Maybe that's what happened in the bug Maxime cited. Or maybe Maxime
made a mistake with that narrow, unfavorable and critical assessment.
Either way, it's important to have goodwill toward one another.

I know a little bit about how large groups can work together. For the
past nine years, I have been a minor city official in a bustling
community of 230,000 immigrants—mostly from India and China, with 158
languages spoken at home. The key is to keep solving the community's
problems and also, to solve other people's problems in addition to my
own.

In Jewish mysticism, there is an old story about a giant vessel that
once existed when the world was made. Unfortunately, it broke into a
gazillion pieces, and we each ended up with a little shard. We spend
the remainder of our lives looking for other pieces that fit.

Let's be proud of our large and diverse community. Let's focus on the
pieces that fit together. Thank you all for being here!

Kind regards
Felix

[1] https://guix.gnu.org/blog/2022/gnu-guix-maintainer-rotation/

Re: rust-build-system from antioxidant

[Vagrant Cascadian]

On 2023-06-11, Maxim Cournoyer wrote:
> Maxime Devos  writes:
>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>>> A few months ago, Maxime Devos worked on a new rust-build-system to
>>> handle a few issues we were experiencing with cargo (see discussions on
>>> antioxidant in guix-devel).
>>> A month ago, we discussed about the possibility of the integration
>>> in
>>> core guix, and the required steps. Maxime and I had a different
>>> approach. Maxime highlighted the possibility to make a smooth transition
>>> but once that would require many gradual changes and deprecation. My
>>> approach was that since we'll have to eventually migrate all packages to
>>> rust-build-system, and since we can freeze all former rust packages in
>>> an archive channel, I would be clearer to make the transition at once.
>>> [...]
>>
>> Actually, I started out with the non-gradual approach, but that was
>> overruled by Ludo', IIRC.
>
> Did you perhaps meant to say that it was disagreed with, or at worst
> "blocked by"?  There should not be a notion of 'overruling' in our
> contribution processes (unless the Guix co-maintainers have to step in
> as a last resort) if all participants strive to build consensus, as
> mentioned in info '(guix) Commit Access':
>
>It is expected from all contributors, and even more so from committers,
>to help build consensus and make decisions based on consensus.  To learn
>what consensus decision making means and understand its finer details,
>you are encouraged to read
>.
>
> I thought I knew what consensus meant myself, but the above link helped
> me to re-frame a few things in a way that is more conducive to building
> consensus.

A possible reframing that might be relevent here too that is maybe not
captured in the seedsforchange link referenced...

In a consensus decision (formal or informal), it is often really
valuable to not get caught up in "so-and-so is blocking X, Y, Z", but
rather more "this issue so-and-so raised is blocking X, Y, Z" or even
"this issue is blocking X, Y, Z". It is a perhaps subtle distinction,
but an important one, as I think it can refocus on a problem-solving
approach rather than finger-pointing-and-blaming approach.

That said, I definitely get the impression the Guix community practices
a very informal ad-hoc form of consensus, which ... while very flexible,
misses many of the strongest benefits of consensus (notably, clarity of
when a decision is actually reached and the next steps to move forward
with it).

A quick attempt at condensing a (more) formal consensus decision making
process boils down to:

* describe a situation, issue, proposal, etc.
* clarify understanding of the above (this step unfortunately
  may get skipped as people are very eagre to...)
* raise concerns
* address concerns (as a distinct step from raising concerns)
(iterate and repeat above steps as necessary)
* call for a decision (all concerns ideally resolved or mostly so.. ?)
* record decision (noting outstanding concerns if any)

I am not suggesting that a more formal process is even appropriate to
guix patch review...

Obviously, with the asyncronous nature of, say, a mailing list
discussion, these things do not necessarily happen in a structured
sequential way, though possibly being aware of the "ideal" formal
process, people can informally attempt to approximate it.

I do want to point out that informal processes are more prone to falling
into difficult patterns (e.g. defaulting to hierarchy or other power
dynamics), at least with the social aspects... I think this is a
collaborative project, so everything kind of has a social component!

We all fall down sometimes or lapse into old habits now and then, but
even if there is no formalized clarity of process, it is helpful to at
least reach towards the spirit of consensus building...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge  writes:

> Hello,
>
> Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner:
>> That was probably a misunderstanding. I meant to suggest with some
>> trepidation that 'master' is merged into the feature branch, and then
>> the feature branch is merged back into 'master'. I thought the two
>> merge commits would be signed by the person performing the merges
>> while the "origin seal" of the accepted change is also preserved.
>
> indeed, that is what we had been doing with the very long lived staging
> and core-updates branches in the past. Well, we used to repeatedly merge
> the master branch to core-updates, which if I remember well makes the
> master commits end up first in "git log". So the core-updates specific
> commits gradually disappear below thousands of master commits. So this is
> a problem.
>
> But Maxim is right about signatures, sorry for forgetting them time and
> again!
>
> One policy would be to *not* merge master back to the feature branch
> (or maybe just before merging the feature branch to master). This would
> work well for short-lived branches.

Yes, I think we should document as policy that there should be no merge
to the feature branches unless really necessary.  This will remove a lot
of noise from the commit history and keep things in the feature branch
focused.

-- 
Thanks,
Maxim

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Andreas Enge]

Hello,

Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner:
> That was probably a misunderstanding. I meant to suggest with some
> trepidation that 'master' is merged into the feature branch, and then
> the feature branch is merged back into 'master'. I thought the two
> merge commits would be signed by the person performing the merges
> while the "origin seal" of the accepted change is also preserved.

indeed, that is what we had been doing with the very long lived staging
and core-updates branches in the past. Well, we used to repeatedly merge
the master branch to core-updates, which if I remember well makes the
master commits end up first in "git log". So the core-updates specific
commits gradually disappear below thousands of master commits. So this is
a problem.

But Maxim is right about signatures, sorry for forgetting them time and
again!

One policy would be to *not* merge master back to the feature branch
(or maybe just before merging the feature branch to master). This would
work well for short-lived branches.

Andreas

Re: rust-build-system from antioxidant

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos  writes:

> Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:
>> Hi Maxime,
>> Maxime Devos  writes:
>> 
>>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
 A few months ago, Maxime Devos worked on a new rust-build-system to
 handle a few issues we were experiencing with cargo (see discussions on
 antioxidant in guix-devel).
 A month ago, we discussed about the possibility of the integration
 in
 core guix, and the required steps. Maxime and I had a different
 approach. Maxime highlighted the possibility to make a smooth transition
 but once that would require many gradual changes and deprecation. My
 approach was that since we'll have to eventually migrate all packages to
 rust-build-system, and since we can freeze all former rust packages in
 an archive channel, I would be clearer to make the transition at once.
 [...]
>>>
>>> Actually, I started out with the non-gradual approach, but that was
>>> overruled by Ludo', IIRC.
>> Did you perhaps meant to say that it was disagreed with, or at worst
>> "blocked by"?
>
> Yes.  Overruling is a form of blocking, and blocking by authority
> (whether de facto or de jure) is overruling.
>
>> There should not be a notion of 'overruling' in our
>> contribution processes (unless the Guix co-maintainers have to step in
>> as a last resort) if all participants strive to build consensus, as
>> mentioned in info '(guix) Commit Access':
>> It is expected from all contributors, and even more so from
>> committers,
>> to help build consensus and make decisions based on consensus.  To learn
>> what consensus decision making means and understand its finer details,
>> you are encouraged to read
>> .
>> I thought I knew what consensus meant myself, but the above link
>> helped
>> me to re-frame a few things in a way that is more conducive to building
>> consensus.
>

[...]

> For example, the thread of the patch you sent at
>  is a good example of this, pretty
> much everyone (except Ludo') agreed that the provided patch is good.

Let's avoid directly criticising ourselves and try to discuss what I
think has more value, which is coming to a better understanding of the
situation and how the perceived deadlock could be undone.  Consensus is
not a majority vote; all parties have to walk the extra mile to reach a
common ground.  I think the object there was from a semantic point of
view: we'd have a 'garbage collection' command (guix gc) which wouldn't
collect any garbage!  It's a valid objection, although its importance in
the narrow use case presented was not agreed by all parties.

A consensus-based outcome could be to add a new option to guix gc,
e.g. '--invalidate', which would be documented as "invalidate
(de-register from the Guix database) rather actually delete from the
store".  If that's still argued semantically unclear we could go with a
dedicated 'guix invalidate', although that seems overkill to me.

This is a bit more work than the 1 line change initially suggested, but
I think we can agree that'd be a more general/better solution.  Such is
the trade-off of consensus-based decision making (requires more
effort/slower moving but with a higher quality outcome).

-- 
Thanks,
Maxim

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Maxim Cournoyer]

Hi Felix,

Felix Lechner  writes:

> Hi Maxim,
>
> On Sun, Jun 11, 2023 at 5:48 PM Maxim Cournoyer
>  wrote:
>>
>> When you rewrite the
>> history (by using rebase, say), the existing signatures of the rewritten
>> (rebased) commits are replaced with new ones generated from your key.
>
> That was probably a misunderstanding. I meant to suggest with some
> trepidation that 'master' is merged into the feature branch, and then
> the feature branch is merged back into 'master'. I thought the two
> merge commits would be signed by the person performing the merges
> while the "origin seal" of the accepted change is also preserved.
>
> Please forgive me. I merely hoped to find common ground but apparently
> added confusion rather than clarity.

No worries, cheers!

-- 
Thanks,
Maxim

Re: rust-build-system from antioxidant

[Maxime Devos]

Op 12-06-2023 om 03:17 schreef Maxim Cournoyer:

Hi Maxime,

Maxime Devos  writes:


Op 02-06-2023 om 20:02 schreef Nicolas Graves:

A few months ago, Maxime Devos worked on a new rust-build-system to
handle a few issues we were experiencing with cargo (see discussions on
antioxidant in guix-devel).
A month ago, we discussed about the possibility of the integration
in
core guix, and the required steps. Maxime and I had a different
approach. Maxime highlighted the possibility to make a smooth transition
but once that would require many gradual changes and deprecation. My
approach was that since we'll have to eventually migrate all packages to
rust-build-system, and since we can freeze all former rust packages in
an archive channel, I would be clearer to make the transition at once.
[...]


Actually, I started out with the non-gradual approach, but that was
overruled by Ludo', IIRC.


Did you perhaps meant to say that it was disagreed with, or at worst
"blocked by"?


Yes.  Overruling is a form of blocking, and blocking by authority 
(whether de facto or de jure) is overruling.



There should not be a notion of 'overruling' in our
contribution processes (unless the Guix co-maintainers have to step in
as a last resort) if all participants strive to build consensus, as
mentioned in info '(guix) Commit Access':

It is expected from all contributors, and even more so from committers,
to help build consensus and make decisions based on consensus.  To learn
what consensus decision making means and understand its finer details,
you are encouraged to read
.

I thought I knew what consensus meant myself, but the above link helped
me to re-frame a few things in a way that is more conducive to building
consensus.


In my experience, Ludovic often doesn't actually practice that, though.
For example, the thread of the patch you sent at 
 is a good example of this, pretty 
much everyone (except Ludo') agreed that the provided patch is good.


People pointed out how Ludo' multiple time missed the point of the 
patch.  Yet, Ludo' kept missing the point, e.g. consider:


> [Liliana Marie prikler wrote on 18 jul 2022 19:03]

Am Montag, dem 18.07.2022 um 15:57 +0200 schrieb Ludovic Courtès:
Toggle quote (7 lines)

Hello,

With commit 472a0e82a52a3d5d841e1dfad6b13e26082a5750 (Nov. 2021),
partially fixing , there is
hopefully less pressure to skip the remove-unused-links phase.

Should we close this issue?

As a hard disk user, I'm leaning towards "no".  In fact, I recently
encountered a case where I think I might want to skip it even if not
deleting "specific items".  [...


> [Ludovic]

I agree that we should strive to have good performance on that kind of
hardware too, but I don’t know how to get there.


That's what the patch is for:

> [Liliana]
> [...]

I agree that we should strive to have good performance on that kind
of hardware too, but I don’t know how to get there.

I don't think deleting links will ever be fast on that disk.  But what
I've been saying the whole time is that I don't always need the links
deleted.  I think adding "expert" switches to skip these phases might
actually be enough – after all, if I ever do want to run a full GC, the
information ought to be the same, no?


[A remainder by me that Ludovic is missing the point]
[...] The point isn't to work-around slow "deleting unused links" 
implementation, but rather to avoid inherit slowness of deleting 
everything when deleting a few things suffice [...]

> [...]

Apologies for being elliptic.  My point here, as has been discussed
earlier in this thread, is that we can’t just skip that phase or we’d
simply leave files around without actually deleting them.


As repeatedly explained in different ways previously, we can, in fact, 
just do this and these consequences are unproblematic.  This is again 
explained in different ways in a response by Liliana and me.


Given that a few of the participants that wanted the patch in some form, 
are actually committers yet didn't commit it even though there was 
consensus, and that de facto Ludo' has authority and disagreed with the 
patch, the only conclusion I can draw from this, is that Ludo' 
effectively overruled the consensus with their (de facto) authority.


Whether this was intentional or not, the effect was the same.

(Technically ‘https://www.seedsforchange.org.uk/consensus#block’ allows 
for an unilateral block, but it later writes ‘However it provides a 
safety net for situations where a proposal would seriously hurt the 
group of people in it’, which doesn't apply at all here.)


This is not the antioxidant stuff, but it should serve as an explanation 
on why I do not believe that Ludovic practices consensus.  There are 
also a few other examples/threads that look suspect to me, but they are 
very ambiguous/not clear-cut.


Greetings,
Maxime.

quodlibet fails to build after python 3.10 update

[Remco van 't Veer]

Hi,

Forgotten patch:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63205#11

The supplied patch by Alice works and looks good to me.  Can somebody
please have a look and consider committing it?

Thanks!

Cheers,
Remco