[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dealing with upstream issues
Dealing with upstream issues
Mon, 27 Jun 2022 12:10:12 +0200
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
(Moving to guix-devel; starting point at
Maxime Devos <email@example.com> 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
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!
Re: Dealing with upstream issues, zimoun, 2022/06/28
- Dealing with upstream issues,
Ludovic Courtès <=