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
