I want to customize my home page of mailman 3 . When I type my site name it
should go to another page and from there when I click distribution lists
link It should redirect to mailman 3 default homepage.
I am trying to achieve this and failing in this regard.
Expert team please give me any suggestions and clues regarding the
dependencies that may involved in changing this.
Iam using httpd to work with ssl on mailman 3 using proxy pass.
After this configuration Iam not able to connect to hyperkitty. It is throwing ssl certificate error in mailman.log file.
What should be the configuration of hyperkitty while using https in mailman..?
Please help me with this Iam struck here from past 4 days
Sent from my iPhone
We are encountering a weird issue, after enabling archives for a list, mails are not archived and not seen in hyperkitty. No error observed.
How will the communication between postorius and hyperkitty takes place..??
Sent from my iPhone
We observed the following error after starting the mailman-suite. If some
one has experienced the same please provide any inputs.
Exception happened during processing of request from ('127.0.0.1', 50210)
Traceback (most recent call last):
File "/usr/lib64/python3.6/socketserver.py", line 651, in
File "/usr/lib64/python3.6/socketserver.py", line 361, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib64/python3.6/socketserver.py", line 721, in __init__
line 171, in handle
line 179, in handle_one_request
self.raw_requestline = self.rfile.readline(65537)
File "/usr/lib64/python3.6/socket.py", line 586, in readinto
ConnectionResetError: [Errno 104] Connection reset by peer
I am developing the processing of bounce messages as my GSoC project.
Currently the `Bounce Functions` are being developed in [this](https://gitlab.com/mailman/mailman/merge_requests/538) pr on GitLab.
There is one `bool` attribute called `bounce_you_are_disabled_warnings_interval` in the `Mailing List` model.
>The number of days between each disabled notification.
Implementing this has a problem
- Say in the case of `process_bounces` function which processes the `BounceEvents` function it is easy it just takes one by one the events from the database and processes them.
- In the case of `Send_Warnings` function if the same approach was followed, meaning it would take one by one the `Address` instances, check tuples in the `bounce_info` attribute ( see the pr for this ) and see whether to send a warning mail or not to can be a slow method.
- Let's suppose the `Addresses` list is very long, then an `Address` instance in the very bottom of the list whose subscription has been disabled and some warning emails send, now waits to receive another mail as the interval is more than `bounce_you_are_disabled_warnings_interval`.
- If the function is enumerating from the top then in order to take action first it has to reach this `Address` instance but the interval is already crossed. This can cause slow performance as the `warning mail` will be sent way late than it actually should have been sent.
- Also if I am implementing 2 functions `process_bounces` and `send_warnings` what if both of them attempted at the same `Address` instance?
- Basically `implementation on sending warning mails` and `implementation to increase bounce_score` are separate things and they can cause problems if they processed the same instance.
Pointers on above will be helpful.
Am I missing something above?
I’m Ariessa Norramli and I’m a GSOD participant with the project
“Instructions to Migration from Mailman 2 to Mailman 3”.
My accepted proposal can be viewed at:
During the doc development period, I'll deliver a weekly blog post to
summarise what I did throughout the respective week.The blog posts can be
viewed at: https://medium.com/@ariessa_norramli
I'll use the mailing list as my main source of communication with mentors.
I have successfully completed implementation of mailman with some customizations (like sending sms to moderators for pending lists, Authenticating into mailman 3 using existing LDAP,and some minor changes)
Now that we are ready to go into production. We are currently running mailman 2 in our production. Now the biggest challenge is we have to migrate around 3000 lists from mailman 2 to mailman 3. Is there any documentation or any inputs from the team would be appreciated and will be very helpful. Iam trying to access docs.mailman3.org but it is not opening don't why.?
This group helped me a lot in bringing my mailman 3 upto this stage. The process of migration would complete my project. Requesting your valuable inputs
Sent from my iPhone
+ Mailman Developers, since this seems like a general discussion topic.
On Thu, Aug 8, 2019, at 2:01 AM, Mike Gabriel wrote:
> Hi Abhilash,
> I just looked into the two recent merges from Daniel on mailman's
> master branch.
> I noticed that you squashed the MR branch commits into one commit
> before the merge and that this one commit uses the latest commit
> messages of the MR branch to describe what the squashed commits do.
> Unfortunately, that commit messages does not appropriately describe
> what the commit in fact does.
> The resulting commit on master for the merge of MR !543 is this:
> commit baf7fbca96cf77ae028740b668d79a906eb600ef
> Author: Daniel Teichmann <daniel(a)teichm-sh.de>
> Date: Thu Aug 8 01:25:05 2019 +0000
> commands/tests/test_cli_members.py: Add testcase for del_infp
> files containing commented and blank lines
This looks surprising to me, I was hoping that it would use the title
of the MR as the commit message and description as the description of
Looking a bit more closely at the documentation, it looks like it will
> The squashed commit’s commit message will be either:
> - Taken from the first multi-line commit message in the merge.
> - The merge request’s title if no multi-line commit message is found.
I am going to keep an eye out for the commit message in future before
merging, thanks for pointing this out.
> It contains the complete "mailman members --delete" code (all commits
> from MR !543), but its commit message is the message of the top commit
> that was on the MR branch. Commit content and commit message deviate.
> As this merging strategy seems to be a sub-optimal strategy, I'd love
> to discuss it for mailman3, if that's ok.
> IMHO, it would be much better (for the sake of transparency and code
> change documentation) to either avoid commit squashing on merges
> (iirc, it can be disabled in GitLab on a pre project level) or
> explicitly demand from contributors to stuff all their code changes
> into one commit and ship an appropriate commit msg.
This could have happened a few times in the past because I didn't know
Gitlab would pick a commit message with the multi-line comment. However,
this is not a general pattern that I am trying to enforce here.
It would be great to have single commit MRs, however, after the review,
I'd prefer to have additional commits added to the MR as compared to
sqashing + force push. Additional commits makes 2nd and 3rd reviews
much more easy, since I can just look at the comments I made and the
changes made in the newer commits.
Finally, we want the MR to be merged as a single commit, so we use the
Gitlab's sqash-merge feature. It works okay most of the times, like
I mentioned above.
> For big MRs the second option is really sub-optimal (esp. from a
> (Debian) downstream maintainer's point of view): if I needed to
> cherry-pick tiny changes on the code into a stable mailman3 release in
> Debian, for example, then I'd love to have atomic changes to
> cherry-pick from in the upstream Git. However, if all merges' commits
> get squashed before being applied on master, then the changesets on
> master become quite bulky and un-cherry-pickable.
Ideally, MRs are a complete unit and it doesn't make sense IMO to
cherry-pick only parts of the MR. MRs should be atomic. If there are
two independent things being done in a single MR, it should ideally be
split into separate MRs and hence get merged as separate commits.
> For future merge requests, would you prefer us to stuff all changes of
> one MR into one commit? Or is it ok, to have several commits in one
> MR? This would IMHO require from you to not squash the commits on
> those MRs.
I hope I answered this above, but in summary, please squash commits when
your Open the MR, but please don't force-push when you make requested
changed from the review.
Also, we maintainers should be aware and just keep an eye out for the
commit message. It is totally possible in Gitlab to change the Squash'd
commit's message and in case Gitlab doesn't pick up the MR's title and
desc, I'll try to pick it up manually.
Does that sound reasonable?
> Please let me know what your position is on this. Thanks!
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
> mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de
Abhilash Raj (maxking)
To the applicants to Google Season of Docs with GNU Mailman:
Cc: Mailman Developers
[This is an abbreviated version of the message sent directly to the
Thank you all for your interest in GNU Mailman, and for applying to
Season of Docs with the Mailman organization.
First, I would like to congratulate Ariessa Norramli, whose project
"Instructions for Migrating from Mailman 2 to Mailman 3" we selected
for implementation this autumn. The list of all projects selected is
available on the Season of Docs website at
Public discussion of the project will take place on the Mailman
Developers mailing list <mailman-developers(a)python.org>. We will also
negotiate a blogging requirement during the community bonding period.
Of course Mailman is a public project on GitLab, and you can follow
progress of the documentation project there. URLs for the blog and
the repo will be posted to the mailing list.
I hope all of the applicants will find some way to participate in the
Mailman project as suits time and interest.
About the Selection Process:
Eight technical writers in some way expressed interest in Season of
Docs with GNU Mailman, of whom five entered proposals via the Season
of Docs website. Two of those proposals were stubs containing little
or no content, which were eliminated quickly.
The remaining three proposals were all very high quality, and in fact
we could have selected any of them. Each had small advantages and
disadvantages compared to the other two. The tie-breaking criterion
was the content of the proposal: after consulting with Abhilash, I
decided that the migration instructions project was our biggest
documentation need based on the questions we get on the Mailman 3
users mailing list.
Associate Professor Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
Hi Steve, Abhilash,
Thanks for your time in going over my proposal in GSoD. Now that GSoD
results are out it would be great to get some feedback regarding my
proposal. What could be improved and what will be that you might look
out for in the next GSoD if that happens again. Also I want to
contribute further as a mailman contributor. So if you could point out
which would be some good issues/projects (either in
documentation/development) to take up, that would be great!