[Top][All Lists]

[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:31:26 +0200
User-agent: Evolution 3.38.3-1

> 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:
> > *
> 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:
>         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?)
> > *
> 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.

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

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


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

reply via email to

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