Re: RFC: monthly epochs for v2

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

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