Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: ovsqlite (Bo Lindbergh)
2. Re: ovsqlite (Russ Allbery)
3. Re: ovsqlite (Russ Allbery)
4. INN 2.7.0 and development repository (Russ Allbery)
5. Re: INN 2.7.0 and development repository (Perry E. Metzger)
6. Re: INN 2.7.0 and development repository (Bo Lindbergh)
7. Re: INN 2.7.0 and development repository (Russ Allbery)
8. RE: INN 2.7.0 and development repository (Avon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Dec 2020 17:44:14 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Quoth Julien ?LIE <[email protected]>:
>
> expireover start mardi 9 mai 2017, 04:15:27 (UTC+0200):
> Article lines processed 2936398
> Articles dropped 959
> Overview index dropped 2347
>
> and afterwards, articles and overview index dropped were identical.
>
> So far so good then!
Yes, that is reassuring. Investigating that first-time discrepancy would
be expensive; you'd have to make a copy of the entire spool just after
the overview rebuild. A filesystem with snapshot capability would help.
/Bo Lindbergh
------------------------------
Message: 2
Date: Thu, 24 Dec 2020 09:18:36 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
>> We'll now need ovspool for article storage :-)
> sqlitespool I meant!
I'm wondering if sqlite could handle the history file. Article storage is
mostly bulk blob storage, and I'm not sure of sqlite is the best tool for
that, but the history file is a weird, ancient bespoke database format
that's kind of a pain to work with if you ever have to figure out wtf is
going on under the hood.
Historically the history file cared a great deal about transaction speed,
but there's a memory cache in front of it now, so mostly write performance
would be the concern, and that's relatively trivial compared to the
overview writes.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Thu, 24 Dec 2020 09:48:50 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> @Russ, do you plan on renaming sqlite.m4 to sqlite3.m4 in rra-c-util too?
Yeah, that does seem to be the thing that everything SQLite-related does,
so I'll go ahead and rename it in rra-c-util, along with the corresponding
macros. The next release breaks some APIs for Autoconf macros anyway, so
now is a good time.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Thu, 24 Dec 2020 10:15:16 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain
I've been thinking about useful cleanup for INN 2.7.0 and wanted to open a
conversation about possibly moving to Git and GitHub.
The current setup with Subversion and Trac works, but it has a couple of
drawbacks:
1. It's a unique setup among all of my projects. I long ago moved almost
everything to Git, and the rest of my very legacy stuff is in CVS (and
will eventually move to Git once I clear various prerequisites). It's
not very hard to maintain the Subversion server and Trac server, but it
is one more thing to maintain, upgrade with new versions of Debian,
etc.
2. Probably more compellingly, the current INN setup is wholly dependent
on me. If I get hit by a bus or otherwise put of commission for a
while, everything gets irritatingly hard, since everything is on my
private infrastructure and no one else can maintain it. If instead we
had a GitHub organization, it can have multiple owners and those owners
can add more owners if necessary, and it's much easier to have
continuity.
Using GitHub would also let us support pull requests if people wanted to
use that development flow (although of course nothing prevents us from
continuing to handle patches sent to the mailing list). And we could use
GitHub Actions to automatically test new commits or pull requests, rather
than only testing nightly on snapshot generation and manually before
committing.
There are other software forges out there than GitHub and there are
reasons (generally free software / free service) reasons for wanting to
use other ones, but I don't really want to open that part of the
discussion. I know GitHub well, already use it for work, think it's easy
enough to get information back out of it again so the chances of lock-in
aren't too high, and find the alternatives like GitLab much inferior. So
I'd rather focus on current setup vs. GitHub. Everything we do would be
free on GitHub, and I suspect will stay free for at least the forseeable
future.
I can continue publishing snapshots the same way that I'm currently doing;
that part is easy to keep going and anyone else could take it over without
a ton of work.
It looks like there are a few scripts available to migrate Trac issues to
GitHub issues, so we should be able to preserve that part of the Trac
setup as well. We don't really use the wiki, I think (although there too
GitHub has GitHub Pages, which is just rendered Markdown and is easy to
use and to get all the data back out of should we want it).
I grabbed the InterNetNews organization name on GitHub just in case we
want to use it. (INN was already taken by an unrelated organization.)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 5
Date: Thu, 24 Dec 2020 13:57:26 -0500
From: "Perry E. Metzger" <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 12/24/20 13:15, Russ Allbery wrote:
> I've been thinking about useful cleanup for INN 2.7.0 and wanted to open a
> conversation about possibly moving to Git and GitHub.
>
I'm just a lurker and have nothing to do with real development here, so
my opinion shouldn't count for much. None the less, I think this is a
very good idea and highly support it. Development will be much easier,
and it will still be possible to leave Github someday should that ever
prove necessary.
Perry
------------------------------
Message: 6
Date: Thu, 24 Dec 2020 20:38:34 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I, for one, welcome our new GitHub overlords.
But seriously, it would simplify life. I only barely managed to build
Subversion on my new machine; the included Perl modules just failed
with completely uninformative error messages.
/Bo Lindbergh
------------------------------
Message: 7
Date: Thu, 24 Dec 2020 11:55:05 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain
Bo Lindbergh <[email protected]> writes:
> But seriously, it would simplify life. I only barely managed to build
> Subversion on my new machine; the included Perl modules just failed with
> completely uninformative error messages.
Yeah, that's one of my concerns. We're a bit off the beaten path in terms
of tooling, and while Subversion and Trac both seem to be actively
supported still, they're not the most common tools and I worry about it
becoming harder for people to get them working.
For better or worse, the entire open source community has standardized on
Git at this point (pace a few Mercurial holdouts).
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 8
Date: Fri, 25 Dec 2020 09:54:39 +1300
From: "Avon" <[email protected]>
To: "'Russ Allbery'" <[email protected]>, <[email protected]>
Subject: RE: INN 2.7.0 and development repository
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Russ, I'm in support of a move to Git and GitHub also.
Best, Paul
news.bbs.nz
> -----Original Message-----
> From: inn-workers <[email protected]> On Behalf Of Russ
> Allbery
> Sent: Friday, 25 December 2020 7:15 AM
> To: [email protected]
> Subject: INN 2.7.0 and development repository
>
> I've been thinking about useful cleanup for INN 2.7.0 and wanted to open a
> conversation about possibly moving to Git and GitHub.
>
> The current setup with Subversion and Trac works, but it has a couple of
> drawbacks:
>
> 1. It's a unique setup among all of my projects. I long ago moved almost
> everything to Git, and the rest of my very legacy stuff is in CVS (and
> will eventually move to Git once I clear various prerequisites). It's
> not very hard to maintain the Subversion server and Trac server, but it
> is one more thing to maintain, upgrade with new versions of Debian,
> etc.
>
> 2. Probably more compellingly, the current INN setup is wholly dependent
> on me. If I get hit by a bus or otherwise put of commission for a
> while, everything gets irritatingly hard, since everything is on my
> private infrastructure and no one else can maintain it. If instead we
> had a GitHub organization, it can have multiple owners and those owners
> can add more owners if necessary, and it's much easier to have
> continuity.
>
> Using GitHub would also let us support pull requests if people wanted to
use
> that development flow (although of course nothing prevents us from
> continuing to handle patches sent to the mailing list). And we could use
> GitHub Actions to automatically test new commits or pull requests, rather
> than only testing nightly on snapshot generation and manually before
> committing.
>
> There are other software forges out there than GitHub and there are
> reasons (generally free software / free service) reasons for wanting to
use
> other ones, but I don't really want to open that part of the discussion.
I know
> GitHub well, already use it for work, think it's easy enough to get
information
> back out of it again so the chances of lock-in aren't too high, and find
the
> alternatives like GitLab much inferior. So I'd rather focus on current
setup vs.
> GitHub. Everything we do would be free on GitHub, and I suspect will stay
> free for at least the forseeable future.
>
> I can continue publishing snapshots the same way that I'm currently doing;
> that part is easy to keep going and anyone else could take it over without
a
> ton of work.
>
> It looks like there are a few scripts available to migrate Trac issues to
GitHub
> issues, so we should be able to preserve that part of the Trac setup as
well.
> We don't really use the wiki, I think (although there too GitHub has
GitHub
> Pages, which is just rendered Markdown and is easy to use and to get all
the
> data back out of should we want it).
>
> I grabbed the InterNetNews organization name on GitHub just in case we
> want to use it. (INN was already taken by an unrelated organization.)
>
> --
> Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
>
> Please send questions to the list rather than mailing me directly.
> <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
> _______________________________________________
> inn-workers mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 126, Issue 20
********************************************
