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

[Maxim Cournoyer]

Hi Csepp,

Csepp  writes:

> Maxim Cournoyer  writes:
>
>> Hi,
>>
>> Csepp  writes:
>>
>> [...]
>>
>>> but as soon as something breaks, you are thrown into the deep end,
>>> having to dissect logs, bisect commit ranges, learn strace, gdb (which
>>> still doesn't work well on Guix)
>>
>> Hm?  While GDB on Guix may be sometimes more challenging than say, on
>> Fedora, I only know of one problem, that is related to grafts (see: #48907).
>>
>> For running binaries wrapped in shell script, I have this 'run-gdb'
>> wrapper which reads:
>>
>> --8<---cut here---start->8---
>> #!/usr/bin/env bash
>>
>> wrapper=$(cat $(which $1))
>> shift
>> . <(echo "$wrapper" | grep ^export)
>> binary=$(echo "$wrapper" | grep ^exec | grep -o -E '/gnu/store[^"]*')
>> gdb --args "$binary" "$@"
>> --8<---cut here---end--->8---
>>
>> Hope that helps,
>
> Thanks, it does somewhat, but this is the kind of thing that should be
> either packaged in Guix, documented in the cookbook, or preferably fixed
> upstream.
> At the very least I try to document these helper Guix-specific helper
> scripts on the mailing list.  I've asked where it would be appropriate
> to put them (cookbook, package, guix module, etc) but I don't think I
> got a response.
> This is exactly what I mean by core devs having their own scripts that
> others don't have an easy way to find and/or access.

I think a "Debugging with GDB" section in the Cookbook showcasing such
script would be a good option.  Patches welcome!

> The other problem is the difficulty of accessing debug symbols.
> One problem is the need to recompile the package you need symbols for,
> the other is loading external symbols.  The first is a CI issue as far
> as I know: all the debug outputs would take up too much space
> (probably).

We have tons of disk space on Berlin, at least.  I don't think it'd be
an issue at least there (not sure about Bordeaux).  We could also look
into having our debug symbols de-duplicated with something like dwz
(https://sourceware.org/mailman/listinfo/dwz) to make them smaller, or
see if Fedora does something smart in this regard.

> This may not be fixable in the short term without
> additional funding.  The second is purely technical though.
> Maybe someone fixed it since the last time I tried to use GDB, but if
> not, it should be a priority IMHO.  Guix packages often have bugs and we
> should do everything in our power to make fixing future problems easier,
> otherwise the project risks the death of a thousand cuts.

Loading external (such as from linked libraries?) symbols should work,
provided they are in the profile you're working with, that gdb is there,
and that it has access to the default ~/.guile file (e.g. not in a
container), so that it automatically set 'debug-file-directory' for you,
from the GDB_DEBUG_FILE_DIRECTORY environment variable.

Also, build the profile with --no-grafts to avoid the bug mentioned
earlier (#48907).

-- 
Thanks,
Maxim

Re: collection of “guix pull“ bug reports

[Csepp]

Simon Tournier  writes:

> Hi Maxim,
>
> On Sat, 26 Aug 2023 at 22:34, Maxim Cournoyer  
> wrote:
>
>>> https://issues.guix.gnu.org/issue/62830
>>> https://issues.guix.gnu.org/issue/63451
>>> https://issues.guix.gnu.org/issue/63830
>>> https://issues.guix.gnu.org/issue/64489
>>> https://issues.guix.gnu.org/issue/64659
>>> https://issues.guix.gnu.org/issue/64753
>>> https://issues.guix.gnu.org/issue/64963
>
> [...]
>
>>> Any idea about what could be unexpected or what needs some love?
>>
>> I haven't checked the above links, but I think something that would help
>> in this regard is better handling of network issues.  E.g, don't print a
>> backtrace on the first connection failure; retry maybe 3 times then
>> print a helpful error mentioning the network appears unreliable.
>
> IMHO, this collection raises two questions:
>
>   1. Why does it happen?  To say it explicitly, I am almost sure that
>   something is not smoothly working as expected on server side.  For
>   instance, I had ‘guix pull’ troubles with a machine and I am doubtful
>   that this machine has network issue (this machine is using the fast
>   network link of my Univ. employer :-))
>
>   2. What could be done on client side for reducing the annoyance?  I
>   agree that substitute failures should be better handled.  For example,
>   retry 3 times then display an error message.  Etc.
>
>
> Cheers,
> simon
>
> PS: About #2, please give a look at these annoyances:
>
>   + Issue 1 and 2: Options --fallabck and --no-substitutes
>   + Issue 3: Non consistent message for substitutes and/or fallback
>
> from .

There also needs to be an option to just retry forever IMHO.  On my
netbook it is very costly to re-run guix pull's non-substitutable parts
so I'd rather Guix just kept trying in case of network errors.

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

[Danny Milosavljevic]

Hi,

> review" because of the amount of cognitive overhead required. I've written
> a script for myself that tries to perform all the steps including running
> the git command to submit the patch, and this has helped me, but that this
> is necessary for me to do might be something that, if addressed, could
> help others.

I agree that automating the technical steps of contributing to Guix
would be nice.

I suggest that we preinstall a script that does the equivalent of this:

if [ ! -d guix ]
  then
git clone --depth=1
https://git.savannah.gnu.org/git/guix.git guix
  else
(cd guix && git pull --rebase)
  fi \
  && cd guix
  && guix shell -C -D guix -- ./bootstrap \
  && guix shell -C -D guix -- ./configure --localstatedir=/var
  --disable-daemon \
  && guix shell -C -D guix -- make -j5 \
  && ./pre-inst-env guix edit "$@" \
  && git add gnu/packages/*.scm

Also, we should automate adding an smtp server (after ascertaining that port
25 localhost is not open or something? Not sure.):

git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserver mail.messagingengine.com
git config --global sendemail.smtpuser f...@example.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtppass hackme

There's even a file guix/etc/git/gitconfig already--aha!

This would reduce the barrier to entry a lot.

It's unfortunate that for example pre-inst-env doesn't work correctly (for
me; checked on multiple computers) when you don't invoke "make" beforehand
(sometimes it just picks up the wrong guix and doesn't say anything!). On the
other hand, using a guix.scm anywhere else works without make.

If I do "guix edit xyz" it opens a file in /gnu/store that I can't edit.
Not sure what good that is.

It would be better to ask and then automatically suggest invoking the script
above that prepares a guix development environment.

It's kinda weird we don't just have a "guix contrib" subcommand or something
that automates basic things that any guix contributor needs.

> I can't ever seem to get the GNU style commit messages correct.

Writing the metadata into the commit messages is annoying. It totally should
be automated, especially since Scheme has pretty simple syntax (so it should
be easy to write such a thing/famous-last-words). It should just figure out
which procedures the changed lines were in, automatically.
(This probably does exist in emacs)

Because of the line-based nature of the diff tools and of a lot of git tools, we
do need to have which procedure was changed in the git commit message,
though.

> I don't use the email-based patch workflow day-to-day, so this is another
> area where I spend a lot of time trying to make sure I'm doing things
> correctly.

Especially since one needs to the debbugs dance where one first opens a new
bug report by sending an email to guix-patc...@gnu.org, waits for an ID to
be mailed to you, only after that to reply to @debbugs.gnu.org,
attaching the patches (copying the message-id from the old mail manually as
a reference). That is such a weird workaround for a debbugs limitation.

This definitely should be automated. Why not generate a UUID locally and send
a mail to @debbugs.gnu.org ? That may require changes to debbugs,
though.

> manually managing Guile imports is laborious. As a fledgling schemer, I
> often forget which imports I needed just for development. 

Yeah. I like that we now tell the user whether imports are unused, and also
which import it could most likely be if it's missing. But automating the cleanup
and adding like it is in Java IDEs would totally be awesome. With a language
as dynamic as Guile I think this problem is intractable since you can never be
sure someone dynamically does (or doesn't) need the import.
Can still be approximated.

I attached some changes to guix to make the contributor experience less bad.
It doesn't look nice but it does work and I even prefer that workflow myself 
now.

@Ludo: What do you think?

> Does this affect anyone else?

The basic setup affects one only when one changes workstations--which I suspect
is why it wasn't improved until now. It's just too rare a problem per person. 
But it's a
very bad barrier of entry for new contributors, and there's no reason for it to 
be there!

But the other annoyances totally affect me all the time, too.

Cheers,
 Danny

P.S. We could also do git config --local alias.send-patches 'git send-email -r 
origin/master --cover-letter --annotate --to=guix-patc...@gnu.org'
From 10f16b0b3cf47931db5c9607b95872f477550422 Mon Sep 17 00:00:00 2001
Message-Id: <10f16b0b3cf47931db5c9607b95872f477550422.1693350103.git.dan...@scratchpost.org>
From: Danny Milosavljevic 
Date: Wed, 30 Aug 2023 00:50:00 +0200
Subject: [PATCH] guix: scripts: Add "contrib" script.

* guix/scripts/contrib.scm: New file.
* guix/scripts/edit.scm (spawn-editor): Mention new command "guix contrib" if applicable.
* manifest.scm: New file.
* doc/guix.texi (Invoking guix 

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

[Csepp]

Giovanni Biscuolo  writes:

> ...
>> What are the blockers in Guix's policies for moving in this direction?
>
> Guix is a GNU project, GNU have an infrastructure, a set of services and
> a policy for their projects.  Maybe one day GNU will provide a self
> hosted SourceHut service, now GNU have https://savannah.gnu.org/ and
> https://debbugs.gnu.org/
>
> ...and please remember: "all forges and all issue trackers suck, some
> just sucks less" (stolen from mutt motto)

I hope GNU is not so inflexible that it won't support Guix if it
switches to a better maintained forge.

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

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
> [...]
>
>> but as soon as something breaks, you are thrown into the deep end,
>> having to dissect logs, bisect commit ranges, learn strace, gdb (which
>> still doesn't work well on Guix)
>
> Hm?  Why GDB on Guix may be sometimes more challenging than say, on
> Fedora, I only know of one problem, that is related to grafts (see: #48907).
>
> For running binaries wrapped in shell script, I have this 'run-gdb'
> wrapper which reads:
>
> --8<---cut here---start->8---
> #!/usr/bin/env bash
>
> wrapper=$(cat $(which $1))
> shift
> . <(echo "$wrapper" | grep ^export)
> binary=$(echo "$wrapper" | grep ^exec | grep -o -E '/gnu/store[^"]*')
> gdb --args "$binary" "$@"
> --8<---cut here---end--->8---
>
> Hope that helps,

Thanks, it does somewhat, but this is the kind of thing that should be
either packaged in Guix, documented in the cookbook, or preferably fixed
upstream.
At the very least I try to document these helper Guix-specific helper
scripts on the mailing list.  I've asked where it would be appropriate
to put them (cookbook, package, guix module, etc) but I don't think I
got a response.
This is exactly what I mean by core devs having their own scripts that
others don't have an easy way to find and/or access.

The other problem is the difficulty of accessing debug symbols.
One problem is the need to recompile the package you need symbols for,
the other is loading external symbols.  The first is a CI issue as far
as I know: all the debug outputs would take up too much space
(probably).  This may not be fixable in the short term without
additional funding.  The second is purely technical though.
Maybe someone fixed it since the last time I tried to use GDB, but if
not, it should be a priority IMHO.  Guix packages often have bugs and we
should do everything in our power to make fixing future problems easier,
otherwise the project risks the death of a thousand cuts.
This is why I chose to work on Mirage, to get a better understanding of
the importer and cross-compilation tooling.

Re: Guix CLI options through manifest.scm or guix.scm

[Distopico]

On 2023-08-27, Liliana Marie Prikler  wrote:

> CLI options are very broadly scoped.  For instance, with
> transformations, we have a dedicated procedure to turn them into a
> transformation that can more easily be used inside a manifest.  On the
> general side…
>
> … every command is available also as a Scheme procedure that takes its
> arguments as a list directly.  Thus, you can quite easily transform the
> above to 
>
> (use-modules (guix script shell))
> (guix-shell "-m" "manifest.scm" "--container" "-F" "-N" …)
>
> Of course, if you want to dig deeper, you can also call the functions
> guix-shell ends up calling, but whether doing so makes sense is up for
> you to decide.
>
> Happy hacking!

It works, here the code as a reference for someone else that maybe will
need something similar

;;; coniatner.scm

```
#!/usr/bin/env -S guile -s
!#
(use-modules (guix scripts shell))

(let ((args (list "-m"
  "manifest.scm"
  "--container"
  "-F"
  "-N"
  "-P"
  (string-append "--share=" (getenv "ANDROID_SDK_ROOT"))
  "--preserve='^DISPLAY$'"
  "--preserve='^XAUTHORITY$'"
  "--preserve='^DBUS_'"
  (string-append "--expose=" (getenv "XAUTHORITY"))
  "--expose=/var/run/dbus"
  "--expose=/sys/dev"
  "--expose=/sys/devices"
  "--expose=/dev/dri"
  "--expose=/dev/kvm")))

  (apply guix-shell (append args (cdr (command-line)
```

and then in `.envrc`

```
eval $(./container.scm --search-paths)
```

or from terminal

```
./container.scm 
```


signature.asc
Description: PGP signature

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

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 29.08.2023 um 12:29 +0300 schrieb MSavoritias:
> 
> Just some remarks here,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Freitag, dem 25.08.2023 um 08:07 + schrieb Attila Lendvai:
> > > i couldn't even find out which tools are used by those who are
> > > comfortable with the email based workflow. i looked around once,
> > > even
> > > in the manual, but maybe i should look again.
> > Users who have tried curlbash also looked at
> >   wget https://issues.guix.gnu.org/issue/N/patch-set/M | git am -3
> > 
> > > i'm pretty sure most maintainers have a setup where the emailed
> > > patches can be applied to a new branch with a single press of a
> > > button, otherwise it'd be hell of a time-waster.
> > Well, it's several keys, actually, but as others have already
> > pointed out, keyboard > mouse.
> > 
> That is a subjective thing and its posed as something that is not. We
> should all be open to being wrong.
I mean, my comment was meant to be tongue-in-cheek and I'm not a UX
expert, so you might want to consult those, but there appears to be a
shared experience of many hackers that the keyboard is often better at
getting the things you want done done.

> > > one fundamental issue with the email based workflow is that its
> > > underlying data model simply does not formally encode enough
> > > information to be able to implement a slick workflow and
> > > frontend.  e.g. with a PR based model the obsolete versions of a
> > > PR is hidden until needed (rarely). the email based model is just
> > > a flat list of messages that includes all the past mistakes, and
> > > the by now irrelevant versions.
> > What the?  If anything, emails are like a tree and discussions in
> > most forges are a single long list that's rarely well organized. 
> > Virtually every mail client supports threads, whereas a certain one
> > of the more popular forges still refuses to do so.  Hiding obsolete
> > versions of a pull request is in practice implemented either by
> > pushing more commits on top of the existing one, often with dubious
> > commit messages or by force-pushing a branch, neither of which is
> > an acceptable solution for Guix.
> > 
> Using Emacs with mu4e its also bad to deal with lots of patches here
> too :) 
> Now having worked with Gitlab for example the UI is not as
> chaotic.
> Aside from the "Gitlab is proprietary" argument which is NOT the
> point. The point is how do we make it as easy as that for the people
> that dont want to customize their email clients for optimal
> "threading" capabilities?
To be fair, Gitlab is on the better forges out there, also allowing you
to interact with issues via email for one.  It also has decent support
for threads.  However, apart from being proprietary and thus not likely
adopted by any GNU project serious about software freedom, 

> > > > But someone would have to write and maintain them...
> > > 
> > > 
> > > there are some that have already been written. here's an ad-hoc
> > > list
> > > of references:
> > > 
> > > #github #gitlab #alternative
> > > https://codeberg.org/
> > > https://notabug.org/
> > > https://sourcehut.org/
> > > https://sr.ht/projects
> > > https://builds.sr.ht/
> > > https://git.lepiller.eu/gitile
> > > codeberg.org is gitea and sr.ht is sourcehut
> > Gitile is (as far as I'm aware) not yet a full forge.  It also
> > hasn't loaded for me in ages, but I digress.
> > 
> > It doesn't suffice if you just integrate any of those forges into
> > the pre-existing workflow somehow.  You must also make it a
> > pleasant experience for everyone involved.  This is similar to the
> > issue that already bugs our Matrix<->IRC bridge.  
> > 
> > Other implicit assumptions include that people will be happy to
> > switch for the particular fork you've chosen (they won't) and will
> > not demand $new_hot_thing within the next five years (they likely
> > will, just look at the ChatGPT-related stuff that has been
> > submitted).  There sadly is no pleasing everyone here and unless
> > these tools are incredibly simple to maintain, the utilitarian
> > approach of least misery leads you to plain email.
> > 
> Also this is sounds like you think the other person just follows
> fashion and you are the one that follows the "enlightened" way
> because you use email. This is not the discussion we are having and
> we don't treat people as less if they dont use terminal, emails or
> emacs or whatever else you find amazing or whatever.
There is no singular "other person" here.  There is people, a plural,
and people as a group are very well influenced through fashion.  Of
course, there's some stochastics involved; people wearing adidas from
head to toe don't tend to frequent the same places as elegant gothic
lolita aristocrat vampires.  Indeed, the people now choosing sourcehut
may still do so in five years (though some might choose something
else).  However, the people demanding any other interface in those five
years will undoubtedly be influenced by 

Re: Guix and the developer ecosystem

[Distopico]

Nice, thanks for your response.

On 2023-08-24, Ludovic Courtès  wrote:

> Hi,
>
> Distopico  skribis:
>
>>> Regarding customization, ‘--with-input’ and perhaps other transformation
>>> options may correspond to your needs:
>>>
>>>   
>>> https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html
>>>
>>
>> According with the docs, it will make rebuilt the packages so with
>> Rust/haskell that could take time and cpu, and for sure is a good option
>> in many cases, and maybe with Parameterized Packages[1] would be another
>> option, but what about have let said two packages like
>> `haskell-language-server-8.x` and `haskell-language-server-9.x` wherein
>> each one utilizes a predefined GHC version and prebuilt derivations? Is
>> this approach valid?
>
> Yes, having one language server package for GHC 8 and another one for
> GHC 9 sounds like the way to go: it gives flexibility for Haskell
> developers and comes almost for free on the Guix side.
>
> Thanks,
> Ludo’.



signature.asc
Description: PGP signature

Re: Guix CLI options through manifest.scm or guix.scm

[Distopico]

On 2023-08-27, Liliana Marie Prikler  wrote:

> Hi Distopico
>
> Am Sonntag, dem 27.08.2023 um 13:25 -0500 schrieb Distopico:
>> 
>> Is it possible to define/express CLI options from manifest.scm or
>> guix.scm? For example, I have
> CLI options are very broadly scoped.  For instance, with
> transformations, we have a dedicated procedure to turn them into a
> transformation that can more easily be used inside a manifest.  On the
> general side…
>
>> ```
>> guix shell \
>>  -m manifest.scm \
>>  --container -F -N -P \
>>  --share=/opt/android-sdk \
>>  --share=$HOME/.android/avd \
>>  --share=$HOME/.gradle/ \
>>  --preserve='^DISPLAY$' \
>>  --preserve='^XAUTHORITY$' \
>>  --preserve='^DBUS_' \
>>  --expose=$XAUTHORITY \
>>  --expose=/var/run/dbus
>> ```
>> 
>> Manually invoking this command is not practical, so I have
>> `scripts/container.sh`, a script to invoke it, but I think it would
>> be much more practical if it's possible to define it in a
>> configuration file similar to docker-compose, which allows almost all
>> CLI options to be set in the configuration file to avoid having an
>> additional configuration file.
>> 
>> Or perhaps a Guile script instead of a shell script? How do others
>> handle this here?
> … every command is available also as a Scheme procedure that takes its
> arguments as a list directly.  Thus, you can quite easily transform the
> above to 
>
> (use-modules (guix script shell))
> (guix-shell "-m" "manifest.scm" "--container" "-F" "-N" …)
>
> Of course, if you want to dig deeper, you can also call the functions
> guix-shell ends up calling, but whether doing so makes sense is up for
> you to decide.
>
> Happy hacking!

Thank you Liliana, I'll tests that option 

Best


signature.asc
Description: PGP signature

Re: 03/08: build: Add dependency on guix script for help2man targets.

[Maxim Cournoyer]

Hello,

guix-comm...@gnu.org writes:

> jpoiret pushed a commit to branch master
> in repository guix.
>
> commit ca8acad38264dd29a808904d3ce8e7249194d95f
> Author: Josselin Poiret 
> AuthorDate: Fri May 12 10:00:00 2023 +0200
>
> build: Add dependency on guix script for help2man targets.
> 
> * doc/local.mk: Add dependency on guix script for help2man targets.
> 
> Signed-off-by: Ludovic Courtès 

This changes appears to break building my tree, like this:

--8<---cut here---start->8---
help2man: can't get `--help' info from guix home
Try `--no-discard-stderr' if option outputs to stderr
make[2]: [Makefile:7131 : doc/guix-home.1] Erreur 1 (ignorée)
--8<---cut here---end--->8---

It doesn't happen with 'make as-derivation' though, so it seems to have
to do with some shenanigan in my checkout.  Any idea how I could fix my
checkout without running 'git clean -xfdd' ?

-- 
Thanks,
Maxim

Re: SSSD, Kerberized NFSv4 and Bacula

[Hartmut Goebel]

Hi,

Am 24.08.23 um 21:55 schrieb Martin Baulig:


 1. My "guix secrets" tool provides a command-line interface to
maintain a "secrets database" (/etc/guix/secrets.db) that's only
accessible to root.  It can contain simple passwords, arbitrary
text (like for instance X509 certificates in PEM format) and
binary data.

 2. …

 3. Finally, "secrets-service-type" depends on all of the above to do
its work.

It takes a /template file/ - which is typically interned in the
store - containing special "tokens" that tell it which keys to
look up from the /secrets database/.


This sounds great and like being a major step towards "guixops" [1], [2].

[1] 
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00435.html[2] 
https://lists.gnu.org/archive/html/guix-devel/2017-09/msg00196.html


--
Regards
Hartmut Goebel

| Hartmut Goebel  |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com  | compilers which you thought are impossible |

Guix pull speed

[Josselin Poiret]

Hi everyone,

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.  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.

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.

One idea I had was to move all the packages that are looked up in (guix
self) to their own little bubble, to avoid having to load extra stuff.
However, this is not currently possible because some of them do have
non-trivial dependency graphs.  I've identified these problematic
inputs: guile-avahi guile-ssh guile-git guile-gnutls guix-daemon (it
pulls in all other dependencies itself) po4a graphviz

What could be done about this?  Another solution would be to somehow
build Guix without any of the dependencies and then add them in later,
similar to what is done with build-aux/build-self.scm to be able to load
(guix self) in the first place.  That seems quite complex though.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

git interfaces (was Re: How can we decrease the cognitive overhead for contributors?)

[Giovanni Biscuolo]

Giovanni Biscuolo  writes:

[...]

> Executive summary: it's "just" and **interface** problem; contributors

"an interface problem"

> who like the SourceHut web UI to format and send patchsets via email are
> very wellcome to subscribe and use the SourceHut services to send
> patches (also) to Guix [1].  There is no reason for Guix to be
> (self)hosted on SourceHut.
>
> Also, like there are manu TUI for Git,

"there are many"

> there are also many Git GUIs
> around https://git-scm.com/downloads/guis, maybe some of them also have
> a "patch preparation UI" like the Git SourceHut web service.

For example, I see that git-cola (https://git-cola.github.io/) have an
interface to apply patches [1] (the user still needs a way to download
the patches to apply them) but AFAIU it does not have an interface for
"git format-patch"; I guess it should not be too hard to add it as a
custom GUI action [2]

Could git-cola be a tool to help people who dislike CLI/TUI tools
contribute to Guix (or other email based patch management projects)
smootly?

[...]

Best regards, Gio'


[1] https://git-cola.readthedocs.io/en/latest/git-cola.html#apply-patches

[2] https://git-cola.readthedocs.io/en/latest/git-cola.html#custom-gui-actions

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

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

[Giovanni Biscuolo]

Hi

MSavoritias  writes:

[...]

>> Not needing to register yet another account for one-off contributions
>> is an argument that kills all the forges, sadly :)
>>
> With Sourcehut you can contribute without an account.

Because they use an email based patch send/review workflow :-)

In other words: you can contribute to a SourceHut hosted project with
patches (or just with comments to patches) because everyone can send an
email to an email address provided by the project maintainer(s).

> There is also https://forgefed.org/ which is for federated forges using
> activitypub. So you can have one account for all forges that
> federate. :D

Interesting project, for now the supported (implementations) are:

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

- Vervis is the reference implementation of ForgeFed. It serves as a demo 
platform for testing the protocol and new features.

- Forgejo is implementing federation.

- Pagure has an unmaintained ForgeFed plugin.

--8<---cut here---end--->8---
(via https://forgefed.org/)

Funny thing is that on the main Vervis instance
(https://vervis.peers.community/browse) they say: «NOTE: Federation is
disabled on this instance!»

Let's say this federation project is stil in early alpha... and probably
we will never see an implementation in GitHub: WDYT?!? :-O

Anyway, since the SourceHut patch management medium is email, it's
federated by default.

Happy hacking! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

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

[MSavoritias]

Liliana Marie Prikler  writes:

> Hi,
>
> Am Sonntag, dem 27.08.2023 um 16:57 +0300 schrieb Saku Laesvuori:
>> > > 
>> > not sure how most people consume their emails nowadays, but for me
>> > it's one flat list per thread, in a browser (i.e. it's not a tree).
>> 
>> The point is that the emails contain the information on how to
>> construct a tree out of them. It's just that most web clients (which
>> most people are unfortunately using nowadays) are so bad that they
>> render the tree as a flat list.
> Not sure about "most", but Guix folk are definitely biased towards
> dedicated mail clients (terminal, graphical, Emacs…), so perhaps my own
> perception was a little off in that people will always benefit from
> having the tree.  Then again, you can share your email between multiple
> clients, which isn't that easy to do with code repositories sadly.  
>
> Of course, you can mirror the repo, but your bug trackers aren't that
> easily mirrored.
>
>> 
>> > and all i'm trying to achieve here is to move the discussion away
>> > from email-is-superior-period, to look at what requiremenets we
>> > have and what tools satisfy them, if any.
>> 
>> I think that is a good discussion to have, but I think it would be
>> better to describe some of the requirements you think we should
>> consider instead of just saying email isn't superior. It might not
>> be, but it might also be. We should consider what we need and
>> evaluate the available tools based on that, and if the result is that
>> email is the best then it is.
> Not needing to register yet another account for one-off contributions
> is an argument that kills all the forges, sadly :)
>
With Sourcehut you can contribute without an account.
There is also https://forgefed.org/ which is for federated forges using
activitypub. So you can have one account for all forges that
federate. :D

MSavoritias
>> > > at the ChatGPT-related stuff that has been submitted). There
>> > > sadly is no pleasing everyone here and unless these tools are
>> > > incredibly simple to maintain, the utilitarian approach of least
>> > > misery leads you to plain email.
>> > 
>> > but is a least-misery model appropriate here? how do you even
>> > account for the contributions that could have happened in a
>> > different environment, but did not happen?
>> > 
>> > similarly, e.g. demanding a dated ChangeLog format for commit
>> > messages has a filtering effect on who will contribute, and then
>> > who will stick around. most engineers have a hard time jumping
>> > through hoops that they find pointless (git automatically encodes
>> > that information), and i'd suggest considering what the effect are
>> > of such rules on Guix asan emergent order.
>> 
>> I agree on the ChangeLogs being a weird thing to require in commit
>> messages. I think of commit messages as the place where you record
>> the reasons behind the change in the commit. The ChangeLog seems to
>> just record the changes which the diff of the commit already
>> automatically records more accurately.
> First things first, I disagree with the framing here.  Engineers do
> pointless things all the time and both code style and commit message
> style have near endless potential for bikeshedding (which we are
> currently engaged in btw).  There are like thirteen competing standards
> on how to format C code and similar debates in other languages.  In
> fact, I'd go so far as to argue that a language ecosystem that has no
> such debate is potentially lacking in diversity.
>
> A proper ChangeLog doesn't simply "record the changes the diff already
> records more accurately".  It adds semantics.  For instance, when
> bumping a package, we write the same line twice; once for the header,
> once for the ChangeLog.  What we don't write is that we also adjusted
> the hash along with the version.  Doing so would give us no new
> information, but the diff includes it anyway, because diffs are stupid.
> Humans writing (and reading) ChangeLogs aren't stupid and can rely on
> contextual meta-information – however, the ChangeLog should still be
> self-contained in the sense that it doesn't rely on other parts of the
> message to infer the actual changes made.
>
>> If someone has use cases for the ChangeLog commits, I'd like to hear
>> them. Maybe there is something that can't be achieved with git
>> history without ChangeLogs, but I can't think of anything. Someone
>> mentioned grepping the git log with them, but I think the same thing
>> can be done with git log and git blame regardless of the commit
>> message format.
> In my humble opinion, you underestimate the benefits of not having to
> invoke another command on a commit.  For a great number of changes, the
> ChangeLog style allows me to imagine the code that was written without
> having to see it in a way that a simple diffstat just can't.  Of
> course, whether you use ChangeLog style commit messages, Emoji commits
> or any other formatting guide is a political question between everyone
> 

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

[MSavoritias]

Simon Tournier  writes:

> Hi,
>
> On Fri, 25 Aug 2023 at 18:39, Katherine Cox-Buday  
> wrote:
>
>> 2. Remember the email address (it might seem silly unless you have forms 
>> of dyslexia. is it guix-patches? or patches-guix? Wait, what was I doing?)
>> 3. And then the whole deal with what to do with follow ups.
>
> For what it is worth, I am using Emacs-Notmuch for reading emails and it
> provides the key “c G” for stashing the email address.  For instance,
> applying to your message:
>
> --to="Katherine Cox-Buday " 
> --to="guix-devel@gnu.org" --cc="guix-devel@gnu.org" 
> --in-reply-to="547c097a-d805-9a55-11d9-b0434327f...@gmail.com"
>
> Then, I am able to paste as argument for git-send-email or else.  Well,
> it reduces the opportunity for a typo.
>
> That’s said…
>
>> I wrote some elisp to one-key apply patches from GNUS, but I guess my 
>> point is: not everyone can do that. How are we to expect more 
>> contributors if that, or something similar, is the barrier to entry?
>
> …I agree that Debbugs is not the best system for managing patches.  Many
> of us are ending with some custom helpers for working around the
> annoyances.  And that seems an indicator that Debbugs is not the best
> fit.
>

Do you know if there are any plans to write a scheme bug/patching
system? Because looking a bit into it, it doesn't seem like its that
actively developed so maybe we would be better served by one in scheme.
Or Sourcehut of course as somebody wrote in another email.
Since not much would change with sr.ht anyways.

MSavoritias

> Cheers,
> simon

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

[MSavoritias]

Just some remarks here,

Liliana Marie Prikler  writes:

> Am Freitag, dem 25.08.2023 um 08:07 + schrieb Attila Lendvai:
>> i couldn't even find out which tools are used by those who are
>> comfortable with the email based workflow. i looked around once, even
>> in the manual, but maybe i should look again.
> Users who have tried curlbash also looked at
>   wget https://issues.guix.gnu.org/issue/N/patch-set/M | git am -3
>
>> i'm pretty sure most maintainers have a setup where the emailed
>> patches can be applied to a new branch with a single press of a
>> button, otherwise it'd be hell of a time-waster.
> Well, it's several keys, actually, but as others have already pointed
> out, keyboard > mouse.
>
That is a subjective thing and its posed as something that is not. We
should all be open to being wrong.

>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is hidden
>> until needed (rarely). the email based model is just a flat list of
>> messages that includes all the past mistakes, and the by now
>> irrelevant versions.
> What the?  If anything, emails are like a tree and discussions in most
> forges are a single long list that's rarely well organized.  Virtually
> every mail client supports threads, whereas a certain one of the more
> popular forges still refuses to do so.  Hiding obsolete versions of a
> pull request is in practice implemented either by pushing more commits
> on top of the existing one, often with dubious commit messages or by
> force-pushing a branch, neither of which is an acceptable solution for
> Guix.
>
Using Emacs with mu4e its also bad to deal with lots of patches here too
:) Now having worked with Gitlab for example the UI is not as chaotic.
Aside from the "Gitlab is proprietary" argument which is NOT the
point. The point is how do we make it as easy as that for the people
that dont want to customize their email clients for optimal "threading"
capabilities?

>> > But someone would have to write and maintain them...
>> 
>> 
>> there are some that have already been written. here's an ad-hoc list
>> of references:
>> 
>> #github #gitlab #alternative
>> https://codeberg.org/
>> https://notabug.org/
>> https://sourcehut.org/
>> https://sr.ht/projects
>> https://builds.sr.ht/
>> https://git.lepiller.eu/gitile
>> codeberg.org is gitea and sr.ht is sourcehut
> Gitile is (as far as I'm aware) not yet a full forge.  It also hasn't
> loaded for me in ages, but I digress.
>
> It doesn't suffice if you just integrate any of those forges into the
> pre-existing workflow somehow.  You must also make it a pleasant
> experience for everyone involved.  This is similar to the issue that
> already bugs our Matrix<->IRC bridge.  
>
> Other implicit assumptions include that people will be happy to switch
> for the particular fork you've chosen (they won't) and will not demand
> $new_hot_thing within the next five years (they likely will, just look
> at the ChatGPT-related stuff that has been submitted).  There sadly is
> no pleasing everyone here and unless these tools are incredibly simple
> to maintain, the utilitarian approach of least misery leads you to
> plain email.
>
Also this is sounds like you think the other person just follows fashion
and you are the one that follows the "enlightened" way because you use
email. This is not the discussion we are having and we don't treat
people as less if they dont use terminal, emails or emacs or whatever
else you find amazing or whatever.

MSavoritias
> Cheers

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

[Giovanni Biscuolo]

[I sent this message incomplete by mistake, sorry!]

Ciao Giacomo,

I never used nor installed/administered SourceHut services, I've some
comments from what I learned reading documentation and articles.

Executive summary: it's "just" and **interface** problem; contributors
who like the SourceHut web UI to format and send patchsets via email are
very wellcome to subscribe and use the SourceHut services to send
patches (also) to Guix [1].  There is no reason for Guix to be
(self)hosted on SourceHut.

Also, like there are manu TUI for Git, there are also many Git GUIs
around https://git-scm.com/downloads/guis, maybe some of them also have
a "patch preparation UI" like the Git SourceHut web service.

paul  writes:

> From reading this discussion it appears sourcehut supporting both the
> web and email workflow and being free software is really the best
> solution.

SourceHut is a suite including this tools providing different services
(some of them already covered by specialized tools in Guix, e.g. CI):

- builds.sr.ht
- git.sr.ht
- hg.sr.ht
- hub.sr.ht
- lists.sr.ht
- man.sr.ht
- meta.sr.ht
- pages.sr.ht
- paste.sr.ht
- todo.sr.ht

git.sr.ht have a tool for "web-based patch preparation UI", it's
documented [1]: that tool is "just" a web interface to prepare a
patchset to be sent upstream via email; please read all the section and
you'll see that it describes an email based patch management workflow.

Also, in the "Tutorials" page I find the section "Contributing to
projects on SourceHut" [1] and the "Read more" link point to
https://git-send-email.io/

Finally, yesterday I sent a message (id:87il8z9yw8@xelera.eu) with
some pointers to related articles, two were from Drew DeVault, SourceHut
founder

Given what I found above, I'd say that the workflow model used by
SourceHut hosted projects is email based, not web based, and that the
service "git.sr.ht" provides SourceHut users "just" a web UI helping
them to format and send a patchset via email in the same way "git
format-patch" and "git send-email" do.

...it's "just" an _interface_ question, not an email vs web patch
management question :-)

That said, I understand that some (many?) users are not comfortable with
CLI interfaces and prefers a GUI interface (web UI is the same), but
there is no reason to increase the reviewers cognitive overhead by
introducing an inefficient web based patch management workflow just to
address a "simple" and unrelated interface problem.

> It appears to have no downsides (besides for the work required for
> packaging and provisioning the service)

First, let's start with packaging each SourceHut service in Guix: AFAIU
packaging in other distros is not in good shape, i.e.

- Debian
  
https://packages.debian.org/search?keywords=sourcehut=names=all=all
  https://wiki.debian.org/Teams/pkg-sourcehut

- Arch Linux
  https://archlinux.org/packages/?sort==sourcehut==

- Fedora
  https://packages.fedoraproject.org/search?query=sourcehut

Sure, they have https://man.sr.ht/packages.md for Alpine Linux, Arch
Linux and Debian, but:

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

Warning: SourceHut is still in alpha, and has no stable releases. As such, we 
do not recommend packaging SourceHut for your upstream distribution 
repositories until we have shipped stable versions of our software.

--8<---cut here---end--->8---
(from https://man.sr.ht/packages.md)

So we have to wait for SourceHut to exit its alpha status to start
packaging it, no?

> and everything else either does not support email workflow or does not
> support web workflow.

I insist: SourceHut does _not_ support a "web workflow" (fork, PR and
merge all done via a web UI)

> What are the blockers in Guix's policies for moving in this direction?

Guix is a GNU project, GNU have an infrastructure, a set of services and
a policy for their projects.  Maybe one day GNU will provide a self
hosted SourceHut service, now GNU have https://savannah.gnu.org/ and
https://debbugs.gnu.org/

...and please remember: "all forges and all issue trackers suck, some
just sucks less" (stolen from mutt motto)

> Should a team with a defined roadmap be created to address Katherine's 
> and all other people's point, either way the consensus will fall?

First it would be useful to separate each /different/ question raised in
dedicated threads that are actionable, possibly leading to a patch or at
least to a consensus... or to some sort of clarification at least.

I hope I helped to clarify the "email vs web patch management" question
with this message.

Ciao! Gio'


[1] https://man.sr.ht/git.sr.ht/#sending-patches-upstream

[2] https://man.sr.ht/tutorials/#contributing-to-srht-projects

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

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

[Giovanni Biscuolo]

Ciao Giacomo,

I never used nor installed/administered sourcehut services, I've some
questions about them:

paul  writes:

> From reading this discussion it appears sourcehut supporting both the
> web and email workflow and being free software is really the best
> solution.

sourcehut is a suite including this tools providing different services
(some of them already covered by specialized tools in Guix, e.g. CI):

- builds.sr.ht
- git.sr.ht
- hg.sr.ht
- hub.sr.ht
- lists.sr.ht
- man.sr.ht
- meta.sr.ht
- pages.sr.ht
- paste.sr.ht
- todo.sr.ht

git.sr.ht is the tool needed for "web workflow" patch management, it's
documented here: https://man.sr.ht/git.sr.ht/#sending-patches-upstream


git.sr.ht provides a web-based patch preparation UI, which you can use to 
prepare changes to send upstream online. You can even use this to prepare 
patches for projects that use email for submission, but are not hosted on 
SourceHut. This tool may be helpful to users who are used to the "pull request" 
style contribution popularized by GitHub, GitLab, and others.


yesterday I sent a message (id:87il8z9yw8@xelera.eu) with some
pointers to related articles, two were from Drew DeVault, sourcehut
founder

in the "Tutorials" page I find the section "Contributing to projects on
SourceHut" [1] and the "Read more" link point to
https://git-send-email.io/




> It appears to have no downsides (besides for the work
> required for packaging and provisioning the service) and everything
> else either does not support email workflow or does not support web
> workflow.
>
> What are the blockers in Guix's policies for moving in this direction? 
> Should a team with a defined roadmap be created to address Katherine's 
> and all other people's point, either way the consensus will fall?
>
> giacomo
>

[1] https://man.sr.ht/tutorials/#contributing-to-srht-projects

-- 
Giovanni Biscuolo

Xelera IT Infrastructures