Re: Dealing with upstream issues

[Maxime Devos]

zimount:
> 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?

You often close bugs with as rationale: ‘no response since X months,
hence closing’, so it seems to me that you would simply close bug
reports if the bug reporter is gone.

> > > 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’.

It's a bug marked "wontfix" -- sure, I suppose #1 cannot happen on Guix
System, but there are foreign distros too.

> > * 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.

These kind of things are still bugs -- occassionally we see these kind
of bug reports pop up, so likely the underlying issue is still there
and error handlings is still loosy.

> > * 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.

Oh right that was a bad example, the approach is broken (no http/https
fallbacks, bootstrap problems, etc); current idea is to extend
(guix download) with gnunet://fs/... instead.



> 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.

That's the issue I wanted to highlight -- issues are closed before
being fixed when the the reporter disappears (and hence, cannot provide
"more info", or has other things to do than provide a fix by
theirselves), even if the bug is understood.

Greetings,
Maxime.

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