The one problem I see with Github is that as far as I am aware discussions are on a per-repository basis, so unless we have a bare repository with everybody subscribed to it there's no way that I'm aware of to share information. For example while most of this mailing list is log4j specific, we also have log4cxx and log4net discussions happening on here and we can to some extent share resources or knowledge between the projects.
-Robert Middleton On Thu, Oct 10, 2024 at 9:44 AM Volkan Yazıcı <vol...@yazi.ci.invalid> wrote: > > GitHub can be configured to send email notifications. We can route these > to, say, `notificati...@logging.apache.org` email address to have our local > records. > > On Thu, Oct 10, 2024 at 2:01 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > > I thought this was recently discussed on @members, but now I can't find the > > thread! I'm not even sure if it was on @members, which exemplifies the > > scaling problem discussed on the list, among other issues: When you look at > > PonyMail's UI, there are about 60 internal mailing lists under the ' > > apache.org' project! How am I supposed to find anything? Searching my > > Gmail > > inbox didn't help, but I did not look for more than 30 seconds. Having to > > search yet another place... > > > > This thread I can't find pointed to examples of Reddit like UIs from FOSS > > providers. > > > > I agree that GH rocks. > > > > One topic that remains and is a must, is that wherever the data lives, it > > must end up recorded on Apache-owned resources, which GH is not. > > > > Gary > > > > On Thu, Oct 10, 2024 at 7:07 AM Apache <ralph.go...@dslextreme.com> wrote: > > > > > I cannot express an opinion without knowing what the replacement is and > > > having experience with it. Mailing lists have one great feature - they > > are > > > easy to search. For that reason anything we choose should be just as easy > > > or better. We must also stick to a single medium for formal communication > > > for the same reason. > > > > > > We do have the ability to experiment with whatever we want but votes need > > > to continue here until we have ASF approval. > > > > > > Ralph > > > > > > > On Oct 10, 2024, at 3:41 AM, 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. > > > > > > > >
