On Fri, Oct 11, 2024 at 2:08 PM Christian Grobmeier <grobme...@apache.org> wrote:
> > > On Fri, Oct 11, 2024, at 19:35, Gary Gregory wrote: > > I'm not crazy about having to bounce around sections of various repos in > > addition to monitoring emails, which has to be done anyway. It's > _another_ > > thing to lose track of :-( Having a repo just to use the discussion > feature > > feels like a hack. > > > > I wish I could find the thread about new reddit-like FOSS UIs on one of > > the @apache.org lists... I feel like we should piggy back this > discussion > > on that. > > Wasn’t that on members? > I think the idea was to patch up ponymail to be more like Reddit and have > some kind of email subscriptions to topics. > Also nice, but I guess a lot of work > There was a separate email listing at least 2 FOSS web UIs we could use. Gary > > > > > > Gary > > > > On Fri, Oct 11, 2024 at 3:02 AM Volkan Yazıcı <vol...@yazi.ci.invalid> > > wrote: > > > >> That is something we can decide together: > >> > >> 1. Have project-specific discussion repositories (i.e., Log4j users > will > >> use `logging-log4j2`, LogNet users will use `logging-log4net`, and so > >> on) > >> 2. Have a shared discussion repository (e.g., we can create > >> `logging-discuss` repository and create `General`, `Log4j`, > `Log4Net`, > >> etc. > >> sections there) > >> 3. Have project-specific discussion repositories (`logging-log4j2`, > >> `logging-log4net`, etc.) and also a shared one (i.e., > `logging-discuss` > >> with only `General` section) > >> > >> My point is, we can configure GitHub Discussions to suit our needs. But, > >> are we willing to take that step? > >> > >> On Thu, Oct 10, 2024 at 11:36 PM Robert Middleton < > rmiddle...@apache.org> > >> wrote: > >> > >> > 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. > >> > > > > > >> > > > > > >> > > > > >> > > >> >
