From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 570E021EB9 for ; Fri, 10 May 2024 23:03:21 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Fri May 10 17:00:14 -0400 2024 Message-ID: <88C5968363742087DD9363949EF889CB@gaff.inri.net> Date: Fri, 10 May 2024 17:00:14 -0400 From: sl@stanleylieber.com To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: self-healing element browser shader blockchain Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk > For whatever reason, I'm getting delayed mails from the mailing > list. I haven't investigated further. we use upas mlmgr(1). what happens is, it processes outgoing messages in batches, and chokes when one fails for whatever reason. when this happens, all the rest of the messages in the batch are also postponed. over the years we have improved performance some by tweaking scripts and making sure the mailing list runs on a fast disk, but to my knowledge nobody has yet worked on the actual mlmgr(1) stuff directly. sl