guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with upstream issues


From: Maxime Devos
Subject: Re: Dealing with upstream issues
Date: Tue, 28 Jun 2022 14:21:44 +0200
User-agent: Evolution 3.38.3-1

zimoun schreef op di 28-06-2022 om 13:01 [+0200]:
> Well, from my understanding, the question is: should a perfectly working
> and fine submission be delayed because unrelated-to-Guix issues are in
> upstream code?

This is not the question.  The dispute is about:

Maxime Devos: https://issues.guix.gnu.org/55541#3
> AFAICT the issues have not been reported upstream yet, so I don't
> think we can close this entry on debbugs yet. 

zimoun:
> Ludo said these unrelated-to-Guix issues are not blocker, from my
> understandings.  And I agree.  Do you disagree?

I agree too.  What I disagree with, is ignoring the bug.  The blocker
for me is: appropriate parties need to be at least informed of bug if
it isn't fixed.

> You are commenting on “standard” which somehow asks about explicit
> criteria.  And, you are implicitly commenting on blocking while
> issues from upstream are not fixed.  Instead of trying to deduce
> myself (and probably the wrong way), could you please explicitly
> write down your arguments?

Reviewer noticed a $bug.  This kind of $bug has two accepted and
standard methods for addressing it:

 (1) fix it (by replacing the configure script or patching it or
     sufficient substitute*).
     (a) in Guix (often work-around-ish, though often a work-around is
         sufficient for these kind of cross-compilation problems)
     (b) upstream (more work, sometimes more fulfilling, sometimes not 
         worth it
 (2) report it upstream (because it's more complicated than a simple
     'substitute*'.

Why?  It's a bug, needs to be fixed somehow, and for (2): we can't
solve everything ourselves.

What happened:

  Committer pushed changed, ignoring (1) and (2).

/me: What?  Why ignore the bugs?

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]