[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dealing with upstream issues
From: |
Ludovic Courtès |
Subject: |
Dealing with upstream issues |
Date: |
Mon, 27 Jun 2022 12:10:12 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
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
- Dealing with upstream issues,
Ludovic Courtès <=
Re: Dealing with upstream issues, zimoun, 2022/06/28