python...sigh. ________________________________ 发件人: Gary Gregory <garydgreg...@gmail.com> 发送时间: 星期二, 十月 15, 2024 3:59:10 上午 收件人: Apache Logging Developers List <dev@logging.apache.org> 主题: Re: Successor to mailing lists
I'll admit that I rely on PonyMail. It seems we (Apache) should have a professional (paid for is ok) set up for this, not a custom solution. Gary On Mon, Oct 14, 2024, 3:51 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Maybe we just need to start contributing to PonyMail to improve the UI to > eliminate actually needing the email delivered to our accounts. > > I am only 1/4 serious about this. There has to be a better solution. > > Ralph > > > On Oct 14, 2024, at 10:25 AM, Matt Sicker <m...@musigma.org> wrote: > > > > I didn’t get the original email in this thread once again, so I think > I’d support trying somewhere else to host discussions. Besides archiving > those messages into a mailing list, it would be great if the solution > provided allowed for email interactivity (e.g., you can reply to the > notification of a message and it’s added to the thread appropriately; this > is how GitHub notification emails typically work). > > > >> On Oct 10, 2024, at 05:40, Christian Grobmeier <grobme...@apache.org> > wrote: > >> > >> Hi > >> > >> I am generally open to such experiments. I would start with the easiest > parts, such as users@, and see where it goes. > >> > >> I would advise against mirroring it to users@ behind the scenes, as it > may cause privacy problems (we need user consensus to mirror it). When a > user uses GitHub, they know what to expect. > >> > >> As for Discourse, many use that now, but I find it very overwhelming > and stressful. I prefer the clean Github discussions approach. > >> > >> I haven't checked against ASF policies but feel positive about this > move for the arguments you have given > >> > >> Kind regards > >> Christian > >> > >> > >> > >> On Thu, Oct 10, 2024, at 10:58, Volkan Yazıcı wrote: > >>> *Abstract:* Modern email system security measures make it practically > >>> impossible for mailing lists to work – many subscribers don't get all > >>> emails. This not only hinders communication, but blocks an inclusive > >>> one. *Shall > >>> we, as Logging Services, experiment with alternatives?* > >>> > >>> *Motivation #1: mailing lists technically don't work* > >>> > >>> Several widely-used email providers (GMail, Yahoo, iCloud, etc.) have > in > >>> the last couple of years enabled new measures (DMARC, SPF, DKIM, etc.) > to > >>> verify the authenticity of emails. In short, these measures enrich > email > >>> content with checksums and signatures capturing its authenticity. When > a > >>> mailing list system (e.g., ezmlm, mailman) receives such an email, it > >>> performs several changes on its content (adds information about the > mailing > >>> list, etc.), and delivers it to all subscribers. When the mail server > of a > >>> subscriber receives such tampered mail, and if that mail server > happens to > >>> have earlier shared authenticity checks enabled, it discards the > email, or > >>> at best, marks it as spam. > >>> > >>> Ralph, Matt, Piotr stated many times that they don't receive all > emails. > >>> Ralph actually stated many ASF mailing list emails end up in his spam > >>> box > >>> < > https://the-asf.slack.com/archives/CBX4TSBQ8/p1728032221080189?thread_ts=1727958807.348019&cid=CBX4TSBQ8 > >. > >>> Recently we witnessed even Brian Proffitt (VP, Marketing & Publicity) > >>> suffer > >>> from the same problem > >>> <https://lists.apache.org/thread/yfmrpjslcbo5jmsqqpvtok1o6lht11rb>. > >>> INFRA > >>> is crawling with related tickets: INFRA-24574 > >>> <https://issues.apache.org/jira/browse/INFRA-24574>, INFRA-24790 > >>> <https://issues.apache.org/jira/browse/INFRA-24790>, INFRA-24845 > >>> <https://issues.apache.org/jira/browse/INFRA-24845>, INFRA-24850 > >>> <https://issues.apache.org/jira/browse/INFRA-24850>, INFRA-24872 > >>> <https://issues.apache.org/jira/browse/INFRA-24872>, INFRA-25947 > >>> <https://issues.apache.org/jira/browse/INFRA-25947>, INFRA-26171 > >>> <https://issues.apache.org/jira/browse/INFRA-26171> – there are > dozens > >>> more. > >>> > >>> This technical difficulty is not only known to us. AFAIK, this is one > of > >>> the main reasons PSF (Python Software Foundation) decided to switch > from > >>> mailing lists to Discourse. Mailman documents several DMARC mitigations > >>> < > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html > >, > >>> but I think these are workarounds/hacks rather than well-established > >>> solutions. > >>> > >>> *Motivation #2: ezmlm is dead* > >>> > >>> ezmlm, the mailing list software ASF uses, is dead – it is neither > >>> developed, nor maintained anymore. (Last official release was in 1997, > >>> there > >>> is the `ezmlm-idx` add-on, which later on became a successor > >>> < > https://untroubled.org/ezmlm/faq/What-is-the-difference-between-ezmlm-and-ezmlm_002didx_003f.html > >, > >>> which last produced a release in 2014, and so on. Long, dead story.) > >>> INFRA > >>> maintains a very big, sophisticated set of Perl rules for running ASF > >>> ezmlm > >>> instances. If you look closely at the INFRA tickets I cited above, some > >>> suggest INFRA to fork ezmlm and fix some long standing bugs, etc. We > can > >>> discuss the possibility of migrating from ezmlm to mailman (yet another > >>> mailing list software, but one that is still maintained), whether such > a > >>> migration should be practiced ASF-wide or only for Logging Services, > >>> etc. > >>> But eventually, we will still be using a mailing list, and as I tried > to > >>> explain above, IMO, they just don't work good. > >>> > >>> *Proposal #1: Experimenting with GitHub Discussions* > >>> > >>> GitHub is our development bread and butter. We use its tickets, PRs, > >>> reviews, discussions, CI, security & code quality checks, etc. It works > >>> perfectly and components are integrated well, i.e., you can link > issues, > >>> comments, PRs, CI runs, etc. Users like it too – we all witnessed the > >>> sudden increase in user interactions after migrating to GitHub Issues > >>> and > >>> Discussions. We can configure sections & categories in Discussions > >>> < > https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions > > > >>> to make it serve as our main communication medium. It also provides > mail > >>> notifications and the possibility to respond to them for those who > still > >>> prefer their email client over a browser. > >>> > >>> In short, we can quickly configure Discussions, update our support > policy > >>> page, and start experimenting with it. > >>> > >>> One can raise the argument that what if Discussions disappear? We can > >>> mirror communication there to a mailing list to be on the safe side. > Yet, > >>> we need to evaluate the necessity of this. > >>> > >>> *Proposal #2: Experimenting with Discourse* > >>> > >>> We can get a VM from INFRA and manage our Discourse instance. Though, > >>> AFAIC, this will result in a "GitHub Discussions"-like setup with all > the > >>> integration goodies missing and added server maintenance burden. > >>> > >>> *F.A.Q.* > >>> > >>> *What if GitHub Discussions disappear?* > >>> > >>> In such a case, I presume they will allow us to download the existing > >>> archives. In the worst case, we can decide to mirror the communication > >>> there to a mailing list. Yet, we need to evaluate the necessity of > this. In > >>> particular, how big of a problem is this at the experimentation stage? > >>> > >>> *How will private communication work with GitHub Discussions?* > >>> > >>> We can create private repositories for internal/private communication. > >>> For > >>> users/researchers wanting to submit & discuss security issues, they > can > >>> get > >>> in touch with us (either via email to `security@logging` or some other > >>> ASF/INFRA mailing list), we can grant them permissions to collaborate > >>> privately on a repository security advisory > >>> < > https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories > > > >>> . > >>> > >>> *Don't the ASF legals require mailing lists?* > >>> > >>> I am aware that several ASF policies require mailing list > communication, > >>> e.g., for voting and such. I first want to establish a consensus among > us, > >>> and then pitch to the board for exemption as a pilot. > >>> > >>> *Shouldn't this proposal be practiced ASF-wide?* > >>> > >>> This will be a very (very very very, actually!) daunting route to > pursue. > >>> I'd rather start small, solve our problem first (if we can), and then > think > >>> about widening the scope. > > > >
