From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 744591F4C0; Fri, 25 Oct 2019 22:57:55 +0000 (UTC) Date: Fri, 25 Oct 2019 22:57:55 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: RFC: monthly epochs for v2 Message-ID: <20191025225755.GA8414@dcvr> References: <20191024195304.5b7zlx7e3vxfxmtg@chatter.i7.local> <20191024203503.GA31522@dcvr> <20191024212108.zfbwh7bmfbo3cgu5@chatter.i7.local> <20191024223451.GA17949@dcvr> <20191025122214.GA6947@dcvr> <20191025205604.GA23680@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191025205604.GA23680@chatter.i7.local> List-Id: Konstantin Ryabitsev 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)