Email list hosting service & mailing list manager

Remaining things to remove mostly per the 80/20 rule hga@xxxxxx (11 Aug 2019 14:35 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (11 Aug 2019 15:10 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (11 Aug 2019 15:15 UTC)
gecos parser implementation Lassi Kortela (11 Aug 2019 17:30 UTC)
Re: gecos parser implementation John Cowan (12 Aug 2019 04:07 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:02 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 11:52 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:21 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 13:44 UTC)
Timezone files Lassi Kortela (12 Aug 2019 14:00 UTC)
GECOS field parsing Lassi Kortela (17 Aug 2019 08:52 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:11 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:16 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:35 UTC)
Re: GECOS field parsing Lassi Kortela (17 Aug 2019 09:56 UTC)
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela (12 Aug 2019 12:39 UTC)

Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 12:02 UTC

> I don't think there's a positive payoff in the suggested proliferation
> of SRFIs.  They're isolated, but they still require jumping down to
> the world of C, and might as well be bundled with this base POSIX SRFI.
>
>> Things that deal with user/group _numbers_ pertaining to the current
>> process
>
> They're very useful at this base POSIX SRFI level for e.g. logging, so
> I think they should stay here, and have the processes SRFI(s) require
> at least some specific subset of procedures in this SRFI.

These are good arguments. I originally thought having more small SRFIs
is good than a few big ones, but you may convince me to change my opinion.