Re: Process for reviewing patches as someone without commit access

[Maxim Cournoyer]

Hi Simon, Chris,

Simon Tournier  writes:

> Hi Chris, all,
>
> On Wed, 06 Sep 2023 at 16:55, Christopher Baines  wrote:
>
>> Once we know what tags to use, I can have the QA frontpage do something
>> similar to the "Mark as moreinfo" links, so it's easy to just click a
>> button then send the email to change the state of a issue.
>
> That’s cool!
>
> Well, using emacs-debbugs and then
>
> C-u M-x debbugs-gnu-usertags guix-patches RET
>
> the list of usertags is:
>
> guix-patches  for-core-updates
> guix-patches  reviewed-looks-good
>
> And if instead of guix-patches we consider guix then it reads,
>
> guix  build-system
> guix  cross-compilation
> guix  for-core-updates
> guix  looks-good
> guix  patch
> guix  plz-work
> guix  powerpc64le-linux
> guix  ready-to-review
> guix  reproducibility
> guix  reviewed
> guix  reviewed-looks-good
> guix  test-tag
> guix  v1.3.0
>
> However, I do not know how to list all the bugs for the package
> guix-patches that matches the usertag reviewed-looks-good.  Anyway!

Clicking on an entry in the above list shows them; I'm sure we could
define a procedure to directly show the bugs associated with a usertag,
which would be useful.

> I think that the usertag ’reviewed’ is a good idea.  That would be a
> very good start.  Then if it helps, we could add other usertags as
> reviewed-julia for patches that the Julia team can merge.

+1 for the 'reviewed' usertag (using the 'guix' user).

> Discussing about idea, would it be possible that the QA infrastructure
> automatically send a message to Debbugs for tagging?  For example, the
> usertag ’qa-ok’ or whatever other meaningful name. :-)

+1 for that as well, maybe 'qa-passed'.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi,
>
> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer  
> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial.  Sadly.
>
> There are many corner cases:
>
>  1. series as attachement
>  2. not all the series is applied
>  3. commit message had been tweaked
>  4. etc.
>
> The potential issue is the number of false-positive; closing and the
> submission is not applied.
>
> Maybe patchwork already running (I think) could help, trying to
> regularly rebase the branch dedicated to the submission on the top of
> master, then if all is fine, somehow the two heads from the master
> branch and the dedicated branch should match, and it would indicate the
> patches are included and it is safe to close.  More or less. :-)

We could use Gerrit's commit hook that adds a unique ID as a git
trailer.  Then it should become possible to

1. Check if all items of a series have appeared in the git history
2. If so, close the associated issue if it was still open

-- 
Thanks,
Maxim

Re: Process for reviewing patches as someone without commit access

[Simon Tournier]

Hi Chris, all,

On Wed, 06 Sep 2023 at 16:55, Christopher Baines  wrote:

> Once we know what tags to use, I can have the QA frontpage do something
> similar to the "Mark as moreinfo" links, so it's easy to just click a
> button then send the email to change the state of a issue.

That’s cool!

Well, using emacs-debbugs and then

C-u M-x debbugs-gnu-usertags guix-patches RET

the list of usertags is:

guix-patches  for-core-updates
guix-patches  reviewed-looks-good

And if instead of guix-patches we consider guix then it reads,

guix  build-system
guix  cross-compilation
guix  for-core-updates
guix  looks-good
guix  patch
guix  plz-work
guix  powerpc64le-linux
guix  ready-to-review
guix  reproducibility
guix  reviewed
guix  reviewed-looks-good
guix  test-tag
guix  v1.3.0

However, I do not know how to list all the bugs for the package
guix-patches that matches the usertag reviewed-looks-good.  Anyway!

I think that the usertag ’reviewed’ is a good idea.  That would be a
very good start.  Then if it helps, we could add other usertags as
reviewed-julia for patches that the Julia team can merge.

Discussing about idea, would it be possible that the QA infrastructure
automatically send a message to Debbugs for tagging?  For example, the
usertag ’qa-ok’ or whatever other meaningful name. :-)

Well, we can start with one usertag for only the architecture x86_64.
If this one is green, then it is worth to start the review.  It would
help for filtering.

The slippery slope is to have too much usertags.  I think we should
start with one or two usertags and see if it helps.

WDYT?

Cheers,
simon

Re: Process for reviewing patches as someone without commit access

[Simon Tournier]

Hi Felix,

On Wed, 06 Sep 2023 at 12:01, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> Usually, helpful reviews come from people with more experience. In
> your system they come from folks with less. That seems upside down to
> me.

Well, I think we are not there.  Maybe I am missing the proposal about
levels.  Somehow, I think there is not enough regular contributors for
having kind of levels.  Well, that’s not Debian. ;-)

Aside that considering how Savannah is configured today, commit access
are all or nothing.

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi,

On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer  wrote:

>> Let's avoid manual gardening as much as possible! :-)
>
> I like the idea!

I think that automatizing is not trivial.  Sadly.

There are many corner cases:

 1. series as attachement
 2. not all the series is applied
 3. commit message had been tweaked
 4. etc.

The potential issue is the number of false-positive; closing and the
submission is not applied.

Maybe patchwork already running (I think) could help, trying to
regularly rebase the branch dedicated to the submission on the top of
master, then if all is fine, somehow the two heads from the master
branch and the dedicated branch should match, and it would indicate the
patches are included and it is safe to close.  More or less. :-)

That’s said, I always find annoying to loose the track between the Git
history and the discussion that happened in the tracker.  Sometimes,
rational of some details of the implementation had been discussed in the
tracker and it is impossible to find then back.  Therefore, I would be
in favor to add ’Close #1234’ in the commit message, say the first one
from the series tracked by #1234.  Doing so, it would ease automatic
management of guix-patches.  However, it would add again some burden on
committer shoulder.

Similarly, we are already adding in the commit message something like
’Fixes ’.  And that could be
used for closing.  Again, the concern is about false-positive; closing
when it should not be.

Well, I think that automatizing is not trivial. :-)


Cheers,
simon

Re: Guix pull speed

[Simon Tournier]

Hi Josselin,

On Wed, 06 Sep 2023 at 11:45, Josselin Poiret  wrote:

>> Well, on my machine, the bigger bottleneck seems the procedure name
>> ’proxy’ which copies stuff around, IIUC. See [1].
>
> Proxy is on the helper script side, it's just waiting for the actual
> build script to do its thing.

Do it copy on the fly?  I mean, is it first written somewhere then moved?

>> Hum, is this ’graphml’ something you have not submitted?  Or am I
>> missing a point?  Last time I played with “guix graph”, I wrote a small
>> script for bridging with networkx.  See [2].
>
> I've committed it pretty recently, and should work OOTB now.

Cool!


>>> You can compare with a compiled check-out of guix by just running the
>>> following in a `guix repl`:
>>> --8<---cut here---start->8---
>>> (use-modules (guix self) (guix monad-repl))
>>> ,run-in-store (guix-derivation (getcwd) "0.0-git" #:pull-version 1)
>>> --8<---cut here---end--->8---
>>> which takes at most 5 seconds on my laptop.
>>
>> Yeah, that’s fast. :-)
>>
>> For comparing, what would be the corresponding derivations that “guix
>> pull” is building?
>
> It's building the same!  Just that building the derivation takes way
> longer because it has first to load a bunch of uncompiled guile files.

Well, I am not sure to follow.  Is your point not about why it
takes longer?

If it is the same, these 5 seconds is not why “guix pull” is slow, no?


Cheers,
simon

Re: How can we decrease the cognitive overhead for contributors?

[kiasoc5]

Hello,

On 2023-09-06 04:49, Maxim Cournoyer wrote:

Hi Katherine,

Katherine Cox-Buday  writes:


On 9/5/23 10:01 AM, Simon Tournier wrote:

Well, somehow, I consider the commit message format similarly as 
coding

style.  We can discuss which one is better than the other when at the
end it only reflects some artificial preferences and for the sake of 
any

project one needs to be arbitrarily picked.  Why not ChangeLog?


The distinction I draw is that I can usually run a linter against a
coding style.

I don't care very much what the standard for commit messages is other
than if it has an expectation of structure, I be able to run a tool to
tell me if it's wrong.

In other words, the overhead isn't "I don't like this standard", it's
"I can't find a way to reliably adhere to the standard".


'git log' should provide ample examples.  The format is not strict, and
it doesn't matter overly as long as it conveys a summary of the changes
accurately; it is meant for us humans.  The format is described
summarily in the GNU Standards document; to read it, you can run:

  guix shell standards info-reader -- info '(standards) ChangeLog'


Would be good to distill these conversations to the manual.

It would also be nice to add a section to the cookbook on explaining the 
parts of the commit message as it relates to Guix as a quick reference 
instead of grepping around for several wordings of the same action. From 
what I remember there's at least these parts to mention:


- including the package name and version on upgrades
- any changes to phases
- any changes to new input style, G-expressions, removal of trailing #t

Re: How can we decrease the cognitive overhead for contributors?

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

Hello,

I wanted to add to this thread my 2 cents. As a person who has recently
(last months) made the first attempts at contributing.

To me, registrations and reliance on JS had always been an obstacle to
using web-based forges. This is one of the reasons I haven't been
contributing to existing projects in the past.

With Guix this issue is gone but there's also another thing that
incentivized me — that, since joining the Guix mailing lists, I am
seeing activity all the time, right at my fingertips (because I have my
email client opened most of the time).

So far I have sent patches 4 times. Once it was a simple update that got
accepted quickly, once I was addressing a problem that turned out to be
better solvable another way and 2 submissions are still waiting for
someone to review them.

Although I had to learn to use `git format-patch` and related tools, I
don't consider it a problem. Actually, I wanted to learn email-based
workflow anyway because it seems to be a more KISS way of software
development.

The amount of new stuff to learn can, however, be a bit overwhelming. I
did learn to use git to send emails but haven't yet started using any of
the templating packages for Emacs that were recommended in Guix
documentation. It would be just too much to process at once.

Do I think Guix has a problem with cognitive overhead? Not at all.
Rather, it seems to be addressing the problems really well.
1. It makes it easy to hack on itself without the need to clone the
   repo first. That's what helped me get familiar with it before I
   could even try to contribute anything.
2. It, by default, updates to the most up-to-date version.
3. It has some detailed documentation.
4. It eases the setting up of one's development environment.

I fact, I suspect the email-based workflow might be automatically
filtering out some bad submissions that would have been made otherwise.
The geeky nature of the project does put it in a kind of a niche where
only geeks dwell. But this is somewhat benefitial because geeks are
those who can build it.

Lastly, sorry if something I wrote is a duplicate of other's opinions —
the thread got s long it'd be hard to read through 100% of it

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Tue, 05 Sep 2023 22:43:04 +0200 Liliana Marie Prikler 
 wrote:

> Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
> > Liliana Marie Prikler  writes:  
> > > Uhm, we have snippets?  
> > 
> > Well, those are exclusive to Emacs :)  And without regard to /that/
> > issue, I do think that there's a problem if the commit format is so
> > complex that it's not trivial for anyone new to the project to write
> > them out manually.  
> By definition, no amount of typing is non-trivial, safe for the empty
> amount, which good luck trying to commit your changes by pure mouse
> movements, I guess?
> 
> Now, if you excuse my French, I think the problem isn't really as much
> that people struggle to type out the perfect ChangeLog on the first
> try, which also makes it odd to request a linter.  Bear in mind that
> committers will sign off anything that appears convincing enough, even
> if there are smaller mistakes in the message.  Trust me, I've been
> there and seen that; and also done it myself.
> 
> Instead, we have seen in this thread appeals to age, appeals to
> perceived lack of personal benefit, and now appeals to typing effort,
> none of which really make that great of an argument against the
> ChangeLog style, especially when they come in combination with a
> refusal to make use of already provided tools.  I think we're starting
> to see the moving of the goal post as the actual game here. 
> 
> Maybe it's time to take a step back and instead of asking “How can we
> decrease the cognitive overhead for contributors?”, we should perhaps
> ask “For which contributors do we want to/can we decrease the cognitive
> overhead?”  We have drifted much from the original post that discussed
> moms with full-time jobs, who struggle to do “difficult” tasks
> (simplified wording; may change the meaning of the OP a little).  Now,
> I personally struggle to see how your personal preference for
> communication media, commit message style, and other things that were
> discussed in any of the preceding threads actually correlate with being
> a parent.  However, I do know that with its 150 million users, most
> people of the world don't have a Github account.  Being one of the 4
> billion email users out there is a comparably low barrier of entry
> imho.  So, whose cognitive overhead do you want to reduce (besides the
> obvious "my own", which everyone always tries)?
> 


pgpVmYY8Y4dB_.pgp
Descr

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Mittwoch, dem 06.09.2023 um 10:52 -0700 schrieb Vagrant Cascadian:
> I always get tripped up with phases, modify-phases, etc. as there
> seem to be potentially four or more levels deep in some common code
> patterns... for example, a recent commit mentioning phases:
> 
> commit c14c25b4fb625c2a5b9512618b3eb17ff15f7e71
> 
>     gnu: go-github-com-tdewolff-minify-v2: Regenerate hash.
> 
>     * gnu/packages/golang.scm (go-github-com-tdewolff-minify-
> v2)[#:phases]: Add
>     phase 'regenerate-hash.
> ...
> diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
> index 44953d6111..3c486c4121 100644
> --- a/gnu/packages/golang.scm
> +++ b/gnu/packages/golang.scm
> @@ -3685,11 +3685,24 @@ (define-public go-github-com-tdewolff-minify-
> v2
> 
> "0h006wpfkl0ls0skqxblwcanrhmphgq5q0ii26l2ayh7s99cgmy3"
>  (build-system go-build-system)
>  (arguments
> - (list #:import-path "github.com/tdewolff/minify/v2"))
> + (list #:import-path "github.com/tdewolff/minify/v2"
> +   #:phases
> +   #~(modify-phases %standard-phases
> +   (add-after 'unpack 'regenerate-hash
> ...
> 
> Why is it not more like:
> 
>     * gnu/packages/golang.scm
>     (go-github-com-tdewolff-minify-v2)[arguments][phases][modify-
> phases]:
>     Add 'regenerate-hash.
> 
> Honestly, that *seems* ridiculous to me, but I do not understand
> *why* based on the comment above or other patterns I have observed in
> the wild.
For one, reusing the same pair of braces is dangerous when you actually
need to split lines, which eventually, of course, you will.  So don't.
Use different pairs.

> My inclination would be:
> 
>     (go-github-com-tdewolff-minify-v2)[arguments]: Add phase
> 'regenerate-hash.
> 
> What goes in the square brackets? How many levels deep? Do I put
> something in the prose of the comment or in square brackets?
You can use ‘fancy quotes’ in ChangeLogs, which would break scheme
syntax.  So 

(go-github-com-tdewolff-minify-v2)[arguments]: Add ‘regenerate-
hash’ phase.

would be clearer than your suggestion.  Why use [#:phases] then? 
Because people understand it to be a shorthand for
[arguments]<#:phases>, the most common way in which the arguments field
changes.  If you change both that and idk, <#:configure-flags>, you'd
type them out.

> I can see how really not wanting to iterate with N back-and-forth
> discussions in review could hinder someone with a less flexible
> schedule, especially if there are no other significant changes to the
> patch... it could get demotivating.
You won't get N back and forth discussions solely on the format of the
ChangeLog.  If it were just that, the reviewer could just write it on
their own and be done with it; there's typically code changes as well
involved or at the very least undocumented changes that ought to be
documented.


Cheers

Re: Process for reviewing patches as someone without commit access

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

Hi Chris,

On Wed, Sep 6, 2023 at 11:39 AM Christopher Baines  wrote:
>
> I don't want to make reviewing changes more difficult, and I think
> setting up more people with commit access and continuing the trend that
> it's mostly people with commit access that review changes would increase
> the difficulty, compared to what I'm proposing here, which is trying to
> empower people who just do review whilst avoiding any of the complexity
> of merging and pushing the changes without breaking things.

Usually, helpful reviews come from people with more experience. In
your system they come from folks with less. That seems upside down to
me.

More significantly, work gets done faster when people are motivated. A
junior committer who is about to push a change will be much more eager
to find an experienced reviewer. It's a way to demonstrate knowledge.
The reviewer's testimony will eventually help the contributor attain a
higher level.

In other words, there is no empowerment in "just do[ing] a review".

Kind regards
Felix

Re: How can we decrease the cognitive overhead for contributors?

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi Vagrant,
>
> Vagrant Cascadian  writes:
>
>> On 2023-09-06, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
 ‘* foo/bar.scm new-package (inputs): add input’
 
 stuff. I literally can never remember this format, no matter how many
 times I do it. I'm reasonably sure square brackes go in there some
 where. It can take me quite a while to put together all that stuff,
 even with magit's help.
>>> It's 
>>>
>>> * file (variable)[field]{do you need 4 levels?}
>>
>> Honestly, not knowing the difference between a variable and field and
>> selector... this comment is of little help to me.
>>
>> I always get tripped up with phases, modify-phases, etc. as there seem
>> to be potentially four or more levels deep in some common code
>> patterns... for example, a recent commit mentioning phases:
>
> The ChangeLog Style section suggests there should be spaces between the
> "markers".  It also says the square brackets should be used to denote a
> change made in a conditional code path, so we're abusing the meaning of
> it in Guix to just a 'field' (which is, a record field, or slot, for the
>  record in Guix).  < > is to precise even more the place
> modified.  They're just shortcuts to avoid less typing while remaining
> readable.
>
> Here's an example in the Guix "dialect":
>
> * gnu/packages/file.scm (package-symbol)
> [arguments] <#:phases>: New patch-paths phase.
>
>
> It could also have been:
>
> * gnu/packages/file.scm (package-symbol) [arguments]: Add patch-paths
> phase.
>
> It doesn't really matter, as long as it's clear and you did the exercise
> of reviewing the code you touched and writing down the changes summary
> for the reviewer (and yourself).

I think I have a similar feeling to Vagrant, and on whether this
matters, I think it matters a lot.

In terms of encouraging people to contribute to Guix, we want the
documentation to set people up for success, or at least feeling like
they're doing things correctly.

The docs say:

  Please write commit logs in the ChangeLog format (see Change Logs in
  GNU Coding Standards); you can check the commit history for examples.

Which is expecting a lot of people who haven't encountered this
before. My view on this is that asking people to perform this task that
isn't very well documented or defined, and which people reviewing and
committing the changes will comment on or revise (maybe to be
objectively better, or maybe just in their own style) discourages people
to continue to contribute, especially those that care more about not
making mistakes/getting things right, or that lack confidence.

I'm indifferent about how we write the commit messages, I'm strongly in
favour of the expectations being clear and documented so that if people
new to the project want to attempt to write a good commit message,
they're setup for success with good documentation, and if something they
write can be improved, there should be some bit of documentation you can
point them to.


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Dienstag, dem 05.09.2023 um 20:34 -0600 schrieb Katherine Cox-Buday:
> In the US, the phrase "I don't buy it" is usually the response to 
> someone trying to trick you into something. This is a little hurtful 
> because it's either saying:
> 
> "You have an ulterior motive and are trying to trick me into doing 
> something."
> 
> or
> 
> "I don't have the same experience as you, so you must be lying."
In the US, you also have multi-level marketing schemes, where people,
fully believing in the product itself without any ulterior motive of
their own and without lying (for they know no better), perpetuate
scams.  And since both social media (including our well known code
hosting platforms) operate like multi-level marketing schemes and
conventions at least have the potential to do so, there can be fair
grounds for rejecting ("not buying") them even without assuming malice
on the part of the person proposing them.

In other words, I don't buy that not buying something is expressly
reserved to instances of deliberate trickery.  At the very least, the
dictionary definition of refusing to believe something leaves open the
reasons as for why one does so.

Cheers

Re: questionable advice about Geiser load path setting

[Maxim Cournoyer]

Hi,

I've made the change proposed and tested; then installed as 65dcfb3f
(".dir-locals: Streamline Geiser configuration.").  Let me know if
you encounter any problem.

-- 
Thanks,
Maxim

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Mittwoch, dem 06.09.2023 um 00:04 +0200 schrieb wolf:
> On 2023-09-05 22:43:04 +0200, Liliana Marie Prikler wrote:
> > Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
> > > Liliana Marie Prikler  writes:
> > > > Uhm, we have snippets?
> > > 
> > > Well, those are exclusive to Emacs :)  And without regard to
> > > /that/ issue, I do think that there's a problem if the commit
> > > format is so complex that it's not trivial for anyone new to the
> > > project to write them out manually.
> > By definition, no amount of typing is non-trivial, safe for the
> > empty amount, which good luck trying to commit your changes by pure
> > mouse movements, I guess?
> > 
> > Now, if you excuse my French, I think the problem isn't really as
> > much that people struggle to type out the perfect ChangeLog on the
> > first try, which also makes it odd to request a linter.  Bear in
> > mind that committers will sign off anything that appears convincing
> > enough, even if there are smaller mistakes in the message.  Trust
> > me, I've been there and seen that; and also done it myself.
> > 
> > Instead, we have seen in this thread appeals to age, appeals to
> > perceived lack of personal benefit, and now appeals to typing
> > effort, none of which really make that great of an argument against
> > the ChangeLog style, especially when they come in combination with
> > a refusal to make use of already provided tools.
> 
> I went through the snippets, and through the GNU documentation[0] and
> I am still not clear on how exactly should the commit message for a
> change in .dir-locals.el look like.  Maybe I did miss some tools or
> documentation?
Our snippets cover the most common cases, and editing the .dir-locals
happens quite rarely :)

> The "you can check the commit history for example" advice from the
> 22.6 page of documentations gives me 4 different styles in last 4
> commits.  Ok, just joking, 3 styles, the 4th is a typo (`* .dir-
> localsl.el: Add ...').
Regarding only the ChangeLog, I see 1.5 styles – that is
"* .dir-locals.el:"
and
"* .dir-locals.el (some specifier):"

Both are okay.  Regarding the header, you are free in what to type,
since it's at the top directory anyway.

> 0: https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> 
> > I think we're starting to see the moving of the goal post as the
> > actual game here. 
> > 
> > Maybe it's time to take a step back and instead of asking “How can
> > we decrease the cognitive overhead for contributors?”, we should
> > perhaps ask “For which contributors do we want to/can we decrease
> > the cognitive overhead?”
> 
> While I do risk taking this slightly more off topic, I personally am
> more interested in what can be done to help the committers, not
> contributors.  My biggest grievance with trying to contribute is not
> the process nor the tools, but the lack of reviews.  Having a patch
> sitting there without any reaction nor feedback is frustrating.  Do
> you see any process/tooling changes that could help on this front,
> even if they would make life harder for the contributors?
To be completely honest, mumi recalling everything at 0 precision is my
biggest pet peeve at the moment, but I don't think it's solely
responsible for the lack of reviews.  Even back when it did produce
reasonable results, patches were overlooked, which people often worked
around by asking for attention e.g. on IRC.

I don't think we should make things harder for contributors, but having
an interface where e.g. patches that have been unnoticed for about a
week or longer can easily be retrieved would definitely make things
easier.  Also, stuff like finding issues where CI lights green and
(non-committer) reviewers have said LGTM would be a big help.  I don't
see how we could implement this without rolling out a big knowledge
graph, though ;)

Re: Process for reviewing patches as someone without commit access

[Christopher Baines]

Felix Lechner  writes:

> On Wed, Sep 6, 2023 at 9:47 AM Christopher Baines  wrote:
>>
>> Maybe we can use debbugs tags for this?
>
> Instead of pushing people into reviews and then again making the same
> committers a bottleneck, I would offer some entry-level contributors
> commit rights but require that they obtain approval for some steps. It
> can be done on a trust basis.

It's an idea, although one I'd discount based on how many breaking
changes (including ones with wide impact like breaking guix pull) happen
with the current criteria for granting commit access.

I don't want to make reviewing changes more difficult, and I think
setting up more people with commit access and continuing the trend that
it's mostly people with commit access that review changes would increase
the difficulty, compared to what I'm proposing here, which is trying to
empower people who just do review whilst avoiding any of the complexity
of merging and pushing the changes without breaking things.

Now of course you could argue that it being easy to break things is a
problem, and maybe it is, but often it's not strictly someone breaking
something but simply a commit not being signed, or not being signed in a
way that guix accepts. Here I think pushing changes is complicated for
good reason.

> That way, you can train a new generation of committers while getting
> the work done.

In my opinion, I want to see review and committing things become more
separated, because the valuable thing is having good review. Committing
and pushing someone elses changes isn't adding much value to Guix in and
of itself, but good review of those changes does.

If we end up with a big backlog of changes that are reviewed and ready
to merge, then I'm all for training and helping more people do the
committing and pushing, but I have a suspicion that it's the review bit
that takes the time.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian  writes:

> On 2023-09-06, Liliana Marie Prikler wrote:
>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
>>> ‘* foo/bar.scm new-package (inputs): add input’
>>> 
>>> stuff. I literally can never remember this format, no matter how many
>>> times I do it. I'm reasonably sure square brackes go in there some
>>> where. It can take me quite a while to put together all that stuff,
>>> even with magit's help.
>> It's 
>>
>> * file (variable)[field]{do you need 4 levels?}
>
> Honestly, not knowing the difference between a variable and field and
> selector... this comment is of little help to me.
>
> I always get tripped up with phases, modify-phases, etc. as there seem
> to be potentially four or more levels deep in some common code
> patterns... for example, a recent commit mentioning phases:

The ChangeLog Style section suggests there should be spaces between the
"markers".  It also says the square brackets should be used to denote a
change made in a conditional code path, so we're abusing the meaning of
it in Guix to just a 'field' (which is, a record field, or slot, for the
 record in Guix).  < > is to precise even more the place
modified.  They're just shortcuts to avoid less typing while remaining
readable.

Here's an example in the Guix "dialect":

--8<---cut here---start->8---
* gnu/packages/file.scm (package-symbol)
[arguments] <#:phases>: New patch-paths phase.
--8<---cut here---end--->8---

It could also have been:

--8<---cut here---start->8---
* gnu/packages/file.scm (package-symbol) [arguments]: Add patch-paths
phase.
--8<---cut here---end--->8---

It doesn't really matter, as long as it's clear and you did the exercise
of reviewing the code you touched and writing down the changes summary
for the reviewer (and yourself).
  
-- 
Thanks,
Maxim

Re: Process for reviewing patches as someone without commit access

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

Hi Chris,

On Wed, Sep 6, 2023 at 9:47 AM Christopher Baines  wrote:
>
> Maybe we can use debbugs tags for this?

Instead of pushing people into reviews and then again making the same
committers a bottleneck, I would offer some entry-level contributors
commit rights but require that they obtain approval for some steps. It
can be done on a trust basis.

That way, you can train a new generation of committers while getting
the work done.

Advancing to a higher level requires a majority approval of the
maintainer collective. Same for revocations.

*** Contributor levels ***

1. Add new packages or fix documentation. This simple activity focuses
on fitness of software for Guix, including licensing. Finding a good
place in the file tree is also part of this job. Sign off required.

Novice levels, all require review by someone with a higher level

2. Update existing packages. Here, a contributor must be aware of how
updates affect consuming packages. Ideally, this activity would
include knowledge of CI, including the pre-compilation of all
consumers in order to avoid build failures before the change is
committed. No new inputs or phases. Hash updates only.
3. Modify inputs and build phases. Requires the mastery of
G-Expressions and a detailed knowledge of the particular build system
involved.
4. Rename package variables or change inheritance. This is for experts
in tool chains like Golang, or a technology like Emacs.

Intermediate levels:

5. Add new services
6. Edit existing services (after review)
7. Change Guix records outside of services, for example for
operating-system (after review).
https://lepiller.eu/en/a-deep-dive-into-guix-records.html

Advanced levels

8. Modify command-line behavior of the Guix executable (after review)
9. Change the Guix daemon (after review)

Black belt

10. No restrictions, and no reviews or approvals needed.

Kind regards
Felix

Re: How can we decrease the cognitive overhead for contributors?

[Vagrant Cascadian]

On 2023-09-06, Liliana Marie Prikler wrote:
> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
>> ‘* foo/bar.scm new-package (inputs): add input’
>> 
>> stuff. I literally can never remember this format, no matter how many
>> times I do it. I'm reasonably sure square brackes go in there some
>> where. It can take me quite a while to put together all that stuff,
>> even with magit's help.
> It's 
>
> * file (variable)[field]{do you need 4 levels?}

Honestly, not knowing the difference between a variable and field and
selector... this comment is of little help to me.

I always get tripped up with phases, modify-phases, etc. as there seem
to be potentially four or more levels deep in some common code
patterns... for example, a recent commit mentioning phases:

commit c14c25b4fb625c2a5b9512618b3eb17ff15f7e71

gnu: go-github-com-tdewolff-minify-v2: Regenerate hash.

* gnu/packages/golang.scm (go-github-com-tdewolff-minify-v2)[#:phases]: Add
phase 'regenerate-hash.
...
diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 44953d6111..3c486c4121 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -3685,11 +3685,24 @@ (define-public go-github-com-tdewolff-minify-v2
 "0h006wpfkl0ls0skqxblwcanrhmphgq5q0ii26l2ayh7s99cgmy3"
 (build-system go-build-system)
 (arguments
- (list #:import-path "github.com/tdewolff/minify/v2"))
+ (list #:import-path "github.com/tdewolff/minify/v2"
+   #:phases
+   #~(modify-phases %standard-phases
+   (add-after 'unpack 'regenerate-hash
...

Why is it not more like:

* gnu/packages/golang.scm
(go-github-com-tdewolff-minify-v2)[arguments][phases][modify-phases]:
Add 'regenerate-hash.

Honestly, that *seems* ridiculous to me, but I do not understand *why*
based on the comment above or other patterns I have observed in the
wild.

My inclination would be:

(go-github-com-tdewolff-minify-v2)[arguments]: Add phase 'regenerate-hash.

What goes in the square brackets? How many levels deep? Do I put
something in the prose of the comment or in square brackets?

For me, all this is only from observing many commits, submitting a few
patches, getting some good feedback, but really at the end of the day I
am just cargo-culting...

I have been submitting patches, and even pushing commits to guix for
several years now, and it is still quite unclear to me.

I can wing it just fine, and am able to submit imperfect patches and
have patience for reviews and suggestions and have the resources to
respond (at least, most of the time)...

I can see how really not wanting to iterate with N back-and-forth
discussions in review could hinder someone with a less flexible
schedule, especially if there are no other significant changes to the
patch... it could get demotivating.

It is obviously tricky, as sometimes people need back-and-forth
discussion to learn... though maybe they would rather focus their
limited energy learning how to program, a new language (guile), or just
learning how guix works in practice.

For some people, they might just not have the time or emotional energy
and just prefer to keep their changes in their local branch so they can
move on to the next thing that actually is motivating their work,
tinkering, play, etc. or move on to something else entirely which is
more rewarding, such as gardening...

This is not to say there is no value in the current commit message
format norms. Obviously some people have described the value it has for
them...

One value may be contextually dependent and sometimes at odds with other
values.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
> ‘* foo/bar.scm new-package (inputs): add input’
> 
> stuff. I literally can never remember this format, no matter how many
> times I do it. I'm reasonably sure square brackes go in there some
> where. It can take me quite a while to put together all that stuff,
> even with magit's help.
It's 

* file (variable)[field]{do you need 4 levels?}

HTH

Process for reviewing patches as someone without commit access

[Christopher Baines]

Hey!

I've been reviewing the list of ideas on and around QA ([1]) recently,
and got thinking again about how to support people without commit access
reviewing patches. Obviously you don't need commit access to review
patches, but where I think we need some process is how to expedite
someone with commit access taking a look at the patches that have been
reviewed, and merging them if appropriate.

1: https://qa.guix.gnu.org/README

Maybe we can use debbugs tags for this? It looks like this has already
been done in the past, I found some issues tagged with the usertag
"reviewed" for example [1]. Some were also tagged with
"reviewed-looks-good". I guess my primary concern is to have a tag (or
combination of tags) which indicate that a committer should have a look
at the issue as it's been reviewed by someone and should be ready to
merge. I don't really use debbugs much, but does anyone have any
opinions on appropriate tags?

1: https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=reviewed&users=guix

Once we know what tags to use, I can have the QA frontpage do something
similar to the "Mark as moreinfo" links, so it's easy to just click a
button then send the email to change the state of a issue.

Chris


signature.asc
Description: PGP signature

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo  writes:

> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this one:

[...]

> IMO we need a way automatically close this kind of bug reports... or am
> I missing something?
>
> Let's avoid manual gardening as much as possible! :-)

I like the idea!

> The first thing we need is a server side git post-receive hook on
> Savannah, I've opened the sr#110928 support request:
> https://savannah.nongnu.org/support/index.php?110928

It's something that the Savannah folks would need to maintain
themselves, right?

> When I asket I though the best way would be to scan for a string like
> "Close #" in the commit message (the committer should add
> such a string) but probably this can be avoided: the bug can be closed
> when a patch is committed to one of the listed official brances (master,
> core-updates, etc.)

You mean by simply matching the subject?  Maybe that could work.

-- 
Thanks,
Maxim

Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi,

Attila Lendvai  writes:

>> also not as obvious (you search for lines added or removed or changed,
>> not easy language such as 'gnu: package-name: Add').
>
>
> i'm pretty sure that the source of the annoyance is not the strict
> format in the summary line, but the formal details in the commit
> message body.

Agreed, but my point still holds.  The search space of our ChangeLog
messages is much smaller than that of the whole code base, thus is
faster (more efficient) and can be done interactively easily from the
'git log' output in your favorite $PAGER, as Andreas mentioned.

-- 
Thanks,
Maxim

Re: Guidelines for pre-trained ML model weight binaries

[Andreas Enge]

Hello,

related to this thread, I just came across an entry in Cory Doctorow's blog:
   
https://pluralistic.net/2023/08/18/openwashing/#you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means

It is already interesting in its disection of the terms "open" vs. "free",
which is quite relevant to us (but just echoes the sentiment I had anyway).
The end can be seen as an invitation to *not* package neurol network
related software at all: by packaging "big corporation X"'s free software,
but which is untrainable on anything but big corporations' hardware, we
actually help big corporation X to entrap users into its "ecosystem".

Andreas

Re: Help packaging ArrayFire

[B. Wilson]

Adam Faiz  wrote:
> On 8/20/23 19:35, B. Wilson wrote:
> > Hello Guix,
> > 
> > Knee deep in CMake hell here and would appreciate a helping hand. ArrayFire
> > build is defeating me:
> > 
> > CMake Error at 
> > /gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2/share/cmake-3.24/Modules/ExternalProject.cmake:3269
> >  (message):
> >   error: could not find git for fetch of af_forge-populate
> > Call Stack (most recent call first):
> >   
> > /gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2/share/cmake-3.24/Modules/ExternalProject.cmake:4171
> >  (_ep_add_update_command)
> >   CMakeLists.txt:13 (ExternalProject_Add)
> > 
> > Apparently, some of the build dependencies get automatically cloned, but I'm
> > unable to make heads or tails of how to work around this. The
> > `af_forge-populate` makes it look like it's related to Forge, but "ArrayFire
> > also requires Forge but this is a submodule and will be checkout during
> > submodule initilization stage. AF_BUILD_FORGE cmake option has to be turned 
> > on
> > to build graphics support," so I'm stumped.
> > 
> > I need this soon for a project and am willing to pay someone to take this 
> > over.
> > 
> > Here are the official build instructions: 
> > https://github.com/arrayfire/arrayfire/wiki/Build-Instructions-for-Linux
> > 
> > In fact, there's a 2016 thread where Dennis Mungai claims to have 
> > successfully
> > gotten ArrayFire packaged on Guix: https://issues.guix.gnu.org/23055. 
> > However,
> > that appears to have never resulted in a patch.
> > 
> > Thoughts?
> > 
> I'm willing to work on this, it's a very interesting challenge.

Beautiful! Keep me posted, and let me know if there's anything I can help with.

Cheers,
B. Wilson

Re: How can we decrease the cognitive overhead for contributors?

[Ekaitz Zarraga]

> > also not as obvious (you search for lines added or removed or changed,
> > not easy language such as 'gnu: package-name: Add').
> 
> 
> 
> i'm pretty sure that the source of the annoyance is not the strict format in 
> the summary line, but the formal details in the commit message body.

Yes.
For me it is. But in any case, this is not a barrier for me to contribute.
It's probably more annoying for those who need to review my commits. Which is 
also bad.

I also feel bad because I always manage to screw them up, but I keep trying.

Re: CI job for lisp-team branch

[Efraim Flashner]

On Mon, Sep 04, 2023 at 09:27:44AM +, Guillaume Le Vaillant wrote:
> Hi.
> I created a lisp-team branch to work one some updates for clisp and
> sbcl. Could someone with admin access to the CI things add a job for it?
> Thanks.

I commented on IRC but figured I should post to the mailing list.

I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib
section. I see the patch was removed, presumably because it was included
in the upstream release. When I finish my current build target(s) I'll
see what needs to be done there.

-- 
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: How can we decrease the cognitive overhead for contributors?

[Attila Lendvai]

> also not as obvious (you search for lines added or removed or changed,
> not easy language such as 'gnu: package-name: Add').


i'm pretty sure that the source of the annoyance is not the strict format in 
the summary line, but the formal details in the commit message body.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Until you make the unconscious conscious, it will direct your life and you 
will call it fate.”
— Carl Jung (1875–1961)

Next action, survey?

[Simon Tournier]

Hi Katherine,

On Tue, 05 Sep 2023 at 20:58, Katherine Cox-Buday  
wrote:

> OK, great! What are next steps, and how can I help?

Well, from my point of view, the next steps are:

 + Propose a survey (questions), open a new thread (or a bug report) for
   iterating.
 + Review how to distribute the survey.
 + Prepare the skeleton for generating a report about the stats from the
   survey.

Maybe the person or group of people in charge of this survey could be in
touch with Emacs folks.  They did a survey on 2022 [1].

1: https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01824.html


> Before I opened this can of worms, I was planning on trying to work on 
> the Go branch/packages 
> (https://lists.gnu.org/archive/html/guix-devel/2023-08/msg00058.html). 
> But since I'm the cause of all this, and it will indirectly help me with 
> Go things (which is why I brought it up), how can I help?

Having a survey will not be wasted, IMHO.  As you said, although there
are bias – the first one is the way to distribute it ;-) – it will help
to inform about the status.  Having some stats about Guix users and
contributors will explicitly spot what we probably already know but
having that will help, for sure.

Well, something unrelated.  For instance, I spent some time to run an
experiment for checking a real-world worst-case scenario when
fallbacking to Software Heritage [2].  This lists all the frictions.
All these frictions were more or less already known but having
explicitly collected them makes easier the path for improving.  That’s
somehow the measure you were talking about.

A survey and the associated report will act similarly: list what we more
or less already know, and then make easier the path for improving.

2: https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html


Cheers,
simon

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi Katherine,

( I feel we are not able to communicate on commit message format and
it seems we are on a road that leads to unfruitful output.  Well, I
appreciate the discussion and I have carefully read the messages. )


On Tue, 05 Sep 2023 at 20:34, Katherine Cox-Buday  
wrote:

> For whatever else has been brought up in this thread, I started with this:
>
>      I have given a list of issues to a group of people who are presumably
>      analytical, and I think the natural inclination is to go 
> point-by-point and
>      make arguments for/against. Instead of that[*], I invite you to 
> address the
>      more abstract issue: (should/how do) we reduce friction for making
>      contributions?

I agree with this, even if maybe I am misread.

For me, the reduction of the friction for making contributions means the
identification of such friction.  Once the friction area are identified,
it leads to an estimation about the order of magnitude of such friction
compared to all the other frictions.

As you said, we are all different, thus it means that any collaboration
cannot be full-frictionless.  Because any social interaction implies
norms and standards.  Norms and standards are by their definition
excluding.

For example, we communicate in English.  It appears to me impossible to
send a contribution without having some basic knowledge of English.  How
do I know that the English I wrote in the docstring, or in the comments
of code, or the name of the procedures, or in the commit message, etc.
how do I know that English is meeting the standard?  There is an
expectation about the English we are using for communicating and that
expectation is complicated enough that it’s easy to get it wrong.  What
is the thing that will tell me that the English I wrote is not meeting
the standard?

Why do we accept this “friction” about English filtering people?

Well, I am stretching a bit to make my point. :-)

I am trying to say that not all frictions are equal.  We collectively
must do our best to the reach equity, sure.  That’s said, we are hackers
and so we are improving what we are considering the most annoying.  You
find that running many commands for contributing is annoying so you are
trying to fix it.  I find some behaviour of “guix time-machine” annoying
so I am trying to fix it.  Etc.  The path for improving starts by making
apparent to all the annoyance, then optionally propose something – best
if one hopes the annoyance will be fixed :-) – and last the annoyance is
reduced for all when some proposal convinces folks.

My points are:

 1. thanks to all people for sharing their feedback
 2. the discussion is pointing many ideas that are actionable
 3. the discussion is also pointing friction that does not appear to me
being actionable


> In the US, the phrase "I don't buy it" is usually the response to 
> someone trying to trick you into something. This is a little hurtful 
> because it's either saying:

Sorry, it was not my intent.  I was expressing: I do not believe it is
*the* real problem.


>> Well, I share various points that had been raised in this thread about
>> smoothing the contribution requirements.  However, I am still puzzled by
>> the comments about the commit message format.  Again, my inability to
>> understand the issue does not mean I am not hearing.
>
> Communication is so hard. My only advice is to remain aware that 
> everyone in the world is different, and that even when we don't 
> understand something, or don't experience it ourselves, that doesn't 
> make it less real, especially if there's a plurality of people agreeing 
> with one another. And to always choose kindness.

I hope that I am demonstrating to always choose kindness.

Well, if we do not have a common understanding about something, then we
cannot communicate about this something, IMHO.  Sharing a common
understanding about something is a core principle to establish
communication and collaboration.

If group A says ’foo’ and group B does not understand ’foo’, this ’foo’
is real for group A but is it real for group B?  Group A and group B
needs to have a common understanding about ’foo’ in order to agree on
how to deal with ’foo’.

My messages in this thread show, I hope, that I am taking seriously this
discussion.  I am doing my best to be empathetic and I am considering
all the concerns.  However, raising a concern does not make it real or
automatically equal with all the others.

( Do not take me wrong, I am not saying that for example commit
message format could not be a real friction for some people, I am sure
it is; as using in English is a real friction for some people.  Instead,
I am saying that I fail to get why is it or what makes this commit
message format a real problem. )


> Here is a great talk by Rich Hickey called "Simple Made Easy". Although 
> I recommend watching the entire thing, I'd like to draw your attention 
> to a few points:

Thanks for this pointer, I already knew it.  Yeah, that’s a goo

Re: [workflow] Automatically close bug report when a patch is committed

[Christopher Baines]

Giovanni Biscuolo  writes:

> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this one:
>
>
>  rofi-wayland was added in:
>
>  04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>
>  And updated to a newer version in:
>
>  19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 
> 1.7.5+wayland2.
>
>  Marking as done.
>
> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)
>
> IMO we need a way automatically close this kind of bug reports... or am
> I missing something?

I think the example you give doesn't relate to what you're looking at
below (a post-receive hook).

There were at least two different issues with patches for adding
rofi-wayland [1] and [2].

1: https://issues.guix.gnu.org/53717
2: https://issues.guix.gnu.org/59241

One improvement I can think of here is that QA should highlight that
some of the changes in each of those patch series can be found in
another patch series.

That would then make it easier to both issues to be closed if that's
appropriate.


signature.asc
Description: PGP signature

Re: Guix pull speed

[Josselin Poiret]

Hi Simon,

Simon Tournier  writes:

> Hi Josselin,
>
> On Tue, 29 Aug 2023 at 13:58, Josselin Poiret  wrote:
>
>> After looking a bit more into guix pull speed, or to be more precise the
>> "Computing Guix derivation..." step, which is not substitutable.  I've
>> come to the conclusion that the thing that takes the majority of the
>> time is loading the files that define the packages that the new Guix
>> needs to build itself.
>
> Well, on my machine, the bigger bottleneck seems the procedure name
> ’proxy’ which copies stuff around, IIUC. See [1].

Proxy is on the helper script side, it's just waiting for the actual
build script to do its thing.

>> These files are not compiled yet, and worse,
>> loading just (gnu packages guile) ends up loading 361 other package
>> files.  You can generate a package graph in GraphML with `guix graph -t
>> module -b graphml guile`, and use e.g. networkx to analyze it.
>
> Hum, is this ’graphml’ something you have not submitted?  Or am I
> missing a point?  Last time I played with “guix graph”, I wrote a small
> script for bridging with networkx.  See [2].

I've committed it pretty recently, and should work OOTB now.

>> You can compare with a compiled check-out of guix by just running the
>> following in a `guix repl`:
>> --8<---cut here---start->8---
>> (use-modules (guix self) (guix monad-repl))
>> ,run-in-store (guix-derivation (getcwd) "0.0-git" #:pull-version 1)
>> --8<---cut here---end--->8---
>> which takes at most 5 seconds on my laptop.
>
> Yeah, that’s fast. :-)
>
> For comparing, what would be the corresponding derivations that “guix
> pull” is building?

It's building the same!  Just that building the derivation takes way
longer because it has first to load a bunch of uncompiled guile files.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[Josselin Poiret]

Hi Lily,

Liliana Marie Prikler  writes:

> Instead, we have seen in this thread appeals to age, appeals to
> perceived lack of personal benefit, and now appeals to typing effort,
> none of which really make that great of an argument against the
> ChangeLog style, especially when they come in combination with a
> refusal to make use of already provided tools.  I think we're starting
> to see the moving of the goal post as the actual game here. 

This seems to me like an unwarranted accusation.  The OP and numerous
other users/contributors have reported that they have actual
frustrations with the process here, and I don't think this is an healthy
interaction.

> Maybe it's time to take a step back and instead of asking “How can we
> decrease the cognitive overhead for contributors?”, we should perhaps
> ask “For which contributors do we want to/can we decrease the cognitive
> overhead?”  We have drifted much from the original post that discussed
> moms with full-time jobs, who struggle to do “difficult” tasks
> (simplified wording; may change the meaning of the OP a little).  Now,
> I personally struggle to see how your personal preference for
> communication media, commit message style, and other things that were
> discussed in any of the preceding threads actually correlate with being
> a parent.  However, I do know that with its 150 million users, most
> people of the world don't have a Github account.  Being one of the 4
> billion email users out there is a comparably low barrier of entry
> imho.  So, whose cognitive overhead do you want to reduce (besides the
> obvious "my own", which everyone always tries)?

We could try to time how long it takes to set up the email vs. forge
workflow and do a first contribution, I can bet the former is much
longer than the latter.  Especially if your email host has funky
authentication systems.  I don't think the number of users of each
system is a compelling argument either: you're not going to say that
mowing your lawn with a knife is inherently better because more people
have knives compared to lawnmowers.

Regarding the “mom argument”, I would disagree and say that this is
completely related: interruptions are more costly, you're more likely to
have less attention span, and overall you probably don't want to commit
to 20 steps just to send a contribution.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

[workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

Hello,

often bug reports related to patches are left open even after the
patch/patchset have been applied, the last example is a batch of Debbugs
manual gardening from Vagrant last Fri and Sat when he closed more than
20 bugs with messages similar to this one:

--8<---cut here---start->8---

 rofi-wayland was added in:

 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.

 And updated to a newer version in:

 19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 
1.7.5+wayland2.

 Marking as done.

--8<---cut here---end--->8---
(https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)

IMO we need a way automatically close this kind of bug reports... or am
I missing something?

Let's avoid manual gardening as much as possible! :-)

The first thing we need is a server side git post-receive hook on
Savannah, I've opened the sr#110928 support request:
https://savannah.nongnu.org/support/index.php?110928

When I asket I though the best way would be to scan for a string like
"Close #" in the commit message (the committer should add
such a string) but probably this can be avoided: the bug can be closed
when a patch is committed to one of the listed official brances (master,
core-updates, etc.)

WDYT?

Ciao, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature