user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Stavros Ntentos <stdedos@gmail.com>
Cc: meta@public-inbox.org
Subject: Re: [PATCH v1] git-send-email-reply: Append subject
Date: Sat, 27 Mar 2021 09:54:31 +0000	[thread overview]
Message-ID: <20210327095431.GA32057@dcvr> (raw)
In-Reply-To: <20210327083946.30726-1-133706+stdedos@users.noreply.github.com>

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.

  reply	other threads:[~2021-03-27  9:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 16:31 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 [this message]
2021-03-27 14:01           ` Σταύρος Ντέντος
2021-03-27 19:32             ` Eric Wong
2021-03-28 16:00               ` Σταύρος Ντέντος
2021-03-28 22:58                 ` Eric Wong

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://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210327095431.GA32057@dcvr \
    --to=e@80x24.org \
    --cc=meta@public-inbox.org \
    --cc=stdedos@gmail.com \
    --subject='Re: [PATCH v1] git-send-email-reply: Append subject' \
    /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

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

	https://80x24.org/public-inbox.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).