On Fri, 2020-03-27 at 10:45 -0400, Christopher Faylor wrote: > On Fri, Mar 27, 2020 at 07:00:59AM +0100, Bernd Edlinger wrote: > > PS: I would CC you, Christopher Faylor, but your email address is > > "cgf-use-the-mailinglist-ple...@gnu.org", so whatever I send there > > would not reach you. > > Well duh? Not being cc'ed is the literal point of the email address. > > Anyway, no one ever said that mhonarc was unavailable on CentOS 8. We > are using the archiver that's built into mailman which required very > little effort to get up and running. It's in use on scores, if not > hundreds of sites around the web. > > What I asked was if there was a public-inbox rpm available. > > Anyway, since this is entirely a volunteer effort on my part and every > daytime hour I spend working on it costs me money, I'm going to go with > the answer "I don't have the time/don't want to" as the response to "Why > don't you do X????" > > If people want to get a collection going and offer to pay for some > improvements/changes to sourceware then I, personally, would consider > spending more time on it. Or maybe another overseer will jump in and > offer to convert the system to majordomo or something. I think one of the things folks need to keep in mind is that maintenance of sourceware/gcc is a volunteer effort. Chris, Frank, & co inherited a system that we set up in the late 90s and have taken loving care of it since, often with little or no recognition for their efforts.
The original system was pretty highly customized as the tools in the late 90s weren't nearly as standardized and the tools that were standardized had significant performance and feature deficiencies. Thus qmail+ezmlm. Sigh. It made sense at the time, but that time has past. Given changes in the landscape over the last 20+ years, I absolutely support the move to standardized tools, particularly those for which we could potentially get support. So that would mean something like RHEL, but not EPEL. Furthermore, I strongly support the desire to bring the configuration of those tools closer and closer to the default configurations. As an ex IT guy, I've gone both directions depending on the project I was supporting and certainly see the pros and cons of going highly customized vs as generic as possible. In my opinion Chris & Frank are doing the right thing here and I would not support reverting or revisiting the decisions they made as part of this upgrade. Yes it means a slight bit of pain as everyone gets used to the new system, but it's the right long term direction. jeff
