I think a setup step might be missing from the developer's docs
https://docs.mailman3.org/en/latest/devsetup.html
If I go through the venv setup and when I call mailman info, the following
error shows up (missing dependency).
...
File "/home/_/Workspace/personal/mailman/src/mailman/__init__.py", line
38, in <module>
from mailman.core.i18n import initialize
File "/home/_/Workspace/personal/mailman/src/mailman/core/i18n.py", line
22, in <module>
from flufl.i18n import PackageStrategy, registry
ModuleNotFoundError: No module named 'flufl.i18n'
However, when I run just run tox, the .tox/qa/bin/mailman info command
works without any issues.
"Used to be" seems to be the operative sentence, unfortunately.
I have browsed various sources around the "Systers organization" keyword
and what public repositories there might be, but no luck finding anything
that includes the dynamic sublists implementation.
I have found the document that describes the implementation, on (the old
wiki?) wiki.list.orghttps://archive.vn/NLyl2
Based on that document I assumed the following rpm to contain the changes,
but no luck. https://ftp.osuosl.org/pub/osl/systers-mailman/ (unpacked with
"rpm2cpio ../mailman-systers-2.1.12-2012.12.27.el6.src.rpm| cpio -idmv")
I think the document in itself can be a starting point for the
implementation.
If you have a contact email to someone that's part of the Systers group, it
might be worth reaching out in order to upstream this feature.
But I also have no issue with just diving into the codebase and building
the functionality along the lines of the aforementioned document.
On Sun, Feb 14, 2021 at 6:00 AM Stephen J. Turnbull <
turnbull(a)sk.tsukuba.ac.jp> wrote:
> Marius Ghita writes:
>
> > To that end, I would propose a new feature for Mailman to allow the
> > user to be more selective with the emails it receives.
>
> This sounds a lot like the "dynamic sublist" feature that has been
> implemented in the Systers' fork of Mailman. (They use Mailman as a
> front-end for a lot of Systers-specific process, so upstreaming the
> dynamic sublist part is not trivial.)
>
> Their repository used to be at git@github.com:systers/mailman3.git if
> you want to take a look. (Note: I haven't been involved there for
> several years. Their Mailman apparently was mature enough for them,
> and their GSoC goals moved toward mobile app development, so they
> didn't push to get GSoC students and we drifted apart).
>
>
Happy new year everyone!
I'm starting to prep Python for GSoC 2021, and I wanted to issue the
usual invitation that we'd be happy to have Mailman as a sub-org if
anyone wants to do GSoC this year. (Mailman's been fine as a separate
org, but I have to do the paperwork for Python anyhow so I figured I'd
offer if there's interest but no one wants to cover the admin side of
things.)
Also, I have two mailman related ideas!
1. Seamless archive converter for 2.1 -> 3.*
A friend was grousing that there was no "nice" way to retain old archive
urls without keeping a static copy of things, and it got me to thinking
that it would definitely be possible to build something that handled the
old urls and redirected or made them work seamlessly, but we didn't do
it because parsing the old archives basically requires you to scrape
them because otherwise we couldn't guarantee that the urls would be
stable from a re-parsed mbox.
It's boring and finicky web scraping work to associate the old url and
do the right things to make it work seamlessly in hyperkitty, but
probably not too hard, so I was thinking that it might be suitable for a
GSoC student.
2. Old mailman "skin" for postorius
Make mailman look like the 2.1 interface for people who really love the
old system. There's a few options that would be different, but the
goal would be to make it pretty much look the same only with a few
options changed, for people who are very change adverse. We had
intended for it to be *possible* to reskin Postorius, but I don't think
too many people have done it, so this would be a test to see how doable
that is and probably fix any underlying issues that make reskinning the
interface hard. Honestly, we could also have a student do a brand new
skin if we had someone who loved UI design, but I suspect replicating
the old interface would be less work, and since this year's GSoC hours
have been cut in half, i'd rather start with something easier.
I've been out of mailman dev for 3 years, so I'm probably not the ideal
mentor, but I'm up for helping on either of those if Mailman as a whole
is interested in doing the GSoC thing this year.
Terri
Hi everyone and Abhilash in particular :)
I've faced a case when Hypirkitty is unable to chain messages into a thread:
https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/
(See messages with the subject "WLUG Meeting Feb 11th 2021! Topic: Good
question!".)
It's a quite disappointment as GMail does show them correctly - as a
single thread.
As per my small investigation, a subscriber Robert N. Evans seems to have
"In-Reply-To" headers stripped from the messages that probably causes the
thread to break.
I wonder if Hyperkitty is able to leverage some other method to combine the
thread correctly in this case?
"Good" and "bad" message examples are in the attachment.
Best regards,
Danil Smirnov
Greetings.
I'm generally a Mailman user through all the open-source projects that
require a user to join a mailing list before contributing to a project. As
a user that occasionally contributes patches/PRs to random repositories, my
mailing list subscriptions are short-lived because I always get more emails
than I need.
To that end, I would propose a new feature for Mailman to allow the user to
be more selective with the emails it receives.
The following scenarios are those that would work best for me.
1. If I send an email to a mailing list, any follow-up emails to that
thread are sent to my inbox as well.
2. If a user sends an email through the mailing list that CCs/BCCs me I get
all the follow-up emails in that thread as well.
3. Maybe -- and this one is more of an idea than something that I would
actually use -- a generated email in the mail archive web view for each
thread, to which I could send an email and be subscribed to any follow-up
emails to that thread.
For me, this feature would make emails more manageable, and have them
behave like subscriptions to individual issues on issue trackers.
My Python is rusty, at best, but I would be happy to help implement this
feature in Mailman.
Hi, everybody
I would like to have Mailman participate in GSoC as a regular
organization this year (as I mentioned earlier I'd like to go to the
GSoC Mentor Summit if they have one -- I'm not *presuming* I'd be one
of the ones to go, but 2 out of 3 or 4 seems like a better bet than
one of the org admins at PSF doesn't go and then 1 out of 100+ PSF
mentors ;-).
The deadline for organization applications is Feb 19, and I'll
probably get started on it tomorrow or Sunday.
I think Abhilash already said he is in, so that's enough for me to get
started on the application. Any objections from Mailman core?
Anybody in or out of core interested in mentoring? If you're
interested but not sure what it involves, feel free to ask me.
Obviously some Python programming ability and familiarity with the
Mailman 3 codebase are important, but you don't have to be a Python
or Mailman core hacker to have a role, eg as a backup mentor, or
helping set up a development environment.
Steve
Hi,
my footer removal software fails on IETF's "last-call" mailing list because it
looks for a line of underscores, whereas that list uses "-- ". That sequence
is "the separator line between the body and the signature of a message",
according to RFC 3676. However, I had never seen it in mailing list footers
before.
My experience with mailing lists is limited, so I ask you. Is that sequence
common enough to try and catch it in a footer removal function?
I asked the list owners, and they answered "We didn't choose these settings
when the list was set up! It was probably just the default for that version of
Mailman." Is that possible?
TIA
Ale
--
