Re: The Little Guixer

[Yasuaki Kudo]

Let's do this together, all of us, and publish in complete Free Software format 
compiled by Guix 

> On Jun 4, 2022, at 01:41, Ludovic Courtès  wrote:
> 
> Sounds like a great idea; feel inclined to do so?  :-)
> 
> Ludo’.

Re: Move switch-symlinks to (guix build utils)

[bokr]

Hi,

I am not expert on kernel link internals, but if
you need/prefer atomic change to a specific link,
does my log [1] below suggest a way?

On +2022-06-03 21:30:39 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxime Devos  skribis:
> 
> >, Maybe replace
> >
> >(symlink target pivot)
> >
> > by (symlink/remove-old target pivot)
> >
> > where
> >
> > (define (symlink/remove-old target link)
> >   "Make a symbolic link named LINK pointing to TARGET.
> > If LINK already exists, it will be removed first.
> > This is not an atomic operation."
> >   (catch 'system-error
> > (lambda ()
> >   (symlink target link))
> > (lambda stuff
> >   (if (= (system-error-errno stuff) EEXIST)
> >   (begin
> > ;; remove old link and retry
> > (delete-file link)
> > (symlink/remove-old link target))
> >   (apply throw stuff)
> 
> Alright, SGTM (this procedure would be kept private).
> 
> So Arun, the floor is yours!  :-)
> 
> Ludo’.
>

[0]: (some "<--= note" notes edited in)
BTW: notice that Size: is number of chars in TARGET name, not the LINK name
--8<---cut here---start->8---
$ ln -sT TARGET LINK
$ stat LINK
  File: LINK -> TARGET
  Size: 6   Blocks: 0  IO Block: 4096   symbolic link
Device: fe00h/65024dInode: 19401553Links: 1   # <--= note inode number: 
mv will not change it
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 00:57:47.680832044 +0200
Modify: 2022-06-04 00:57:47.680832044 +0200
Change: 2022-06-04 00:57:47.680832044 +0200
 Birth: -
$ mv -v LINK WAS-LINK
renamed 'LINK' -> 'WAS-LINK'
$ stat WAS-LINK
  File: WAS-LINK -> TARGET
  Size: 6   Blocks: 0  IO Block: 4096   symbolic link # 
<--= TARGET is still 6 chars :)
Device: fe00h/65024dInode: 19401553Links: 1# <--= note inode 
number: did not change with mv
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 00:57:47.680832044 +0200
Modify: 2022-06-04 00:57:47.680832044 +0200
Change: 2022-06-04 00:58:33.617240104 +0200
 Birth: -
$ ln -sT NEW-TARGET LINK
$ stat LINK 
  File: LINK -> NEW-TARGET
  Size: 10  Blocks: 0  IO Block: 4096   symbolic link # 
<--= NEW-TARGET is 10 chars :)
Device: fe00h/65024dInode: 19401638Links: 1<--= note inode number: 
new for new use of LINK name
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 01:00:10.630121441 +0200
Modify: 2022-06-04 01:00:10.630121441 +0200
Change: 2022-06-04 01:00:10.630121441 +0200
 Birth: -
$ rm -v WAS-LINK  <--= note no OS objection to removing renamed old LINK
removed 'WAS-LINK'
$ stat *LINK*
  File: LINK -> NEW-TARGET
  Size: 10  Blocks: 0  IO Block: 4096   symbolic link
Device: fe00h/65024dInode: 19401638Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/bokr)   Gid: ( 1000/bokr)
Access: 2022-06-04 01:00:10.630121441 +0200
Modify: 2022-06-04 01:00:10.630121441 +0200
Change: 2022-06-04 01:00:10.630121441 +0200
 Birth: -
$ 
--8<---cut here---end--->8---

I'm guessing the inode rewrite involved in mv -v LINK WAS-LINK should be atomic?
Maybe some kernels have to struggle without good hardware support, but still 
atomic?

Maybe a kernel insider will chime in?
HTH some way.
--
Regards,
Bengt Richter

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

[Théo Maxime Tyburn]

Hi all,

> Would you be willing to coordinate work on Emacs-Guix for some time?
> If so, I’m in favor of granting you commit access so you can first push
> these four commits, and eventually apply patches that are submitted or
> fix bugs here and there.
>
> If Giovanni or Théo wants to do that, that’s fine too.  What we need is
> to make sure one of us/you can commit some time going forward to at
> least protect Emacs-Guix from bitrot, and ideally help improve it, as
> time permits.
>
> WDYT?

I can definitly participate in this. I wanted to add some functionalities 
myself anyway so
I think that would make sense. I am stil a beginner guix developer
though so I might not be able to solve intricated bugs. But have
my fare share of elisp hacking so I can probably solve the easy
ones. Hacking emacs-guix also seems like a nice way to start hacking
guix to mee.

> Bug reports would still go to , which you
> can access from the comfort of your Emacs with M-x debbugs-gnu.  :-)

That would be my first time using it, but it sounds like a nice tool.

> Thanks,
> Ludo’.

Thanks,
Théo

Re: On commit access, patch review, and remaining healthy

[Ricardo Wurmus]

Hi Ludo,

> Interesting.  Since I already used Gnus before, I didn’t have much to
> learn when I started using debbugs.el.
>
> I know some people here use debbugs.el with other email clients like
> mu4e, so perhaps they can comment?  We could add guidance in the
> manual.

Since some time mu4e uses gnus for displaying and responding to emails,
so the old hack to make debbugs.el work with mu4e is no longer needed.

-- 
Ricardo

Re: proposal: guix-ment...@gnu.org list/alias

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hey!
>
> Ricardo Wurmus  skribis:
>
>> I’d still want to have the patches hit guix-patches and the changes made
>> by a mentor detailed there.  guix-mentors is meant primarily as a
>> coordination space for mentors — it’s how new contributors get a
>> personal mentor for the journey from raw contribution to merge.
>
> So contributors themselves do not need to know about guix-mentors,
> right?  (My initial understanding was that they’d explicitly email
> guix-mentors in addition to guix-patches.)

Your initial understanding is correct.

If we can automate the involvement of guix-mentors somehow that would be
nice, of course, but the idea as presented involves new contributors
explicitly CC-ing guix-mentors.

-- 
Ricardo

Re: proposal: guix-ment...@gnu.org list/alias

[Ludovic Courtès]

Hey!

Ricardo Wurmus  skribis:

> I’d still want to have the patches hit guix-patches and the changes made
> by a mentor detailed there.  guix-mentors is meant primarily as a
> coordination space for mentors — it’s how new contributors get a
> personal mentor for the journey from raw contribution to merge.

So contributors themselves do not need to know about guix-mentors,
right?  (My initial understanding was that they’d explicitly email
guix-mentors in addition to guix-patches.)

Ludo’.

Re: On commit access, patch review, and remaining healthy

[Ludovic Courtès]

Hi,

Pier-Hugues Pellerin  skribis:

> As a new-new Guix user, I did find the review process or the time it
> takes really long.
> Maybe I've tackle too complex updates[0], I don't know but I don't
> have a clear path how to push it.

Yeah.  :-/

The long delays are mostly due to the lack of reviewers, but also, as
you point out, the more “complex” a patch series is, the more time it’ll
take before it’s reviewed (because it entails more work).

> Also, I don't want to say that one workflow is superior to the other
> but one thing that shines with theses forge
> is the automation and the simplicity to add tooling on pull request to
> reduce the burden to the reviewer:
>
> - linting
> - checks
> - commits log formatting check
> - CI jobs
> - codeowner assignment
> - build packages (partial or complete rebuild the world if needed)
> - license check
> - notification for stable pull request.

Yeah, I think there’s consensus on this.  :-)

> All theses are useful quality of life improvement for reviewers and
> reduce some of the friction and remove some of the
> non glamourous-task. Maybe it could be added to Mumi? Maybe a bot like
> Ofborg in NixOS could take care of some of the operation.

Yup.

> I haven't watched Arun presentation, I will search the list if the
> recording is up somewhere.

It’s right here:

  https://guix.gnu.org/en/blog/2022/online-guix-days-2022-announcement-2/

Thanks,
Ludo’.

Re: On commit access, patch review, and remaining healthy

[Ludovic Courtès]

Hi,

Brian Cully  skribis:

> Ludovic Courtès  writes:
>
>> If you are using Emacs, does debbugs.el have
>> shortcomings that make it a problem to review patches?

To be clear, the question was directed primarily at current committers.

> 1) It’d be nice if ‘M-x debbug-guix’ existed. I (briefly) looked at
> making such a command, thinking it’d be relatively straight-forward to
> just copy ‘debbugs-gnu’ and tweak some variables, but when it looked
> like it was going to take more than 10 minutes just to figure out how
> it was all put together I gave up as I can’t really dedicate time to
> it right now.

Try: C-u M-x debbugs-gnu.  From there you can choose ‘guix’,
‘guix-patches’, or anything else (info "(guix) Debbugs User
Interfaces").

> 2) IMHO, the documentation for debbugs is pretty poor. It mostly
> relies on GNUS documentation for things like mode help; and while this
> makes sense, GNUS is a big, complex package (which is why I use mu4e
> instead of it), and it really raises the barrier for understanding
> debbugs quite a lot.

I find the Debbugs User Guide, plus the docstrings and all, to be good
(info "(debbugs-ug) Top").

I use Gnus though so maybe there are issues I just don’t experience.

> 3) Even after reading all the documentation I could find, it doesn’t
> seem to work very well for an issue-tracker workflow. I still don’t
> know how to simply reply to a ticket. Let alone how to apply a patch
> to my tree (I did see documentation for how to do that to the Emacs
> source tree, but that’s not very useful — also, the key combinations
> feel very obtuse and hard for me to remember).
>
> So, right now, I just use it to browse, since I find it easier than
> mumi, but everything else happens with external tools. It’s very
> possible my n00b is showing right now and it’s easier to work with
> than it seems at first blush, but I’d say that means the documentation
> needs some dedicated, non-GNUS-oriented love. It would be very helpful
> if there were a HOWTO, like we used to do in the old days, with how to
> use it for simple tasks, and stick it in the info documentation and on
> the web.

Interesting.  Since I already used Gnus before, I didn’t have much to
learn when I started using debbugs.el.

I know some people here use debbugs.el with other email clients like
mu4e, so perhaps they can comment?  We could add guidance in the manual.

Thanks for your feedback!

Ludo’.

Re: Move switch-symlinks to (guix build utils)

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Maybe replace
>
>(symlink target pivot)
>
> by (symlink/remove-old target pivot)
>
> where
>
> (define (symlink/remove-old target link)
>   "Make a symbolic link named LINK pointing to TARGET.
> If LINK already exists, it will be removed first.
> This is not an atomic operation."
>   (catch 'system-error
> (lambda ()
>   (symlink target link))
> (lambda stuff
>   (if (= (system-error-errno stuff) EEXIST)
>   (begin
> ;; remove old link and retry
> (delete-file link)
> (symlink/remove-old link target))
>   (apply throw stuff)

Alright, SGTM (this procedure would be kept private).

So Arun, the floor is yours!  :-)

Ludo’.

Re: Move switch-symlinks to (guix build utils)

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Maybe replace
>
>(symlink target pivot)
>
> by (symlink/remove-old target pivot)
>
> where
>
> (define (symlink/remove-old target link)
>   "Make a symbolic link named LINK pointing to TARGET.
> If LINK already exists, it will be removed first.
> This is not an atomic operation."
>   (catch 'system-error
> (lambda ()
>   (symlink target link))
> (lambda stuff
>   (if (= (system-error-errno stuff) EEXIST)
>   (begin
> ;; remove old link and retry
> (delete-file link)
> (symlink/remove-old link target))
>   (apply throw stuff)

Alright, SGTM (this procedure would be kept private).

So Arun, the floor is yours!  :-)

Ludo’.

Re: Move switch-symlinks to (guix build utils)

[Maxime Devos]

Ludovic Courtès schreef op vr 03-06-2022 om 18:38 [+0200]:
> That’s EACCES?

It's EEXIST.

> > If we move it to (guix build utils), I'd prefer the bug to be addressed 
> > first.
> 
> Yes, better be cautious before “setting it in stone”.  Do you have a fix
> in mind?

Maybe replace

   (symlink target pivot)

by (symlink/remove-old target pivot)

where

(define (symlink/remove-old target link)
  "Make a symbolic link named LINK pointing to TARGET.
If LINK already exists, it will be removed first.
This is not an atomic operation."
  (catch 'system-error
(lambda ()
  (symlink target link))
(lambda stuff
  (if (= (system-error-errno stuff) EEXIST)
  (begin
;; remove old link and retry
(delete-file link)
(symlink/remove-old link target))
  (apply throw stuff)

?

Greetings,
Maxime.


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

Re: The Little Guixer

[Ludovic Courtès]

Sounds like a great idea; feel inclined to do so?  :-)

Ludo’.

Re: Release v1.4?

[Ludovic Courtès]

Hello!

zimoun  skribis:

> Schedule a release is the occasion to tackle some not-so-fun tasks as
> merging the ’staging’ branch [1], many upgrades as Haskell [2] or Julia,
> etc.

Thanks for the heads-up!  I think merging ‘staging’ should be
top-priority.  People are welcome to upgrade/reconfigure from it with:

  guix time-machine --branch=staging -- …

Remaining things to check:

  - [ ] system tests
  - [ ] status on non-x86_64 architectures

Ludo’.

Re: Move switch-symlinks to (guix build utils)

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Arun Isaac schreef op do 02-06-2022 om 20:36 [+0530]:
>> Hi Maxime,
>> 
>> > To avoid a world-rebuild, you could for now make a module (guix build
>> > symlinks) or such?  An alternative is (gnu build activation), but then
>> > some (guix ...) modules would depend on (gnu ...).
>> 
>> I don't really mind waiting for the next core-updates cycle. This
>> problem has been around for a long time. It wouldn't hurt much to wait a
>> bit longer. If there is consensus on this change, I can send a
>> patch. WDYT?
>
> Downside of (guix build utils): it makes it harder to modify switch-
> symlinks.  I don't know if that's too much of a downside in practice. 
> Also, there is a bug in switch-symlinks:
>
> (use-modules (guix utils))
> ;; simulate an interrupted switch-symlinks (C-c, power interruption, ...)
> (symlink "target" "link.new")
> ;; now try again
> (switch-symlinks "link" "target")
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure symlink: Bestand bestaat al: "link.new"

That’s EACCES?

> If we move it to (guix build utils), I'd prefer the bug to be addressed first.

Yes, better be cautious before “setting it in stone”.  Do you have a fix
in mind?

With this issue addressed, I think it’s fine to move to (guix build
utils) on ‘core-updates’.  We’ll have to run ‘make check’ to make sure
all users are updated, probably with #:select to clarify what binding
they need from (guix build utils).

Thanks,
Ludo’.

Re: proposal: guix-ment...@gnu.org list/alias

[zimoun]

Hi,

On Fri, 03 Jun 2022 at 13:48, Liliana Marie Prikler 
 wrote:

> 1. When a new contributor sends a mail to guix-patches, the mail gets
> added to a manual approval queue. (This currently happens)
> 2. A human operator manually approves of the patch as in flags it as
> "Not spam" (This currently happens)
> 3. A new issue number is claimed in debbugs, yadda yadda.
> 4. Since we know (from 1+2), that this is a new contributor, a separate
> message is sent to guix-mentors (from debbugs or what have you)
> informing mentors about this contribution.

IIUC, “new contributors” mean «first time to guix-patches»; when I could
send a (simple) R package and asking some mentoring and then send
another (more complex) package and also asking some mentoring.

Such approach is indeed a good way for catching first time contributor –
and it appears a good thing to catch. :-)


> Alternatively to the above, which would (in theory) forward the patches
> as soon as improved, we could implement this with a separate backend
> such as mumi, which would basically check for new patches, check
> whether any of those patches come from hitherto unknown sources, and if
> so send a mail towards guix-mentors.

Since it is #3, #1 and #2, indeed this step #4 would be a forward.
Well, I do not know how automatic it could be and how extra much work it
puts on the shoulder of the human operator (1+2) – already busy enough. :-)


> As for guix-mentors vs. other mailing lists, refer to Ricardo's initial
> proposal.  Interestingly, zimoun had a similar idea, but phrased it
> less wordy.

My proposal is that the contributor wanting a mentor uses a specific
tools for sending to guix-patches; tool which uses internal of Debbugs
(X-Debbugs-CC) triggering the CC at step #3.


Cheers,
simon

Re: proposal: guix-ment...@gnu.org list/alias

[Tobias Geerinckx-Rice]

Liliana Marie Prikler 写道：

So first things first, this would only apply to guix-patches (I
believe), since that is where "contributions" as in "patches 
that need

review" are sent to.  My proposal is roughly as follows:
1. When a new contributor sends a mail to guix-patches, the mail 
gets

added to a manual approval queue. (This currently happens)
2. A human operator manually approves of the patch as in flags 
it as

"Not spam" (This currently happens)
3. A new issue number is claimed in debbugs, yadda yadda.


It's actually 3, 1, 2 (yeah).


Does that help clear things up?


Yes!  Thank you.

As for guix-mentors vs. other mailing lists, refer to Ricardo's 
initial
proposal.  Interestingly, zimoun had a similar idea, but phrased 
it

less wordy.


So we replace the alias with a proper list?

(I'd already asked the sysadmins to create a list, but cancelled 
it when I noticed the alias.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: proposal: guix-ment...@gnu.org list/alias

[Liliana Marie Prikler]

Hi Tobias,

Am Freitag, dem 03.06.2022 um 13:21 +0200 schrieb Tobias Geerinckx-
Rice:
> Hi Lily,
> 
> Liliana Marie Prikler 写道：
> > That is once it's established that a new
> > contribution is actually a contribution, the patch is forwarded
> > separately to guix-mentors (along with reply-to: for the 
> > original bug etc. set up in a way that's useful to mentors),
> > claiming takes place, and so on.
> 
> I have trouble parsing this.
> 
> Can you highlight the difference(s) with the existing Guix lists, 
> if any?
So first things first, this would only apply to guix-patches (I
believe), since that is where "contributions" as in "patches that need
review" are sent to.  My proposal is roughly as follows:
1. When a new contributor sends a mail to guix-patches, the mail gets
added to a manual approval queue. (This currently happens)
2. A human operator manually approves of the patch as in flags it as
"Not spam" (This currently happens)
3. A new issue number is claimed in debbugs, yadda yadda.
4. Since we know (from 1+2), that this is a new contributor, a separate
message is sent to guix-mentors (from debbugs or what have you)
informing mentors about this contribution.

My proposal is to have step 4 implemented in software, sitting in
debbugs, the approval queue software, or possibly both depending on how
much interaction they need, rather than reminding potential newcomers
that guix-mentors exists and that they should CC it to get faster code
review.

Alternatively to the above, which would (in theory) forward the patches
as soon as improved, we could implement this with a separate backend
such as mumi, which would basically check for new patches, check
whether any of those patches come from hitherto unknown sources, and if
so send a mail towards guix-mentors.

Does that help clear things up?

As for guix-mentors vs. other mailing lists, refer to Ricardo's initial
proposal.  Interestingly, zimoun had a similar idea, but phrased it
less wordy.

Cheers

Re: proposal: guix-ment...@gnu.org list/alias

[Tobias Geerinckx-Rice]

Hi Lily,

Liliana Marie Prikler 写道：

That is once it's established that a new
contribution is actually a contribution, the patch is forwarded
separately to guix-mentors (along with reply-to: for the 
original bug
etc. set up in a way that's useful to mentors), claiming takes 
place,

and so on.


I have trouble parsing this.

Can you highlight the difference(s) with the existing Guix lists, 
if any?


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: proposal: guix-ment...@gnu.org list/alias

[Ricardo Wurmus]

Liliana Marie Prikler  writes:

> As a specific measure against potential abuse as well as a way of
> helping out newcomers, what if instead of making new contributors CC
> guix-mentors, we made it so that forwarding to guix-mentors is handled
> by the spam filter?  That is once it's established that a new
> contribution is actually a contribution, the patch is forwarded
> separately to guix-mentors (along with reply-to: for the original bug
> etc. set up in a way that's useful to mentors), claiming takes place,
> and so on.

I wouldn’t know how to set this up, but if you have an idea, I’d be
happy to see it implemented.

-- 
Ricardo

Re: proposal: guix-ment...@gnu.org list/alias

[Liliana Marie Prikler]

Am Mittwoch, dem 01.06.2022 um 22:17 +0200 schrieb Ricardo Wurmus:
> Hi,
> 
> to help new contributors get their first contribution into Guix I
> think it would be good to do this:
> 
> 1. create a new private mailing list or mailing alias
> guix-ment...@gnu.org
> 
> 2. ask for experienced Guix contributors who are committed to helping
> new contributors to subscribe to the list
> 
> 3. update the Contributing section in the manual (and the website) to
> suggest Cc-ing guix-ment...@gnu.org for a first contribution.
> 
> 4. have subscribers to guix-ment...@gnu.org “claim” a contribution
> within 48 hours, to avoid dilution of responsibilit.  Every
> contribution must be acknowledged.
> 
> [...]
> 
> What do you think about this?
As a specific measure against potential abuse as well as a way of
helping out newcomers, what if instead of making new contributors CC
guix-mentors, we made it so that forwarding to guix-mentors is handled
by the spam filter?  That is once it's established that a new
contribution is actually a contribution, the patch is forwarded
separately to guix-mentors (along with reply-to: for the original bug
etc. set up in a way that's useful to mentors), claiming takes place,
and so on.

Cheers

Re: proposal: guix-ment...@gnu.org list/alias

[jbranso]

June 2, 2022 4:00 AM, "Ricardo Wurmus"  wrote:

> zimoun  writes:
> 
>> Ah sorry, I overcomplicate the discussion. :-)
> 
> Hah, no worries! It’s worth discussing this before we implement a
> workflow that ends up being *more* confusing than the status quo.
> 
>> To me, it could be nice to have a tiny script (or Guix extension or
>> subcommand), maybe in etc/ which simplifies the workflow; something
>> similar to ’etc/committer.scm’.
>> 
>> The workflow would be:
>> 
>> $ edit code
>> $ git commit
>> $ etc/mentoring.scm
>> 
>> where etc/mentoring would generate the patch(es), add X-Debbugs-CC and
>> send; assuming a correct ~/.gitconfig. And maybe this script could
>> provide a simple hint for configuring git-send-email.
>> 
>> Even, we could imagine that this tiny script would hint the user to run
>> “guix lint” or “guix style” before pressing yes at the send step.
> 
> All good ideas, though I think setting up “git send-email” is a pretty
> big problem for many people — myself included! Would be nice if that
> could be simplified, too.

I always use this website to remind myself how to use git send-email:
https://git-send-email.io/

We could out that information in the guix manual or link to it.  :)

> 
>> From my experience, the most confusing is the “wait from Debbugs ID”
>> part, i.e., check your inbox or spam. And I do not know how it could be
>> simplified.
> 
> Yes, on top of that comes the gray-listing, which increases the waiting
> time.
> 
> Perhaps… we shouldn’t use Debbugs directly. I have a couple of
> annoyances with Debbugs, including the fact that we cannot configure the
> contents of the emails it sends out. Maybe it is time to implement a
> friendlier email-based frontend…
> 
> --
> Ricardo

Re: Feed on specific topic (public-inbox?)

[zimoun]

On Fri, 03 Jun 2022 at 10:22, zimoun  wrote:

> Note that recent ’public-inbox’ comes from with the tool ’lei’. This
> tool ’lei’ allows to query a public-inbox server and then fetch some
> filtered messages to use it locally.  Currently, the Guix package is at
> 1.6 and it requires an update at 1.7; discussed here [3].  In this
> message [4], you can find some Emacs workflow using public-inbox.

My bad, I am not enough up to date. :-)  Recent commit:
1e1de837190d1c08fae369a4cb3bf43a433abed1 from Wed Jun 1 provides
public-inbox v1.8, so it is now easy to test ’lei’. :-)


Cheers,
simon

Feed on specific topic (public-inbox?)

[zimoun]

Hi,

On Thu, 02 Jun 2022 at 21:35, Luis Felipe  wrote:

> As for reviewing patches or just taking a look at reported issues
> against parts of Guix one is interested, it would be easier if there
> were some kind of subscription system. Say, I'd like to subscribe to
> issues on Python packages, Spanish translation, and guix-artwork. I
> know this kind of subscription thing has been mentioned before,
> though. 

As discussed in «Incentives for review» [1], using public-inbox, you can
filter using «dfn: match filename from diff» or even write more complex
queries [2].  For instance, read from your browser,

https://yhetil.org/guix-patches/?q=dfn:python

And you can even follow a feed, for instance:

https://yhetil.org/guix-patches/?q=dfn:python=A

Note that recent ’public-inbox’ comes from with the tool ’lei’. This
tool ’lei’ allows to query a public-inbox server and then fetch some
filtered messages to use it locally.  Currently, the Guix package is at
1.6 and it requires an update at 1.7; discussed here [3].  In this
message [4], you can find some Emacs workflow using public-inbox.


For guix-artwork, as a whole, I do not know what would be the best
query.

What is missing from Mumi is the use of Message-ID for an easy
referencing between the email tools, as discussed in [5].


As we discussed once, maybe it would help to have an “official“
public-inbox instance for the Guix project.  For instance, Org folks
uses a public-inbox instance [6] and switched 2 years ago [7].

>From my point of view, public-inbox would fix some annoyance about the
“email workflow”.  Now the question is: who help in the maintenance? :-)


1: 
2: 
3: 
4: 
5: 
6: 
7: 


Cheers,
simon