Re: Dealing with upstream issues

[zimoun]

Hi Maxime,

I am confused by your replies in the thread.  Maybe, I miss the topic of
the comment by Ludo.

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?

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

Reading you, I am missing what you are suggesting.

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?  Do you think that patch#55541 should be delayed while
upstream is not supported by cross-compilation?

I agree that fixing as much as possible and earlier is the best.
However, there is a tension between being perfect and doing with the
resources at hand.  For sure, it would be better if submitter also
report (or fix) upstream some issues, but I am not convinced the Guix
project should make this as mandatory requirements for inclusion of
submitted packages in Guix.  Do you think that patch#55541 should be
delayed while submitter has not open an upstream issue?


Last, I miss these comments about old bugs and what you are implicitly
suggesting with them.  Are you suggesting that old unsolved bugs are
closed without valid motivation?

>> Old unsolved bugs are still open
>
> Sometimes they aren't:

> * https://issues.guix.gnu.org/45828

Closed because:

        This can happen if guix-daemon was restarted but ‘guix publish’ wasn’t:
        ‘guix publish’ opens only one connection to the store at startup time,
        and then never tries to re-open it.  There was an old bug on this topic:

        https://issues.guix.gnu.org/26705

        Back then I marked it as ‘wontfix’ because:

          1. Losing a connection to the daemon Does Not Happen™ in normal
             conditions.  Namely, upon ‘herd restart guix-daemon’, ‘guix
             publish’ is automatically restarted.  One situation where ‘guix
             publish’ is not restarted is if one does “killall guix-daemon” or
             similar.  (Perhaps that’s something to fix in the Shepherd?)

> * https://issues.guix.gnu.org/26705

Closed because:

        For now I’m closing this bug as “wontfix” because I’ve never seen any
        occurrence of #2, and because #1 cannot happen on GuixSD (if 
‘guix-daemon’
        is restarted, the shepherd will also restart ‘guix-publish’.

> * https://issues.guix.gnu.org/25719 (exception handling hasn't been cleaned 
> up before closing)

Closed because:

        I haven't seen this particular exception in a long time.  I cannot tell 
whether
        the actual usability has been fixed, though--it could be that only the 
servers
        are more reliable and this code path is thus not currently being 
entered.

> * https://issues.guix.gnu.org/44199 (it's a WIP, not completed yet, but still 
> closed!)

This history is:

Maxime Devos    wrote on 24 Oct 2020 21:47
zimoun          wrote on 27 Oct 2020 14:39
Maxime Devos    wrote on 27 Oct 2020 19:50
Maxime Devos    wrote on 1  Nov 2020 01:05
Ludovic Courtès wrote on 15 Nov 2020 22:13

        > This patch defines a `gnunet-fetch' method, allowing for downloading
        > files from GNUnet by their GNUnet chk-URI.

        While I think this is a laudable goal, I’m reluctant to including GNUnet
        support just yet because, as stated in recent release announcements,
        GNUnet is still in flux and not considered “production ready”.

        So I think we should keep it around and revisit this issue when GNUnet
        is considered “stable”.  WDYT?

zimoun          wrote on 16 Nov 2020 01:35
Maxime Devos    wrote on 18 Nov 2020 20:14

        > So I think we should keep it around and revisit this issue when
        > GNUnet
        > is considered “stable”.  WDYT?

        Sounds reasonable to me. There are also a lot of missing parts: a
        service definition for Guix System, findings substitutes, finding
        sources by hash (the one Guix uses, not the GNUnet hash) ..., so it
        isn't like my rudimentary patch was usable on large scale anyway.

Ludovic Courtès wrote on 18 Nov 2020 23:12

        tags 44199 wontfix
        close 44199
        quit


Therefore, if you have more details for one of these reports, feel free
to comment, provide more info or fix; for sure it will help.


Cheers,
simon