+Detlef,Jeremy for lists.isocpp.org migration+upgrade planning
BTW, I think Boost and WG21 reflectors (lists.isocpp.org) are encountering identical problems. Let me sanity-check as this will help us both get this right… My understanding is that there are two distinct issues: 1. Moving from Indiana: Boost and WG21 reflectors have been hosted at Indiana, and our host has left so we need to move them. For Boost, I understand you is looking at moving to Ciere; that’s up to you of course. For WG21, we are moving lists.isocpp.org to the same webhost as the rest of isocpp.org; our plan is to do that migration over the U.S. Thanksgiving holiday, and Jeremy (who runs isocpp.org) is in communication with DongInn (Indiana IT), to complete this. 2. Upgrading to Mailman (2.1.18 or later): IIUC Boost and WG21 reflectors are using an older version of Mailman and this problem would be resolved with a newer version. See https://wiki.list.org/DEV/DMARC where IIUC the correct option we would use is “munge” as encouraged in DMARC Support in Mailman <http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html> – does that match your understanding? For WG21, the plan is that after we finish the #1 move and are stable, we’ll look at upgrading Mailman to 2.1.18 or later, hopefully before the end of the year, and turn on the “munge” option. Does that match your understanding and planning? Herb From: boost-steering@googlegroups.com [mailto:boost-steering@googlegroups.com] On Behalf Of Niall Douglas Sent: Thursday, November 3, 2016 2:30 AM To: Boost Steering Committee <boost-steering@googlegroups.com> Cc: m...@jsharpe.net Subject: Re: [boost-steering] Fwd: DMARC and mailman The failure to fix this is beginning to interfere with library peer reviews, never mind the operation of boost-dev in general. Much of the email received from boost-dev lands in Spam nowadays from DKIM enforced email addresses. We also are failing to rewrite SPF correctly. I attach below the full headers from a mail received by Antony Polukhin who is review managing Boost.Process right now. His job is impeded if reviews by Boost members keep landing in Spam. Can I ask boost-steering to please get on this already and get this fixed? Niall Delivered-To: antosh...@gmail.com <mailto:antosh...@gmail.com> Received: by 10.25.205.12 with SMTP id d12csp142015lfg; Wed, 2 Nov 2016 01:58:30 -0700 (PDT) X-Received: by 10.36.92.14 with SMTP id q14mr1846291itb.97.1478077110428; Wed, 02 Nov 2016 01:58:30 -0700 (PDT) Return-Path: <boost-boun...@lists.boost.org <mailto:boost-boun...@lists.boost.org> > Received: from wowbagger.crest.iu.edu (wowbagger.crest.iu.edu. [129.79.39.203]) by mx.google.com with ESMTP id 7si2162397itu.59.2016.11.02.01.58.30; Wed, 02 Nov 2016 01:58:30 -0700 (PDT) Received-SPF: neutral (google.com: 129.79.39.203 is neither permitted nor denied by best guess record for domain of boost-boun...@lists.boost.org <mailto:boost-boun...@lists.boost.org> ) client-ip=129.79.39.203; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@nedprod.com <mailto:header.i=@nedprod.com> ; spf=neutral (google.com: 129.79.39.203 is neither permitted nor denied by best guess record for domain of boost-boun...@lists.boost.org <mailto:boost-boun...@lists.boost.org> ) smtp.mailfrom=boost-boun...@lists.boost.org <mailto:smtp.mailfrom=boost-boun...@lists.boost.org> ; dmarc=fail (p=QUARANTINE dis=NONE) header.from=nedprod.com Received: by wowbagger.crest.iu.edu (Postfix, from userid 495) id 6E47F160B07; Wed, 2 Nov 2016 04:58:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on wowbagger.crest.iu.edu X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, T_DKIM_INVALID autolearn=no version=3.3.1 Received: from wowbagger.crest.iu.edu (localhost [127.0.0.1]) by wowbagger.crest.iu.edu (Postfix) with ESMTP id DCE5A160C73; Wed, 2 Nov 2016 04:58:04 -0400 (EDT) X-Original-To: bo...@lists.boost.org <mailto:bo...@lists.boost.org> Delivered-To: bo...@lists.boost.org <mailto:bo...@lists.boost.org> Received: by wowbagger.crest.iu.edu (Postfix, from userid 495) id 71DDF160C58; Wed, 2 Nov 2016 04:58:03 -0400 (EDT) Received: from mail.nedprod.com (europe4.nedproductions.biz [213.251.186.177]) by wowbagger.crest.iu.edu (Postfix) with ESMTP id A0F7415F627 for <bo...@lists.boost.org <mailto:bo...@lists.boost.org> >; Wed, 2 Nov 2016 04:57:53 -0400 (EDT) Received: from authenticated-user (mail.nedprod.com [213.251.186.177]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.nedprod.com (Postfix) with ESMTPSA id AD69F26786 for <bo...@lists.boost.org <mailto:bo...@lists.boost.org> >; Wed, 2 Nov 2016 08:57:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1478077072; bh=m0JYAuglZABUVinF4F4iPaS9jnh47//GLAwQco86kbs=; h=From:To:Date:Subject:In-reply-to:References:From; b=ojjB1UFkzPIFh5zEzSof15fJlGK3aHOemkqLycI829/rTboX6VCwVAWBtZw8GiHsP QXwDEGqYvdqKCVAKJee5cMSEL11v9Q0nFyqpMFjkwHRihbqave0XnyMsIHJDBIxJKF 9TvcwmCR4Eb0BJFDcYlvyjBZBfmFmNtDuYoxkjaJG/b8eGHEi+fcaUbHgiiKQkPnzu idptbTt4oJPrFdRgU4euW+PR77K0WABumaSpm6VdYcqe+4eSW+JxCIH90QOe0cbyOo F2zNJsdUAVxHTXw0C/MXR1uzqRb3k5af+MdTJDsSY2eeIHd5tS1reSQwOqk4CTecfd bS/NdpMaLq7XA== From: Niall Douglas <s_sourcefo...@nedprod.com <mailto:s_sourcefo...@nedprod.com> > To: bo...@lists.boost.org <mailto:bo...@lists.boost.org> Date: Wed, 02 Nov 2016 08:57:51 -0000 MIME-Version: 1.0 Message-ID: <5819AA8F.16763.4B662C04@s_sourceforge.nedprod.com <mailto:5819AA8F.16763.4B662C04@s_sourceforge.nedprod.com> > Priority: normal In-reply-to: <b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net <mailto:b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net> > References: <CAKqmYPaxM6UUWf4CO6CmnXYaCqk=zDcTdAtaVDmmEWxt=ls...@mail.gmail.com <mailto:CAKqmYPaxM6UUWf4CO6CmnXYaCqk=zDcTdAtaVDmmEWxt=ls...@mail.gmail.com> >, <nvb636$4t2$1...@blaine.gmane.org <mailto:nvb636$4t2$1...@blaine.gmane.org> >, <b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net <mailto:b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net> > Content-description: Mail message body Subject: Re: [boost] [process] Formal Review starts today, 27 October X-BeenThere: bo...@lists.boost.org <mailto:bo...@lists.boost.org> X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bo...@lists.boost.org <mailto:bo...@lists.boost.org> List-Id: Boost developers' mailing list <boost.lists.boost.org> List-Unsubscribe: <http://lists.boost.org/mailman/options.cgi/boost>, <mailto:boost-requ...@lists.boost.org?subject=unsubscribe> List-Archive: <http://lists.boost.org/boost/> List-Post: <mailto:bo...@lists.boost.org> List-Help: <mailto:boost-requ...@lists.boost.org?subject=help> List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, <mailto:boost-requ...@lists.boost.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: boost-boun...@lists.boost.org <mailto:boost-boun...@lists.boost.org> Sender: Boost <boost-boun...@lists.boost.org <mailto:boost-boun...@lists.boost.org> > On 1 Nov 2016 at 23:57, Klemens Morgenstern wrote: > Am 01.11.2016 um 23:48 schrieb Gavin Lambert: > > On 1/11/2016 21:41, Niall Douglas wrote: > >> You also don't need to use completion ports like ASIO does for async > >> i/o on Windows which are slightly complex to use. There is a much > >> simpler solution called alertable i/o which AFIO v2 uses which has NT > >> dispatch for you all pending async i/o callbacks every time you sleep > >> a thread. Examine AFIO v2's source code for ideas if you like, you > >> can throw together an async pipe i/o multiplexed reactor with very > >> little effort in no time because NT has already implemented an "ASIO" > >> for you, no ASIO needed. > > > > Having written my own mostly-lock-free ASIO-lite based around > > completion ports, I can confirm that they're not at all complex to > > use. Meanwhile I shy away from alertable I/O because it's > > thread-affine and requires remembering to always perform alertable > > waits, both of which seem fragile to me. Still, the advantage of both > > methods existing is that you can use whatever you feel most > > comfortable with. :) > > > I guess the right approach for boost.process would be, to add support > for boost.afio when it comes out, as it does now for boost.asio. > Elsewise you'd just have multiple libraries doing the same thing. AFIO should land in the peer review queue in 2019. Outcome, upon which AFIO v2 is very heavily based (and probably would be the most contentious part of AFIO v2's API design), should land in the peer review queue early 2017 (I'm currently writing its tutorial at https://ned14.github.io/boost.outcome/). AFIO v2 was designed to understand child process handles and pipes, and its hierarchy of class inheritances allows easy extension to implement child process i/o support. Pull requests for that are welcome. BTW it is the lack of user supplied i/o backends in Process which was a big part of why I voted to reject it. The correct API design would allow the user to supply *any* implementation of child process i/o, and Process would not need to care what it is nor how it works. You would of course supply a default i/o backend probably based on popen() on POSIX or something equally simple, but the point is that you having to hard code support for ASIO or AFIO shows how Process has the wrong API design. My other big showstopper issue was you imposing on users your serialisation API i.e. all that iostreams and FILE * machinery. It's widely known that the committee would like a v2 iostreams to happen as soon as possible as the current iostreams is so very 1992. Quite a few people are experimenting with some very alternative designs right now, again if Process didn't need to be hardcoded to use some serialisation framework that would be a huge gain and in my mind the correct API design. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- You received this message because you are subscribed to the Google Groups "Boost Steering Committee" group. To unsubscribe from this group and stop receiving emails from it, send an email to boost-steering+unsubscr...@googlegroups.com <mailto:boost-steering+unsubscr...@googlegroups.com> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Boost Steering Committee" group. To unsubscribe from this group and stop receiving emails from it, send an email to boost-steering+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
