Dealing with upstream issues

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxime,

(Moving to guix-devel; starting point at
<https://issues.guix.gnu.org/55541#3>.)

Maxime Devos <maximedevos@telenet.be> skribis:

>> That said, I think it’s a bit too much to ask of a downstream packager
>> or user to address these issues.  As I see it, these issues should be
>> reported upstream and addressed upstream.
>> 
>> I hope that makes sense!
>
> AFAICT the issues have not been reported upstream yet, so I don't think
> we can close this entry on debbugs yet.  While I'd like for downstream
> packaging to be trivial, the sad reality is that sometimes is not the
> case, the issues are still there and need to be resolved somehow (fixed
> downstream or upstream, or reported upstream).
>
> If not by the new downstream packager that submitted the patch, then by
> the the one committing the patch, or by a reviewer, or by some more
> neboluous role of a random Guix contributor, or in some exceptional
> cases the issue could be considered ‘too difficult and not too bad’
> with some corresponding reasoning.  (It's most efficient if the
> reporting or fixing is done directly by the submitter, but if the
> submitter can't do it for whatever reason, then surely something can
> eventually be worked out by other people, albeit more slowly.)
>
> However, AFAICT, none of that has happened yet.
>
> More generally, I don't think we should have an ‘packages included in
> Guix should be good, unless submitted by a newbie’ exception.  Also,
> potentially the new submitter would _like_ to learn more about Guix
> (and have time for it, etc.) and learn how to improve things?
>
> In the future, if someone submits a patch and I notice it has some
> complicated problems, should I just ignore the complicated problems and
> just LGTM?  This seems contrary to the concept of reviewing to me. 
> (This is probably not what you meant, but to me, this is implied by
> your response.)

You did thorough review work and pointed at valid issues, thanks for
doing that.

Those issues are upstream issues, in that they’re not Guix-specific.
For instance, that ./configure runs binaries effectively prevents
cross-compilation, whether in Guix or not; that code potentially
violates C99 strict-aliasing rules is also not Guix-specific.

My view is that such issues should be reported upstream but cannot alone
block package adoption in Guix.

Regarding the review process, I think we should strive for a predictable
process—not requesting work from the submitter beyond what they can
expect.  Submitters can be expected to follow the written rules¹ and
perhaps a few more rules (for example, I don’t think we’ve documented
the fact that #:tests? #f is a last resort and should come with a
comment).  However, following that principle, we reviewers cannot
reasonably ask for work beyond that.  Upholding this principle makes
sure submitters can have a good picture of what it will take for their
work to be included.

Related to that, I think it’s important to have a consistent review
process.  In other words, we should be equally demanding for all patches
to avoid bad surprises or a feeling of double standard.

I hope this clarifies my view!

Thanks,
Ludo’.

¹ https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html