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
>
> 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.
>> > > > >
>> > > > >
>> > > >
>> >
>>
