unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Eric Wong <e@80x24.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: meta@public-inbox.org
Subject: Re: RFC: monthly epochs for v2
Date: Fri, 25 Oct 2019 22:57:55 +0000	[thread overview]
Message-ID: <20191025225755.GA8414@dcvr> (raw)
In-Reply-To: <20191025205604.GA23680@chatter.i7.local>

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Fri, Oct 25, 2019 at 12:22:14PM +0000, Eric Wong wrote:
> > > I'm not sure about a libpublicinbox... I have been really
> > > hesitant to depend on shared C/C++ libraries whenever I use Perl
> > > or Ruby because of build and install complexity; especially for
> > > stuff that's not-yet-available on distros.
> > > 
> > > Well-defined and stable protocols + data formats?
> > > Yes. 100 times yes.
> > > 
> > > What would be nice is to have a local server so they could
> > > access everything via HTTP using curl or whatever HTTP library
> > > users want.  On shared systems, it could be HTTP over a UNIX
> > > socket.  I don't think libcurl supports Unix domain sockets,
> > > yet, but HTTP/1.1 parsers are pretty common.
> > > 
> > > JSON is a possibility, too; but I'm not sure if JSON is even
> > > necessary if all that's exchanged are git blob OIDs and URLs for
> > > mboxes.  Parsing MIME + RFC822(-ish) are already sunk costs.
> > 
> > More on that. As much as I may be in favor of "software freedom",
> > I'm even more in favor of "freedom _from_ software".  Reusing
> > existing data formats as much as possible to minimize the
> > bug and attack surface is something I've been trying to do.
> 
> I understand the sentiment, but it's the exact problem that kernel
> maintainers are struggling with. Almost every maintainer I've spoken to have
> complained that without dedicated tools automating a lot of tasks for them,
> they quickly run out of scaling capacity. In fact, most of the ones I spoke
> with have rigged up some kind of fragile solution that sort-of works for
> them, often involving spittle and baling wire (someone I know runs patchwork
> in a container). After they set it up, they are hesitant to touch it, which
> means they don't want to perform system or library upgrades for the fear
> that something may break at the worst possible time during the merge window.
> Which means they are potentially leaving their systems exposed by not
> applying security updates.
> 
> It's little wonder why many are clamoring for a centralized forge solution
> that would put the responsibility of maintaining things on someone else's
> shoulders.

Yeah.  I've tried to make public-inbox somewhat easy-to-install
compared to typical web apps, at least on Debian-based systems.
I guess the CentOS7 experience is acceptable, but maybe less than
ideal due to the lack of Search::Xapian.

Not sure what other distros and dependencies we'd have to worry
about with less package availability than CentOS/RHEL.

> If we want to avoid this, we need to provide them with convenient and robust
> tools that they can use and adapt to their needs. Otherwise we aren't really
> solving the problem.

Right.  Much of the public-inbox search and blob-solver logic
can be adapted to command-line tools (as they are for testing)
and/or exposed locally via a git-instaweb-style HTTP server
which can be curl-ed.  But ALSO hosting it on a giant server is
an option for organizations that want such things.

Maybe some tooling can be piggy-backed into git.git or its
contrib/, section, too.  I certainly want to make git operation
totally network transparent, at least.

> (I know this really belongs on workflows more than on meta.)

I posted a little bit more about local tools, here:
  https://lore.kernel.org/workflows/20191025223915.GA22959@dcvr/
(but I've posted to similar effect here, I think)

  reply	other threads:[~2019-10-25 22:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 19:53 RFC: monthly epochs for v2 Konstantin Ryabitsev
2019-10-24 20:35 ` Eric Wong
2019-10-24 21:21   ` Konstantin Ryabitsev
2019-10-24 22:34     ` Eric Wong
2019-10-25 12:22       ` Eric Wong
2019-10-25 20:56         ` Konstantin Ryabitsev
2019-10-25 22:57           ` Eric Wong [this message]
2019-10-29 15:03             ` Eric W. Biederman
2019-10-29 15:55               ` Konstantin Ryabitsev
2019-10-29 22:46                 ` 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=20191025225755.GA8414@dcvr \
    --to=e@80x24.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=meta@public-inbox.org \
    /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.
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).