Hi Maxime, (Moving to guix-devel; starting point at <https://issues.guix.gnu.org/55541#3>.)
Maxime Devos <maximede...@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