From: Maxime Devos <maximedevos@telenet.be>
To: zimoun <zimon.toutoune@gmail.com>, "Ludovic Courtès" <ludo@gnu.org>
Cc: Tobias Kortkamp <tobias.kortkamp@gmail.com>, guix-devel@gnu.org
Subject: Re: Dealing with upstream issues
Date: Tue, 28 Jun 2022 14:31:26 +0200 [thread overview]
Message-ID: <2dc71c54541e84a647187fb0e6e34672930b697a.camel@telenet.be> (raw)
In-Reply-To: <865yklf3vq.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4631 bytes --]
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
next prev parent reply other threads:[~2022-06-28 12:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6d31ff958ec0c75cbba8324a275315d195a54902.1653045472.git.tobias.kortkamp@gmail.com>
[not found] ` <87sfntu6ft.fsf@gnu.org>
[not found] ` <b6d482002f7773e65e02dbbbf354e1c0178b823a.camel@telenet.be>
2022-06-27 10:10 ` Dealing with upstream issues Ludovic Courtès
2022-06-27 10:30 ` Maxime Devos
2022-06-27 10:37 ` Maxime Devos
2022-06-27 12:32 ` zimoun
2022-06-27 14:20 ` Maxime Devos
2022-06-27 15:06 ` zimoun
2022-06-27 15:41 ` Maxime Devos
2022-06-28 11:01 ` zimoun
2022-06-28 12:21 ` Maxime Devos
2022-06-28 16:21 ` zimoun
2022-06-28 16:47 ` Maxime Devos
2022-06-28 17:36 ` zimoun
2022-06-28 20:03 ` Maxime Devos
2022-06-28 12:22 ` Maxime Devos
2022-06-28 12:31 ` Maxime Devos [this message]
2022-06-28 16:25 ` zimoun
2022-06-28 16:47 ` Maxime Devos
2022-06-29 6:07 ` bokr
2022-06-29 7:29 ` Missing tags in Debbugs? zimoun
2022-06-29 13:45 ` Bengt Richter
2022-06-30 11:53 ` Dealing with upstream issues Ludovic Courtès
2022-06-27 12:53 ` zimoun
2022-06-27 14:32 ` Maxime Devos
2022-06-27 15:23 ` zimoun
2022-06-27 15:47 ` Maxime Devos
2022-06-27 16:03 ` Maxime Devos
2022-06-27 16:14 ` Maxime Devos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2dc71c54541e84a647187fb0e6e34672930b697a.camel@telenet.be \
--to=maximedevos@telenet.be \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=tobias.kortkamp@gmail.com \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).