Subject: [bug#38554] [PATCH 0/5] Update python-hy to 0.17.0

From: Jesse Gibbons <[email-masked]>
Date: Tue, 10 Dec 2019 14:59:52 -0700

On Mon, 2019-12-09 at 22:25 -0600, Brett Gilio wrote:
> Jesse Gibbons <[email-masked]> writes:
> 
> > The next five patches:
> > - add dependencies for python-hy 0.17.0 (patches 1,2)
> > - update python-hy from 0.13.0 to 0.17.0 (patch 3)
> > - add dependencies for python2-hy 0.17.0 (patches 4,5)
> > 
> > 
> > This will be the last version of python-hy to support python 2. If it is
> > better to drop python2-hy now, simply omit patches 4 and 5, and remove
> > python2-hy.
> 
> Hy Jesse! (Haha.)
> 
> Thank you for your patch series. I am sorry for the delay and the lack
> of communication regarding your bug report. I could imagine this is
> really frustrating. There are some corrections that I think need to be
> made before we go forward, and for the sake of education I would like to
> propose some revisions. Once we get these revisions, I think we will be
> golden for a push to master! So bare with me.
I feel the need to automate producing these patches because there are a lot
of things my poor memory needs to remember. I'll make some commit scripts
and share them later. Or maybe I can write a local git hook to do all those
things for me.
> 
> First off, _USUALLY_ we have the package-for-python2 derivatives in the
> same commits as the package indicating the original. Thus, your
> python2-* patches (4 & 5) can be squashed into their originating commits
> (1 & 2) respectively.
I tried to figure this out, but it has been so long since a python package
has been added, and we anticipate python2 EOL, so I thought I would keep
them separate in case it wasn't worth adding the python2 versions as their
own patches. I'll fix this.
> 
> In patch 1: You indicate your copyright email as such:
> 
> --8<---------------cut here---------------start------------->8---
> ;;; Copyright © 2019 Jesse Gibbons <[email-masked]>
> --8<---------------cut here---------------end--------------->8---
> 
> Is this correct? Just seems odd to me.

Yes, this is correct. As I understand it, names and email addresses are
added to the copyright section to allow someone to initiate contact with
each of the copyright holders regarding their copyright. The address looks
odd (and doesn't match some of the more common regexps for email addresses)
because it takes advantage of a feature that gives me (theoretically)
infinite email addresses that go to the same inbox. I use it to filter my
email, so I will know (in this case) an email is about a contribution I made
to guix, and my email client can filter it accordingly. I add the same email
address by my name in the copyright region when I send a major patch to
guix, and would rather not change it for this reason.

FMI see https://www.wikihow.com/Use-Plus-Addressing-in-Gmail
> 
> Also in that patch you have too many white space return indications
> between the preceeding package, and you have white space return at the
> EOF. This should be reduced to one and none, respectively.
Ok. So do I understand correctly patch 1 should have a single white space
after the package, but not patch 2?

> Next, if you could run `guix lint` on this package. Your synopsis and
> description sections are identical and do not conform to our guidelines. I
> suspect this was just the default from running `guix import pypi`.
> 
> If you need help with making synopsis and descriptions, here is the
> relevant documentation:
> https://guix.gnu.org/manual/en/html_node/Synopses-and-Descriptions.html
I forgot to change the synopsis and descriptions. I'll make sure I do that
before I send the fixed patches.
> 
> In patch 2: There should be a white space return before the package in
> this case, but was likely cut off from the improper EOF return in patch
> 1. Otherwise, this package looks okay aside from the issue with the
> synopsis and description.
> 
> Lastly, all of the commit messages need a period at the end. And the
> sub-header message for the patch which bumps Hy to 0.17 needs a period
> as well. You could also remove the redundant [inputs] section and simply
> make a comma-separated-list of new inputs. Also, if you could add
> something like,
> 
> --8<---------------cut here---------------start------------->8---
> Fixes: <link-to-original-bug-report>.
> --8<---------------cut here---------------end--------------->8---
> 
> to the patch that updates Hy, that way we can know where this patch
> series is predicated from. That would be superb!
Ok. I will make sure that happens.
> 
> Once we get these easy changes done we will push! If you could send your
> revisions with something like:
> 
> --8<---------------cut here---------------start------------->8---
> [PATCH v2 x/3]
> --8<---------------cut here---------------end--------------->8---
> 
In response to this email, or simply to [email-masked]? I'm guessing
either will work, but you are more likely to see a response to this email.
> 
> Again, I apologize for the radio silence.
> 
Not to worry. I had (and still have) other work to do, and this was a low-
priority task. I might not be able to send the fixed patches until possibly
the 18th or 19th. I'll send the corrected patches, and possibly contribute
other pending package definitions and/or bug reports as well.