user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
* [PATCH v1] git-send-email-reply: Append subject
@ 2021-03-26 16:31 Stavros Ntentos
  2021-03-26 19:36 ` Eric Wong
  0 siblings, 1 reply; 9+ messages in thread
From: Stavros Ntentos @ 2021-03-26 16:31 UTC (permalink / raw)
  To: meta; +Cc: Eric Wong, stdedos+git, Stavros Ntentos

I keep copy-pasting the addresses provided,
I keep writing my plaintext reply in a file,
and I keep forgetting to add a subject
(because I am "just" writing a plaintext file)

Teach `git-send-email-reply` to append a `--subject` line.

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
---
 lib/PublicInbox/Reply.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/PublicInbox/Reply.pm b/lib/PublicInbox/Reply.pm
index 8226fdc3..0f312fbe 100644
--- a/lib/PublicInbox/Reply.pm
+++ b/lib/PublicInbox/Reply.pm
@@ -103,6 +103,8 @@ sub mailto_arg_link {
 		}
 	}
 
+	push @arg, "--subject=".squote_maybe($subj);
+
 	# I'm not sure if address obfuscation and mailto: links can
 	# be made compatible; and address obfuscation is misguided,
 	# anyways.
-- 
2.31.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-26 16:31 [PATCH v1] git-send-email-reply: Append subject Stavros Ntentos
@ 2021-03-26 19:36 ` Eric Wong
       [not found]   ` <CAHMHMxVS4tVvUYvWUmk8L8oqPPxtYW-MF_57Vwuzug-asWQiQg@mail.gmail.com>
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2021-03-26 19:36 UTC (permalink / raw)
  To: Stavros Ntentos; +Cc: meta, stdedos+git

Stavros Ntentos <stdedos@gmail.com> wrote:
> I keep copy-pasting the addresses provided,
> I keep writing my plaintext reply in a file,
> and I keep forgetting to add a subject
> (because I am "just" writing a plaintext file)
> 
> Teach `git-send-email-reply` to append a `--subject` line.

OK, that seems reasonable.

> Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>

Unlike the git.git project, we don't require Signed-off-by.
Furthermore, publicizing "noreply" addresses doesn't seem
worthwhile since they're not usable email addresses.

> diff --git a/lib/PublicInbox/Reply.pm b/lib/PublicInbox/Reply.pm
> index 8226fdc3..0f312fbe 100644
> --- a/lib/PublicInbox/Reply.pm
> +++ b/lib/PublicInbox/Reply.pm
> @@ -103,6 +103,8 @@ sub mailto_arg_link {
>  		}
>  	}
>  
> +	push @arg, "--subject=".squote_maybe($subj);
> +
>  	# I'm not sure if address obfuscation and mailto: links can
>  	# be made compatible; and address obfuscation is misguided,
>  	# anyways.

That shows a URI-encoded subject unless address obfuscation is enabled.

I think the following needs to be squashed in:

diff --git a/lib/PublicInbox/Reply.pm b/lib/PublicInbox/Reply.pm
index 0f312fbe..2a1066d2 100644
--- a/lib/PublicInbox/Reply.pm
+++ b/lib/PublicInbox/Reply.pm
@@ -74,6 +74,7 @@ sub mailto_arg_link {
 	my $obfs = $ibx->{obfuscate};
 	my $subj = $hdr->header('Subject') || '';
 	$subj = "Re: $subj" unless $subj =~ /\bRe:/i;
+	my $subj_raw = $subj;
 	my $mid = $hdr->header_raw('Message-ID');
 	push @arg, '--in-reply-to='.squote_maybe(mid_clean($mid));
 	my $irt = mid_href($mid);
@@ -103,7 +104,7 @@ sub mailto_arg_link {
 		}
 	}
 
-	push @arg, "--subject=".squote_maybe($subj);
+	push @arg, "--subject=".squote_maybe($subj_raw);
 
 	# I'm not sure if address obfuscation and mailto: links can
 	# be made compatible; and address obfuscation is misguided,

No need to resend if that looks alright to you, I can squash
before pushing.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
       [not found]   ` <CAHMHMxVS4tVvUYvWUmk8L8oqPPxtYW-MF_57Vwuzug-asWQiQg@mail.gmail.com>
@ 2021-03-26 21:35     ` Eric Wong
  2021-03-27  8:39       ` Stavros Ntentos
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2021-03-26 21:35 UTC (permalink / raw)
  To: Σταύρος
	Ντέντος
  Cc: meta

Σταύρος Ντέντος <stdedos@gmail.com> wrote:
> On Fri, 26 Mar 2021 at 21:36, Eric Wong <e@80x24.org> wrote:
> > Stavros Ntentos <stdedos@gmail.com> wrote:
> > > Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
> >
> > Unlike the git.git project, we don't require Signed-off-by.
> > Furthermore, publicizing "noreply" addresses doesn't seem
> > worthwhile since they're not usable email addresses.
> 
> Forces of habit:
> * git.git requires it, and
> * github masks the e-mail addresses (from weird groupies), and tracks
> contributions.

Fair enough, pushed as 90ca1ac28edb2e8a64c30bb4be723643c646df89 with
t/reply.t adjustments:

  https://public-inbox.org/meta/90ca1ac28edb2e8a64c30bb4be723643c646df89/s/

Also, please don't send HTML email.  It wastes storage, bandwidth,
and CPU cycles (spam filtering) for everybody involved.

> LGTM; I am anyway not accustomed to perl, and neither do I have a testing
> server.
> Hopefully, there is a staging environment (or an easy-to-docker-setup one?)
> that this can be POCed.

I try to stick to widely-packaged dependencies to avoid the need
for things like Docker (which I've never used).  It should be
reasonably easy-to-install on most GNU/Linux and *BSD distros;
do you use anything exotic that's not covered in INSTALL and
HACKING?

	https://public-inbox.org/INSTALL
	https://public-inbox.org/HACKING

> Changes are anyway small enough, so I considered it safe to do it so.

Yes, already deployed to the server that runs public-inbox.org/meta
(I do development on that server :x)

Thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-26 21:35     ` Eric Wong
@ 2021-03-27  8:39       ` Stavros Ntentos
  2021-03-27  9:54         ` Eric Wong
  0 siblings, 1 reply; 9+ messages in thread
From: Stavros Ntentos @ 2021-03-27  8:39 UTC (permalink / raw)
  To: e; +Cc: meta, stdedos

> Fair enough, pushed as 90ca1ac28edb2e8a64c30bb4be723643c646df89 with
> t/reply.t adjustments:
>
>   https://public-inbox.org/meta/90ca1ac28edb2e8a64c30bb4be723643c646df89/s/

Cool! ... but, I don't see it e.g. here :-p
	https://public-inbox.org/meta/20210326213517.GA5730@dcvr/

I thought you said you deployed it :/

> Yes, already deployed to the server that runs public-inbox.org/meta
> (I do development on that server :x)

Would it make sense for you to "symlink" /meta/ to /public-inbox/?
(as it is for git.git --> /git/)

> Also, please don't send HTML email.  It wastes storage, bandwidth,
> and CPU cycles (spam filtering) for everybody involved.

It was definitely not my intention to mess up systems.
It was one of the last things I did that night (my timezone), and I thought:
just a "LGTM" response is maybe not that nice, and
I am a bit too tired to full-fletched git-send-email reply to it.
(because so far, I am manually copy-paste-format-reply from my text editor).

If anyone has more instructions on how to meld Gmail with git-send-email and friends,
for an inbox that doesn't normally reside in a said computer, I am all ears. :-D

> I try to stick to widely-packaged dependencies to avoid the need
> for things like Docker (which I've never used). It should be
> reasonably easy-to-install on most GNU/Linux and *BSD distros;
> do you use anything exotic that's not covered in INSTALL and
> HACKING?

It's not about using something "more fancy"; it's just about keeping a "separatation"
between my normal system, and the system I want to develop x-or-y project.

Docker allows me to deploy any OS (debian stretch) above any OS (in this case Ubuntu bionic)
in its pristine state, super light-weight and ready to go.

tl;dr: With some (maybe not so much) considerable work from your side,
I could be looking at a minified public inbox clone, with some lightweight repo and e-mails
inserted, to which I could've made my changes, and (in that terminal) type `make deploy`.
Then, I would've seen here https://localhost/meta/20210326213517.GA5730@dcvr/ (or some other
equivalent page) what I expected to have seen here https://public-inbox.org/meta/20210326213517.GA5730@dcvr/

Then, when I was done, I would've written `docker rm -f $container_sha`, and poof!
Nothing ever existed, nothing is running, no resources used (except caches of the
"docker layers" used to build the docker image)

Across any docker-supported system, no matter what your base is.

(Okay, maybe it wasn't so much tl;dr after all :-D)

It's not so hard to insert it (albeit clumsily) into your toolchain.
You can even write it quite easily, or I could even convert you a "deploy all".sh
script you may have laying around on top of debian buster.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-27  8:39       ` Stavros Ntentos
@ 2021-03-27  9:54         ` Eric Wong
  2021-03-27 14:01           ` Σταύρος Ντέντος
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2021-03-27  9:54 UTC (permalink / raw)
  To: Stavros Ntentos; +Cc: meta

Stavros Ntentos <stdedos@gmail.com> wrote:
> > Fair enough, pushed as 90ca1ac28edb2e8a64c30bb4be723643c646df89 with
> > t/reply.t adjustments:
> >
> >   https://public-inbox.org/meta/90ca1ac28edb2e8a64c30bb4be723643c646df89/s/
> 
> Cool! ... but, I don't see it e.g. here :-p
> 	https://public-inbox.org/meta/20210326213517.GA5730@dcvr/
> 
> I thought you said you deployed it :/

Oops :x  I finished the deploy, now :>

> > Yes, already deployed to the server that runs public-inbox.org/meta
> > (I do development on that server :x)
> 
> Would it make sense for you to "symlink" /meta/ to /public-inbox/?
> (as it is for git.git --> /git/)

Not really, since the address is meta@public-inbox.org.
"public-inbox" is already a long name, and
"public-inbox.org/public-inbox" is kinda annoyingly long.

(and I've been preferring <80x24.org|yhbt.net>/public-inbox.git
 for the git repo).

> > Also, please don't send HTML email.  It wastes storage, bandwidth,
> > and CPU cycles (spam filtering) for everybody involved.
> 
> It was definitely not my intention to mess up systems.
> It was one of the last things I did that night (my timezone), and I thought:
> just a "LGTM" response is maybe not that nice, and
> I am a bit too tired to full-fletched git-send-email reply to it.
> (because so far, I am manually copy-paste-format-reply from my text editor).
> 
> If anyone has more instructions on how to meld Gmail with git-send-email and friends,
> for an inbox that doesn't normally reside in a said computer, I am all ears. :-D

It's been a few years since I checked, but I seem to recall
there being an option in the web UI of Gmail.  Or so I'm told,
since I get plenty of text-only mail from Gmail users.

> > I try to stick to widely-packaged dependencies to avoid the need
> > for things like Docker (which I've never used). It should be
> > reasonably easy-to-install on most GNU/Linux and *BSD distros;
> > do you use anything exotic that's not covered in INSTALL and
> > HACKING?
> 
> It's not about using something "more fancy"; it's just about keeping a "separatation"
> between my normal system, and the system I want to develop x-or-y project.

I understand that, I've been using chroots (often aided by
debootstrap) since the early 2000s; though much less in recent
years since distros have gotten better (and I use less code).

> Docker allows me to deploy any OS (debian stretch) above any OS (in this case Ubuntu bionic)
> in its pristine state, super light-weight and ready to go.

Everything I've read about Docker sounds scary when people are
grabbing binaries and code from random distributors and just
running it blindly.  IMHO it encourages dangerous behavior.

Having duplicates of things like libc or even Perl is total
overkill here and not remotely lightweight in my book.

I don't expect anybody to trust me enough to run public-inbox
without reading it (which is why there'll never be JavaScript).

We only distribute source so people can always read what they're
running.  We even use a language that makes binary distribution
(nearly) impossible.

<snip>

> (Okay, maybe it wasn't so much tl;dr after all :-D)

> It's not so hard to insert it (albeit clumsily) into your toolchain.
> You can even write it quite easily, or I could even convert you a "deploy all".sh
> script you may have laying around on top of debian buster.

Not exactly.  I don't like installing/running software in
general, especially not stuff in languages I've yet to learn
(golang).

I would never introduce any soft or hard dependency into a
project without being knowledgeable and comfortable about it,
first; and that can take a LOT of time and lead me down rabbit
holes...

For example, implementing IMAP support caused me to fix several
bugs in Mail::IMAPClient.  There's also several bugs fixed
in libgmime even though we still haven't started using it (and
may not), and a couple other mail things we don't use.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-27  9:54         ` Eric Wong
@ 2021-03-27 14:01           ` Σταύρος Ντέντος
  2021-03-27 19:32             ` Eric Wong
  0 siblings, 1 reply; 9+ messages in thread
From: Σταύρος Ντέντος @ 2021-03-27 14:01 UTC (permalink / raw)
  To: meta; +Cc: Eric Wong

With regards,
Ntentos Stavros


On Sat, 27 Mar 2021 at 11:54, Eric Wong <e@80x24.org> wrote:
> > I thought you said you deployed it :/
>
> Oops :x  I finished the deploy, now :>

Yeah, I saw it a bit later :-p :-D

> > Would it make sense for you to "symlink" /meta/ to /public-inbox/?
> > (as it is for git.git --> /git/)
>
> Not really, since the address is meta@public-inbox.org.
> "public-inbox" is already a long name, and
> "public-inbox.org/public-inbox" is kinda annoyingly long.
>
> (and I've been preferring <80x24.org|yhbt.net>/public-inbox.git
>  for the git repo).

Remember that a symlink (or a 30x redirect) does not cost you anything :-p
It _is_ longer, and it doesn't cost you anything, for the sake of
"finding where is something where you look for it to be" ;-)

> It's been a few years since I checked, but I seem to recall
> there being an option in the web UI of Gmail.

It does, and it is a bit hidden, and a bit global-ish: If you send
e-mails at night ...

> Everything I've read about Docker sounds scary when people are
> grabbing binaries and code from random distributors and just
> running it blindly.  IMHO it encourages dangerous behavior.

Pulling solely from "sane-ish sources" (buster from Debian and your
code from your repo),
should it be okay. The risks (as stated above) should ...

> Having duplicates of things like libc or even Perl is total
> overkill here and not remotely lightweight in my book.
>
> I don't expect anybody to trust me enough to run public-inbox
> without reading it (which is why there'll never be JavaScript).
>
> We only distribute source so people can always read what they're
> running.  We even use a language that makes binary distribution
> (nearly) impossible.

... be outweighed by benefits (clean add and remove, single-ish
up-and-running command).
Of course, you are right of claiming that anywhere, anything can be
inserted - and the more
you pull, the more things you expose yourself to.

https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/

> I would never introduce any soft or hard dependency into a
> project without being knowledgeable and comfortable about it,
> first; and that can take a LOT of time and lead me down rabbit
> holes...

Yeah, me too :-D
Having a more clean deploy&isolation&remove process would facilitate
in me testing more
and providing a cleaner patchset to you.

You might have fixed my patchset yourself (thanks!) but not everyone
is willing to spend time on it.
On the other hand, I am not willing to "pollute" my system with
something tying itself more or less to my system.
(It's not the pollution that I am afraid of, but the sanitization afterwards).
I've barely used chroots, and I am not comfortable using them (because
they require sudo).

Not to say that I am "that comfortable" using docker either! However,
they have created a group which,
if I add myself on it, it (hopefully) uses only the minimal set of
required privileges to do, whatever it is that it does,
without requiring me to type "sudo" (which, I keep telling to myself
that it is "something dangerous" overall).

If you have some tl;dr knowledge on how to make (s)chroots to work
cleanly without any sudo
(after I review a specific subset of rights & get myself access to
e.g. `/var/chroots/*` directory),
I am all ears!

A lot of compiled deb packages use that one way or another, and (mistakenly?)
I feel more comfortable installing via `apt-get install package.deb`
than `make install`.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-27 14:01           ` Σταύρος Ντέντος
@ 2021-03-27 19:32             ` Eric Wong
  2021-03-28 16:00               ` Σταύρος Ντέντος
  0 siblings, 1 reply; 9+ messages in thread
From: Eric Wong @ 2021-03-27 19:32 UTC (permalink / raw)
  To: Σταύρος
	Ντέντος
  Cc: meta

Σταύρος Ντέντος <stdedos@gmail.com> wrote:
> On Sat, 27 Mar 2021 at 11:54, Eric Wong <e@80x24.org> wrote:
> > Not really, since the address is meta@public-inbox.org.
> > "public-inbox" is already a long name, and
> > "public-inbox.org/public-inbox" is kinda annoyingly long.
> >
> > (and I've been preferring <80x24.org|yhbt.net>/public-inbox.git
> >  for the git repo).
> 
> Remember that a symlink (or a 30x redirect) does not cost you anything :-p
> It _is_ longer, and it doesn't cost you anything, for the sake of
> "finding where is something where you look for it to be" ;-)

It does, it clutters up the directory listing ("homepage").
Also redirect adds latency + traffic.

If somebody is already looking at public-inbox.org, then "meta/"
is already the top link in the listing.

> > Everything I've read about Docker sounds scary when people are
> > grabbing binaries and code from random distributors and just
> > running it blindly.  IMHO it encourages dangerous behavior.
> 
> Pulling solely from "sane-ish sources" (buster from Debian and your
> code from your repo),
> should it be okay. The risks (as stated above) should ...

Yes, if public-inbox.org provides a Docker image, it would not
be a "sane-ish source" :)

> > I would never introduce any soft or hard dependency into a
> > project without being knowledgeable and comfortable about it,
> > first; and that can take a LOT of time and lead me down rabbit
> > holes...
> 
> Yeah, me too :-D
> Having a more clean deploy&isolation&remove process would facilitate
> in me testing more
> and providing a cleaner patchset to you.

Fwiw, the test suite runs w/o install.

> You might have fixed my patchset yourself (thanks!) but not everyone
> is willing to spend time on it.
> On the other hand, I am not willing to "pollute" my system with
> something tying itself more or less to my system.
> (It's not the pollution that I am afraid of, but the sanitization afterwards).

Agree.  Note public-inbox.git has a new "symlink-install" target
that allows a minimimum install footprint:

   # https://public-inbox.org/meta/20201218120950.23272-24-e@80x24.org/
   make symlink-install prefix=/tmp/home
   export PATH=/tmp/home/bin:$PATH

Everything else is available from distro packages and easy to
uninstall.

> I've barely used chroots, and I am not comfortable using them (because
> they require sudo).

Understood, I also don't want to advocate use of chroot for
testing public-inbox.  I've used chroot since it's been
available far longer than containers or VMs, so I already
learned it ages ago.

I still use QEMU VMs to test old kernels and *BSD, and do so
with userspace networking (so no root needed).

> If you have some tl;dr knowledge on how to make (s)chroots to work
> cleanly without any sudo
> (after I review a specific subset of rights & get myself access to
> e.g. `/var/chroots/*` directory),
> I am all ears!

I don't, but I would probably look at containers directly or
something lighter than docker.  It seems systemd-nspawn can work
with debootstrap, maybe that is worth exploring, or some other
lxc thing.  Honestly, it still seems like overkill (I don't want
duplicate libc, perl, libz, git, etc. on the disk if I can help
it).

For testing other stuff, I configure with alternate prefix:
  ./Configure -Dprefix=... # for perl5.git
  ./configure --prefix=... # for autotooled stuff
  make prefix=... # for git.git

No root needed at all :>  But I rarely build software anymore
since it takes too long.

> A lot of compiled deb packages use that one way or another, and (mistakenly?)
> I feel more comfortable installing via `apt-get install package.deb`
> than `make install`.

Btw, it's in Debian sid, now: https://packages.debian.org/public-inbox

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-27 19:32             ` Eric Wong
@ 2021-03-28 16:00               ` Σταύρος Ντέντος
  2021-03-28 22:58                 ` Eric Wong
  0 siblings, 1 reply; 9+ messages in thread
From: Σταύρος Ντέντος @ 2021-03-28 16:00 UTC (permalink / raw)
  To: meta; +Cc: Eric Wong

On Sat, 27 Mar 2021 at 21:32, Eric Wong <e@80x24.org> wrote:
> It does, it clutters up the directory listing ("homepage").
> Also redirect adds latency + traffic.
>
> If somebody is already looking at public-inbox.org, then "meta/"
> is already the top link in the listing.

Hmm .... I "skipped" it as some error (why on earth "meta" is first on
a "name-ascending" sorting?!?!).

> > Yeah, me too :-D
> > Having a more clean deploy&isolation&remove process would facilitate
> > in me testing more
> > and providing a cleaner patchset to you.
>
> Fwiw, the test suite runs w/o install.

I wanted to test my change "in reality" (i.e. its browser rendering),
rather than run a testing suite.
Honestly, I blacked out after being unable to see my result, I didn't
think to run tests.
(especially considering the not-so-big changes done).

> Agree.  Note public-inbox.git has a new "symlink-install" target
> that allows a minimimum install footprint:
> [Also], it's in Debian sid, now: https://packages.debian.org/public-inbox

True, but I'd be missing "a backend of existing threads".
But now that I think of it, I could've just cloned any small enough
repo (e.g. meta? :-p)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1] git-send-email-reply: Append subject
  2021-03-28 16:00               ` Σταύρος Ντέντος
@ 2021-03-28 22:58                 ` Eric Wong
  0 siblings, 0 replies; 9+ messages in thread
From: Eric Wong @ 2021-03-28 22:58 UTC (permalink / raw)
  To: Σταύρος
	Ντέντος
  Cc: meta

Σταύρος Ντέντος <stdedos@gmail.com> wrote:
> On Sat, 27 Mar 2021 at 21:32, Eric Wong <e@80x24.org> wrote:
> > It does, it clutters up the directory listing ("homepage").
> > Also redirect adds latency + traffic.
> >
> > If somebody is already looking at public-inbox.org, then "meta/"
> > is already the top link in the listing.
> 
> Hmm .... I "skipped" it as some error (why on earth "meta" is first on
> a "name-ascending" sorting?!?!).

It matches nginx behavior, as well as Apache w/ FoldersFirst
option enabled.

> > Fwiw, the test suite runs w/o install.
> 
> I wanted to test my change "in reality" (i.e. its browser rendering),
> rather than run a testing suite.
> Honestly, I blacked out after being unable to see my result, I didn't
> think to run tests.
> (especially considering the not-so-big changes done).

Ah, "perl -I lib script/public-inbox-httpd -l $HOST:$PORT"
lets you run on ~/.public-inbox/config, or whatever PI_CONFIG=
you want.  When I work on WWW changes, I also use:

   plackup -I lib -o 127.0.0.1 -R lib -r examples/public-inbox.psgi

Which does auto-reloading and ensures stuff works on generic
PSGI servers.

> > Agree.  Note public-inbox.git has a new "symlink-install" target
> > that allows a minimimum install footprint:
> > [Also], it's in Debian sid, now: https://packages.debian.org/public-inbox
> 
> True, but I'd be missing "a backend of existing threads".
> But now that I think of it, I could've just cloned any small enough
> repo (e.g. meta? :-p)

Yes, meta is pretty small, still.  There's many smaller v2 ones
at lore: lore.kernel.org tools | workflows | dwarves ...

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-03-28 22:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-26 16:31 [PATCH v1] git-send-email-reply: Append subject Stavros Ntentos
2021-03-26 19:36 ` Eric Wong
     [not found]   ` <CAHMHMxVS4tVvUYvWUmk8L8oqPPxtYW-MF_57Vwuzug-asWQiQg@mail.gmail.com>
2021-03-26 21:35     ` Eric Wong
2021-03-27  8:39       ` Stavros Ntentos
2021-03-27  9:54         ` Eric Wong
2021-03-27 14:01           ` Σταύρος Ντέντος
2021-03-27 19:32             ` Eric Wong
2021-03-28 16:00               ` Σταύρος Ντέντος
2021-03-28 22:58                 ` Eric Wong

user/dev discussion of public-inbox itself

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/meta
	git clone --mirror http://czquwvybam4bgbro.onion/meta
	git clone --mirror http://hjrcffqmbrq6wope.onion/meta
	git clone --mirror http://ou63pmih66umazou.onion/meta

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 meta meta/ https://public-inbox.org/meta \
		meta@public-inbox.org
	public-inbox-index meta

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta
	nntp://ou63pmih66umazou.onion/inbox.comp.mail.public-inbox.meta
	nntp://czquwvybam4bgbro.onion/inbox.comp.mail.public-inbox.meta
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.mail.public-inbox.meta
	nntp://news.gmane.io/gmane.mail.public-inbox.general
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/public-inbox.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git