Re: Can we provide another UI for patches than just email ?

[Maxim Cournoyer]

Hi Saku,

Saku Laesvuori  writes:

>> I'd like to be part of the solution, so Saku, I'd like to help
>> write the putative scripts you talk about. The main difficulty I see is
>> that they need to be configured to be able to send and receive email on
>> the user's behalf.
>
> That could probably be done via git send-email. I think the hardest
> thing is working around debbugs. One idea I have is to first create a
> branch with a name like -not-submitted, then somehow get the
> issue number after sending the first email and then rename the branch to
> - and either add a conditional git configuration
> rule[1] that sets the sendemail-to to the corresponding address or use
> that information from the script. Maybe mumi already does most of this,
> I haven't tried it yet (but I probably should).

You should try out the mumi CLI command; it already knows to poll
Debbugs for the new issue when sending a multi-patch series, avoids the
manual task of manually sending the first patch, waiting, then sending
the rest to the newly created issue #.

-- 
Thanks,
Maxim

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> So given there's no technical reasons not to use libgit2, I'd use that
>> and keep the closure size down.
>
> For the record, that’s a 6% increase:
>
> $ guix size guix | tail -1
> total: 633.0 MiB
> $ guix size guix git-minimal | tail -1
> total: 675.7 MiB
>
> (Of course it all adds up; I’m not saying we can dismiss it.)

As Simon pointed out, it'd be more after wrapping 'git' with coreutils
and possible util-linux on its PATH.

> In the context of  plus the lack of
> GC in libgit2 discussed in , my
> inclination is to include that hard dependency on Git.
>
> That’s not a happy choice for me, but it has the advantage of solving
> two immediate problems.
>
> I would revisit it as soon as libgit2 supports shallow clones (which is
> coming, as you write)

This isn't "coming", it's already been released :-).

> and GC (or a workaround to that effect).  SHA256 may also soon be a
> requirement: we’ll need to be able to clone repos that use it.
>
> How does that sound?

Yeah, 'git gc' is lacking from libgit2.  I'm not against adding
dependency on the real 'git' CLI, but at that point, as Simon mentioned,
I see little reason to keep libgit2 around for much longer, given it
performs worst than git CLI in every aspect.  I doubt forking processes
on GNU/Linux would cause a performance hit compared to using libgit2,
especially given how optimized git appears to be (at least compared to
libgit2).

So, I think we need to agree on the future of libgit2 in the big picture
and decide to invest in it or let it in favor of just using git.

-- 
Thanks,
Maxim

Re: Can we provide another UI for patches than just email ?

[Liliana Marie Prikler]

Hi Simon,

Am Donnerstag, dem 14.09.2023 um 19:48 +0200 schrieb Simon Tournier:
> a.  … send an Email to guix-patc...@gnu.org #only once
> b.  $ git config sendemail.to 12...@debbugs.gnu.org #only once
> c.  $ git send-email --base=auto -v  origin
> 
> and the order is flipped:
> 
>     a == 3   #only once
>     b == 1   #only once
>     c == 2
I mean, the real benefit of git send-email is that these three steps
compress into a single one if you have a series that consists of a
single patch.  In fact, mumi send-email already implements this
workflow in a somewhat clunky way that works, but it requires the use
of yet another tool that isn't well known outside of Guix (at least
with git send-email you can point at how kernel devs do stuff).

Maybe we should actually fix that debbugs bug or advocate a separate
address that runs a script on the backend waiting for all emails to
land and then forwarding them to debbugs similar to what mumi send-
email already does.  I kinda understand that there are good reasons why
debbugs is not that smart out of the box (something something denial of
service), but for most reasonable cases it shouldn't take too long for
that cover letter to arrive even if the mails are out of order.  (Plus
we have moderation, so spamming of large series is kept to a reasonable
minimum already).  We could also implement a timeout solution like "if
it's a multi-patch series and the cover letter doesn't arrive within
five minutes of the first patch, send a mail to the contributor asking
them nicely to send that first and then wait a bit, and then abort the
process".  

Cheers

Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Wilko Meyer]

Hi Guix,

I haven't had enough time to read up on every topic that has been
mentioned in the "How can we decrease the cognitive overhead for
contributors?" discussion as at some point it got quite a lot to
follow. At one point[0] there was a discussion on having a survey to get
a better picture on and quantify what potential blockers are to engage
with/contribute to Guix; which seems, if done right (as surveys have to
be carefully crafted), a good idea; especially with the prospect of
repeating it annually as a means to check if issues got
better/priorities in Guixes userbase change and so on. If there's a
consensus on doing this, I'd be happy to contribute some of my time to
get things going (would creating a issue on guixes bug tracker for this
topic be a good idea? how are these non-code contrib. topics handled?).

Before writing this mail, I had a look on how other projects handle
these kind of surveys, in particular:

- the emacs user survey[1]
- the nix community survey[2]
- the curl user survey[3]
- the fennel survey[4]

I identified a few key themes that could be useful for a guix user
survey as well. I plan on doing a more extensive summary on this later
this weekend if my time allows it, for now a loose collection of
ideas/list of what, in my subjective opinion, stood out and what most
surveys had in common should do to hopefully get a discussion on this
started:

- the emacs user survey specifically asked for elisp profiency; mapping
  out the Guile profiency of guixes community could be feasible.
- fennel as well as emacs had questions on which programming languages
  their community uses; in the regards on recent discussions on
  guix-devel on developer ecosystems[4] this could help to identify if
  there are any shortcomings in providing importers/packages for certain
  languages that may be used by guix users.
- the nix survey specifically asked for the environments and context nix
  is being used in; it'd be interesting to see where and for what
  purpose people are using Guix.
- most surveys had, some more some less extensive, demographic
  questions and questions mapping out how many years people have been
  programming.

Specifially in the lights of the original discussion/regarding
contributions:

- I think that the "Where do you discuss Fennel or interact with other
  Fennel developers" question of fennels survey should be asked for guix
  as well, to get a grasp on which platforms are being used to discuss
  all things guix.
- the curl user survey[6] did a pretty good job in mapping out what
  prevents users from contributing (p.20) as well as mapping out what
  areas of the project are regarding as good/which have room for
  improvements (p.24-26)
- fennel asked for "the biggest problems you have using Fennel", it had
  a "If you haven't hacked on Fennel itself, why not?" question as
  well. I personally think this could be good to assess potential pain
  points/blockers for Guix as well. Fennel also asked for "favorite
  features" which could be a nice way to map out which parts of Guix are
  popular.

Last, the nix user survey allowed free-form responses. Having a
qualitative research component to a survey could help getting better
results (especially when identifying problems in using guix/blockers in
contributing and so on); but evaluating these is pretty time extensive
and dependant on how much resources people have to compile a list of
findings/results from a prospective survey.

What could the next steps be to get this going?

[0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
[1]: https://emacssurvey.org/
[2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
[3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
[4]: https://fennel-lang.org/survey/2022
[5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
[6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

-- 
Kind regards,

Wilko Meyer
w...@wmeyer.eu

Re: Implementing the guix-dameon in Guile

[Mathieu Othacehe]

Hey Chris,

Congrats on getting the grant! I'm sure it will lead to a lot of
positive things. I tried it myself a couple years ago, for
the exact same subject, without success. 

> I imagine the daemon could be structured as a set of actors (it’s really
> my thing these days ;-)), with an eye on facilitating code sharing and
> interaction with the Coordinator, Cuirass, and all that.

I think this point is really important here. If the offload mechanism of
the existing guix-daemon was scaling correctly, with a better API, we
would probably never had to develop the Cuirass remote worker and the
Build Coordinator mechanisms.

Perhaps, part of the Build Coordinator code could be one day integrated
inside the new guix-daemon so that we can only use one offload mechanism
for all use cases. Users of the current "guix offload" as well as CI
tools could rely upon a unique offload mechanism.

The three other points I had in mind when proposing the subject to NLNet
were to:

- Fix the sqlite contention issues that have been observed on Berlin and
  other machines with huge local databases.

- Remove the GC lock: I think it has been done on recent nix-daemon.

- Add support for unprivileged daemon.

I don't know if it fits your plans but thought it could be interesting
to share that.

Good luck,

Mathieu

Re: The already complicated (complex?) process for contributing.

[Simon Tournier]

Hi Giovanni,

On Sat, 16 Sep 2023 at 09:33, Giovanni Biscuolo  wrote:

> since I already replied you offline please forgive me for any
> repetitions, but later I realized a better comment to your metaphore
> (see below) could be useful to other people.

Since your offlist comment is more or less about the same idea, let me
paste my answer. :-)

First, Guix is done by volunteers and is not an “industrial food
company”. :-) Being done by volunteers does not mean low-quality – Guix
is probably better than many products done by professionals ;-).
Instead, done by volunteers implies other mechanisms than the ones used
in “industrial food company”.

Second, I think we all agree with: we all have or had to read some
documentation and have to make some trial/error loop before being able
to run Guix.

That's also all my point, IMHO. :-)

As you said elsewhere, complex does not mean complicated.  Simple is not
necessary easy.  Etc.  Somehow, Rich Hikey says the obvious in their
talk [1] and that’s why the talk speaks to many people, I guess.  Rich
Hikey makes clear what we already know and had never said explicitly.
It is important to remember the message behind, IMHO.

>From my point of view, if the Guix community wants to Guix being
successful, then we have to work on two directions:

 1. Spread the word.
 2. Keep easy what should be easy.

About #1, it means talks, skill sharing, blog posts, tutorials,
documentation, etc.  and being pedagogical by showing what Guix is able
to offer.

About #2, it is where Guix is still a bit weak and we need to work on
that part.  Although, it is regularly improving.

Back to the initial discussion of this thread, which is a tiny stuff in
that picture :-) Your answer "it will be documented" focus on #1.
That's fine and yes having a good documentation is more than important.

My concern is to just say: please do not forget #2.

Thanks for the discussion.  And thanks for pushing ideas and for
pushing how to make them concrete.

My final word, the culinary proverb: talk does not cook the rice. :-)  I
am going to try to cook some rice. ;-)

Cheers,
simon

Re: The already complicated (complex?) process for contributing.

[Giovanni Biscuolo]

Hi Simon,

since I already replied you offline please forgive me for any
repetitions, but later I realized a better comment to your metaphore
(see below) could be useful to other people.

Simon Tournier  writes:

[...]

> On a side note, documentation is very fine but I do not read (or
> study!?) the documentation of my oven, instead I am just cooking stuff
> for fun.

On a side note, I like your metaphores!

OK but in my view the GNU Guix project is not a personal kitchen but an
international food company [1], with a complex /distributed/ production
process involving tools (ovens, etc.) and recipes (code) ranging from
trivial to very complex; not to forget **legal requirements**, a
challenging supply chain management and a very _peculiar_ process called
"change integration management" from "customers" proposals.  Am I
exaggerating?

Now, given the above context is a valid analogy, is it a fair
expectation you can contribute to the company [1] with the food you cook
just for fun with your oven?

The food GNU Guix company [1] supplies is boostrappable and reproducible
binary code, largerly "baked" using third-party recipes, with a
progressively shrinking binary seed: yeah! :-D

Well, to be honest the food analogy does not fit very well: Guix
supplies /peculiar/ tools that users can use for a variety of
activities, ranging from cooking just for fun to complex infrastructures
management... and to effectively use /that/ tools users should better
study its documentation (ungrateful job the documentation writer!) ;-)

[...]

> If a project needs really lengthy documentation for just contributing,
> either it is a more-than-thousand contributors project, as the Linux
> kernel

I disagree this is a valid metric to measure the complexity of the
process called "change integration management", it could even be _one_
customer asking to change the recipe for his preferred cake.

> either something is wrong.  Maybe both. ;-)

...or maybe it's not "just" a project but a whole food compay [1].

Oh, oh, oh: wait!  Are we going into /that/ famous essay [2] and its
sequel [3] ?!? (very interesting readings!)

...OK, I surrender, unconditionally! :-D

Happy cooking! :-) Gio'


[1] with a very peculiar vision, mission and business model; but please
concede the analogy

[2] "On Management and the Maginot Line"
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s12.html

[3] "Project Structures and Ownership"
http://catb.org/~esr/writings/homesteading/homesteading/ar01s16.html



P.S.: on a side note, I think that part (all?) of the problems discussed
in [2] and [3] are rooted in the anthropological set of questions known
as «Phenomenon of Bullshit Jobs»
https://davidgraeber.org/articles/on-the-phenomenon-of-bullshit-jobs-a-work-rant/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Can we provide another UI for patches than just email ?

[Saku Laesvuori]

> I'd like to be part of the solution, so Saku, I'd like to help
> write the putative scripts you talk about. The main difficulty I see is
> that they need to be configured to be able to send and receive email on
> the user's behalf.

That could probably be done via git send-email. I think the hardest
thing is working around debbugs. One idea I have is to first create a
branch with a name like -not-submitted, then somehow get the
issue number after sending the first email and then rename the branch to
- and either add a conditional git configuration
rule[1] that sets the sendemail-to to the corresponding address or use
that information from the script. Maybe mumi already does most of this,
I haven't tried it yet (but I probably should).

[1]: https://www.git-scm.com/docs/git-config#_conditional_includes


signature.asc
Description: PGP signature