From: zimoun <zimon.toutoune@gmail.com>
To: "Maxime Devos" <maximedevos@telenet.be>,
"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 13:01:45 +0200 [thread overview]
Message-ID: <865yklf3vq.fsf@gmail.com> (raw)
In-Reply-To: <6d2b1052b3e63a67c42c4e6ce431b3f1bb4b4605.camel@telenet.be>
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
next prev parent reply other threads:[~2022-06-28 11:06 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 [this message]
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
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=865yklf3vq.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=maximedevos@telenet.be \
--cc=tobias.kortkamp@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).