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 foo@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-patches@gnu.org, waits for an ID to
be mailed to you, only after that to reply to <ID>@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 <UUID>@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-patches@gnu.org'

0001-guix-scripts-Add-contrib-script.patch
Description: Text Data