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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 19FEE1F4C1 for ; Fri, 25 Oct 2019 20:56:08 +0000 (UTC) Received: by mail-qk1-x736.google.com with SMTP id g21so3015407qkm.11 for ; Fri, 25 Oct 2019 13:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pN2ZgFAFZCbkpWXpmY45m1DChSrGJWSt1jxkS4CcSN0=; b=g637U7gct86nrhSyCC0S/kPwRtKVgsX1gYRyx6ecJLJaFhUj2Etp3fhjp1CpW0RMjN qeaDvR/hn85Kr3HkaDgRweY5UgxK00autPWhaMK0jqqV2NWxdH7C0ZVYqy/pMrlPLkiK 9VJbqlFsYZHBt1cCU+M8LIh517YKQqszfw7Rs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=pN2ZgFAFZCbkpWXpmY45m1DChSrGJWSt1jxkS4CcSN0=; b=QpV6lCKVcCEph3aAgl51MCIEiZgEDqaDNtP9PwBcUnXqdG+6xm/F7AqqbJ+uyNqnMJ GD1VWaNzLspkYUeRfayHtVScF1siwyezoDpqyTNQOjUp81g2rkJS17zEkvoHGEdvbga4 +yM3iAkbIpcetXREmyZO28UBr9O5RhmbqzYDvNxxLWmsLtM8iz3KuN885MRTNxnk0jIa s/O4/D6bJm9hWekaUafISDPCtat2n3DX9rDQzopOKWx0i95ZNhyZ9xGXbUFV5khDprn2 ad8BO1AghQZTonjgNw9HC7FW4Lamc8UuLKzdDMareAk1iLSECD0KmFMFFb1NMGo5vZPz AgdQ== X-Gm-Message-State: APjAAAWjDx1CbXCquvR1vm2lUG78WUFVs9MHJrF9XM6cTxxyFTtOgnLr PLYt1KPgm1bJ6EOnDLQXHfwXdQ== X-Google-Smtp-Source: APXvYqyKpFUq8UI5/J2CrcTu7K8Ago/iPlUXkzY1b4d/Pfg3yQBhewXhlhNX7AwXd5ffKR+Bw5Zttw== X-Received: by 2002:a37:a154:: with SMTP id k81mr4854755qke.196.1572036966709; Fri, 25 Oct 2019 13:56:06 -0700 (PDT) Received: from chatter.i7.local (192-0-228-88.cpe.teksavvy.com. [192.0.228.88]) by smtp.gmail.com with ESMTPSA id 44sm2217060qtt.13.2019.10.25.13.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Oct 2019 13:56:05 -0700 (PDT) Date: Fri, 25 Oct 2019 16:56:04 -0400 From: Konstantin Ryabitsev To: Eric Wong Cc: meta@public-inbox.org Subject: Re: RFC: monthly epochs for v2 Message-ID: <20191025205604.GA23680@chatter.i7.local> Mail-Followup-To: Eric Wong , meta@public-inbox.org References: <20191024195304.5b7zlx7e3vxfxmtg@chatter.i7.local> <20191024203503.GA31522@dcvr> <20191024212108.zfbwh7bmfbo3cgu5@chatter.i7.local> <20191024223451.GA17949@dcvr> <20191025122214.GA6947@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <20191025122214.GA6947@dcvr> User-Agent: Mutt/1.12.1 (2019-06-15) List-Id: 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. 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. (I know this really belongs on workflows more than on meta.) -K