Re: Teams

[Andrew Tropin]

On 2022-06-05 10:19, Josselin Poiret wrote:

> Hello everyone,
>
> Ricardo Wurmus  writes:
>
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.
>
> I think an installer team would be good too (which I would gladly join).
> WDYT of the following teams:
> * Installer (which I'd gladly join);
> * System;
> * Home;
> * Internals?
>
> Maybe that would add too many teams, but I think the first three could
> be pretty useful.
>
> How do we automatically make Mumi understand which team a patch should
> notify?  I've just started using public-inbox/lei and the `dfn:` search
> term is pretty useful, it lets you select only patches that change
> specific files.  For example, `dfn:gnu/installer*` would match all
> patches that touch the installer.
>
> Best,

I'm not in a guix-maintainers yet, but I would like to join Home team.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

«Reproducibility vs. Replicability: A Brief History of a Confused Terminology»

[zimoun]

Hi,

On Sun, 12 Jun 2022 at 15:10, Maxime Devos  wrote:

> It's ‘reproducible’ in the trivial sense that you can ‘reproduce’ a
> scientific paper by putting it a photocopier.  That way, you can
> reproduce the results, but you cannot confirm whether these results
> were correct.

More details for the interested reader here [1].

1: 


Cheers,
simon

Release ? (was: Merging ‘staging’?)

[zimoun]

Hi,

On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès  wrote:

> Merged, enjoy!  :-)

Cool!


> Next up: release and ‘core-updates’.

Do you want to do a ’core-updates’ merge before the release?  I think a
release on July would be very welcome.  WDYT?


Cheers,
simon

Re: On commit access, patch review, and remaining healthy

[zimoun]

Hi,

On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann  
wrote:

> But I do think it's one more source of “friction” for new contributors,
> and one more thing for us to require that they get right.

[...]

> There's one in the GNU Coding Standards¹:

[...]

> Personally, I think nowadays this purpose is better fulfilled by
> good commit messages and git blame. Especially with an editor that makes
> it easy to use them to navigate through history (such as Emacs, but
> certainly others as well).

I agree that Emacs+Magit among many others make easy to navigate through
the history.  However, the commit messages are probably good enough
because some Coding Standards are imposed.

Because these standards, it is easy to navigate via grep for instance.
Git blame is useful once you know exactly what you are looking for.
Before that, when I try to figure out the logic behind such change, the
commit messages more or less fixed by the standards are very helpful,
IMHO.

Whatever the style (ChangeLog or anything else), it appears to me a good
thing to have strong standards.


Cheers,
simon

Re: On commit access, patch review, and remaining healthy

[zimoun]

Hi,

On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo  wrote:

>> It reduces a bit the pressure on the committers, IMHO.
>
> It raises a bit the pressure on the maintainers, IMHO :-)

What does it mean “maintainer” here?

Maybe I miss something but I do not think the Guix maintainers play a
special role in reviewing or committing.  Could you explain which
pressure you are envisioning?


> I understand there is a certain "entrance barrier" to become patch
> reviewer, but I'm afraid we cannot lower it more than the current
> situation except for the offload build server and more tolling options.

I am missing the meaning of «tolling option».

I think it is possible to lower a bit the reviewing barrier.  Today, the
patch submission is very flexible: it is possible to send inline
patches, attached patches, mix inline and attach, subject can or not
contain ’vN’ and/or X/Y, base-commit is recommended but not mandatory,
etc.  Therefore, it is hard to automate many reviewing steps.

For instance, consider submission #47171 [1].  It was not my first
contribution, it was not the first review by Ricardo, and we both missed
a “guix pull” breakage despite the fact I did “make as-derivation” (and
I am not convinced it is systematically done ;-)).

Another example, when working of Preservation of Guix [2], I noticed
that many packages using git-fetch were not in SWH; which means that
“guix lint” had not been run on these packages.

We could answer more automated tools on infra side, etc. which is the
direction to go.  But we are not there yet and things need to be done
today. :-)  That’s why, I think the project should:

 1. change the default branch of “git push” vs the default branch of
 “guix pull”.

 2. add a bit more of checkers on patch submission easing patch review.
 

1: 
2: 



Cheers,
simon

Re: Release ? (was: Merging ‘staging’?)

[Efraim Flashner]

On Tue, Jun 14, 2022 at 12:32:13PM +0200, zimoun wrote:
> Hi,
> 
> On Mon, 13 Jun 2022 at 09:03, Ludovic Courtès  wrote:
> 
> > Merged, enjoy!  :-)
> 
> Cool!
> 
> 
> > Next up: release and ‘core-updates’.
> 
> Do you want to do a ’core-updates’ merge before the release?  I think a
> release on July would be very welcome.  WDYT?

I think we do release and then core-updates, before we get bogged down
in fixing packages in core-updates.

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


signature.asc
Description: PGP signature

Re: On commit access, patch review, and remaining healthy

[Maxim Cournoyer]

Hello,

zimoun  writes:

> Hi,
>
> On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann  
> wrote:
>
>> But I do think it's one more source of “friction” for new contributors,
>> and one more thing for us to require that they get right.
>
> [...]
>
>> There's one in the GNU Coding Standards¹:
>
> [...]
>
>> Personally, I think nowadays this purpose is better fulfilled by
>> good commit messages and git blame. Especially with an editor that makes
>> it easy to use them to navigate through history (such as Emacs, but
>> certainly others as well).
>
> I agree that Emacs+Magit among many others make easy to navigate through
> the history.  However, the commit messages are probably good enough
> because some Coding Standards are imposed.
>
> Because these standards, it is easy to navigate via grep for instance.
> Git blame is useful once you know exactly what you are looking for.
> Before that, when I try to figure out the logic behind such change, the
> commit messages more or less fixed by the standards are very helpful,
> IMHO.

I agree.  I've come to like GNU ChangeLog commit messages because it
forces me to lay down the changes I've worked on, and sometimes I can
spot things that would be better separated in its own commit, or that
was unintentionally left while testing.

When reviewing others' work it also give me a clear trail of what they
did, and I can match the actual changes to their high level description.

> Whatever the style (ChangeLog or anything else), it appears to me a good
> thing to have strong standards.

Agreed!

Thanks,

Maxim

Re: Teams

[Blake Shaw]

I think I could join the Home team as well, at least for now, as I started
using it a month ago and have been having a blast. I also have some
home-services to upstream after a bit of polish (Guile EDSL for
Herbstluftwm configuration if anyone is interested), and some plans to work
on the documentation.

I found the documentation to be a bit confusing (understandably, as its
new), but once the workflow snapped together its been amazing to see how
easy it is to create new services. And I now I have my entire desktop
environment contained in a single text file! Being able to ftp a text file
to a fresh Debian linode and get to work with all my tools ready within 10
minutes has been magic.

It also demonstrates a lot of Guile's strengths in one place: you can
easily wrap interfaces in Guile, and the expressive power it adds (at least
in the case of a window manager) is immediately evident.

Very excited about it, great work :)

On Tue, Jun 14, 2022, 18:31 Andrew Tropin  wrote:

> On 2022-06-05 10:19, Josselin Poiret wrote:
>
> > Hello everyone,
> >
> > Ricardo Wurmus  writes:
> >
> >> As a first step I’d suggest collecting teams, setting up the email
> >> aliases, and updating the website to show the existing teams.
> >
> > I think an installer team would be good too (which I would gladly join).
> > WDYT of the following teams:
> > * Installer (which I'd gladly join);
> > * System;
> > * Home;
> > * Internals?
> >
> > Maybe that would add too many teams, but I think the first three could
> > be pretty useful.
> >
> > How do we automatically make Mumi understand which team a patch should
> > notify?  I've just started using public-inbox/lei and the `dfn:` search
> > term is pretty useful, it lets you select only patches that change
> > specific files.  For example, `dfn:gnu/installer*` would match all
> > patches that touch the installer.
> >
> > Best,
>
> I'm not in a guix-maintainers yet, but I would like to join Home team.
>
> --
> Best regards,
> Andrew Tropin
>

Re: Teams

[jgart]

On Tue, 14 Jun 2022 08:47:37 -0400 guix-devel-requ...@gnu.org wrote:

Hi Guixers,

Count me in for any packaging on teams. 

I'd like to help out with python and/or rust.

all best,

jgart

Re: On commit access, patch review, and remaining healthy

[Arun Isaac]

>>> Personally, I think nowadays this purpose is better fulfilled by
>>> good commit messages and git blame. Especially with an editor that makes
>>> it easy to use them to navigate through history (such as Emacs, but
>>> certainly others as well).
>>
>> Because these standards, it is easy to navigate via grep for instance.
>> Git blame is useful once you know exactly what you are looking for.
>> Before that, when I try to figure out the logic behind such change, the
>> commit messages more or less fixed by the standards are very helpful,
>> IMHO.
>
> I agree.  I've come to like GNU ChangeLog commit messages because it
> forces me to lay down the changes I've worked on, and sometimes I can
> spot things that would be better separated in its own commit, or that
> was unintentionally left while testing.

Exactly! I too have grown to like our ChangeLog style commit messages
enough that I use it in my own repositories.

I like to think of them as akin to the Pointing and Calling[1] system
common on Japanese railways. In the Pointing and Calling system, the
railway worker has to not only go through a checklist of items, but also
has to actually *point* (gesturing) and *call" (verbalizing) the
relevant dial or traffic signal. This explicit gesturing and verbalizing
makes them pay more attention and reduces the probability of an
accident. Likewise, our ChangeLog style commit messages force the
committer to explicitly list down the changes and thus catch any lapses
of concentration.

[1]: https://en.wikipedia.org/wiki/Pointing_and_calling

> When reviewing others' work it also give me a clear trail of what they
> did, and I can match the actual changes to their high level
> description.

I agree! :-)