Hello Mailman 3 users and developers!
It's been a long slog but I think we are finally ready to begin the release process for Mailman 3.1. I am pretty happy about the state of the Core, and Florian is going to do some more integration testing with HyperKitty and Postorius. We still have a few issues and a merge proposal or two to address, but I am planning to spin a beta of Core this weekend to facilitate testing.
Here is the Core's 3.1 milestone page:
https://gitlab.com/mailman/mailman/milestones/2
If your favorite issue or merge request isn't on that list, please do get in touch. Otherwise it will be deferred to 3.2. I'm also not entirely promising I'll get to all of these; I really want to release 3.1 in 2016 so if we run out of time, it will get deferred.
Here's the project-wide list of 3.1 issues:
https://gitlab.com/groups/mailman/issues?scope=all&state=opened&utf8=%E2%9C%93&milestone_title=3.1
and merge requests:
Except that HyperKitty isn't on this list.
Please do test whatever you can and let us know how it goes.
Cheers, -Barry
On Fri, Dec 02, 2016 at 11:07:24AM -0500, Barry Warsaw wrote:
Hello Mailman 3 users and developers!
It's been a long slog but I think we are finally ready to begin the release process for Mailman 3.1. I am pretty happy about the state of the Core, and Florian is going to do some more integration testing with HyperKitty and Postorius. We still have a few issues and a merge proposal or two to address,
I did some manual integration testing today (core+mailmanclient+postorius) which looked fine so far. I didn't get to test HyperKitty and the bundler though, so any help testing those would be very much appreciated. I will have some more time tomorrow.
I did all of my testing locally, which has some limitations. So I started setting up a more realistic environment on one of my dev machines. But I'm not done yet. Will report back when I'm done... ;-)
but I am planning to spin a beta of Core this weekend to facilitate testing.
I think it's OK to put out a separate beta of the core, because the version pulled from pypi will still be 3.0 if I'm not terribly mistaken.
For the real 3.1 we should probably do a coordinated release of all components, once everything's tested a little more thoroughly.
Cheers Florian
Thanks for doing the testing Florian. Btw I fixed the venv problem. It was actually a bug in one of the dependencies. I have another small branch to land before spinning the beta but I think the MySQL docker image on ci is having some problems. I can't double check ATM.
Sent from my digital lollipop.
On Dec 3, 2016, at 15:22, Florian Fuchs <f@florianfuchs.com> wrote:
On Fri, Dec 02, 2016 at 11:07:24AM -0500, Barry Warsaw wrote: Hello Mailman 3 users and developers!
It's been a long slog but I think we are finally ready to begin the release process for Mailman 3.1. I am pretty happy about the state of the Core, and Florian is going to do some more integration testing with HyperKitty and Postorius. We still have a few issues and a merge proposal or two to address,
I did some manual integration testing today (core+mailmanclient+postorius) which looked fine so far. I didn't get to test HyperKitty and the bundler though, so any help testing those would be very much appreciated. I will have some more time tomorrow.
I did all of my testing locally, which has some limitations. So I started setting up a more realistic environment on one of my dev machines. But I'm not done yet. Will report back when I'm done... ;-)
but I am planning to spin a beta of Core this weekend to facilitate testing.
I think it's OK to put out a separate beta of the core, because the version pulled from pypi will still be 3.0 if I'm not terribly mistaken.
For the real 3.1 we should probably do a coordinated release of all components, once everything's tested a little more thoroughly.
Cheers Florian
On 2016-12-03 12:22 PM, Florian Fuchs wrote:
I did some manual integration testing today (core+mailmanclient+postorius) which looked fine so far. I didn't get to test HyperKitty and the bundler though, so any help testing those would be very much appreciated. I will have some more time tomorrow.
I tried to do some testing based on these wiki instructions last weekend https://wiki.list.org/HyperKitty/DevelopmentSetupGuide
and hit a "[Errno 61] Connection refused" issue when attempting to log in to Postorius. I suspect it might be an issue with the mac, since googling for the error (it's a django one) seems to find a lot of people on macs with problems, but I didn't manage to narrow it down more than that to make a useful bug report.
I did set up a new linux install on another machine to work on next, though, so I may have something else to say on that front tomorrow.
Terri
On Sat, Dec 03, 2016 at 17:25:24PM -0800, Terri Oda wrote:
On 2016-12-03 12:22 PM, Florian Fuchs wrote:
I did some manual integration testing today (core+mailmanclient+postorius) which looked fine so far. I didn't get to test HyperKitty and the bundler though, so any help testing those would be very much appreciated. I will have some more time tomorrow.
I tried to do some testing based on these wiki instructions last weekend https://wiki.list.org/HyperKitty/DevelopmentSetupGuide
and hit a "[Errno 61] Connection refused" issue when attempting to log in to Postorius. I suspect it might be an issue with the mac, since googling for the error (it's a django one) seems to find a lot of people on macs with problems, but I didn't manage to narrow it down more than that to make a useful bug report.
Do you have a traceback somewhere? If you're logging in for the first time, it *might* have to do with allauth trying to verify your email address by sending you an confirmation email (which probably fails if you don't have smtp set up on your mac).
If that's the case, we should probably try to catch this condition and display a useful error message instead of just letting it break.
Cheers Florian
I did set up a new linux install on another machine to work on next, though, so I may have something else to say on that front tomorrow.
Terri
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/f%40florianfuchs....
Security Policy: http://wiki.list.org/x/QIA9
On 2016-12-08 9:45 AM, Florian Fuchs wrote: you have a traceback somewhere? If you're logging in for the first
time, it *might* have to do with allauth trying to verify your email address by sending you an confirmation email (which probably fails if you don't have smtp set up on your mac).
If that's the case, we should probably try to catch this condition and display a useful error message instead of just letting it break.
The email *would* make sense, and would explain why I saw the error more often associated with macs. If that's the case it sounds like an error that should be caught and explained. I'll file a bug and dump the traceback there.
Terri
just verifying my ability post... Since there is a human delay in approvals, why wait until there is a need?
Vince
On Dec 03, 2016, at 09:22 PM, Florian Fuchs wrote:
I think it's OK to put out a separate beta of the core, because the version pulled from pypi will still be 3.0 if I'm not terribly mistaken.
BTW, I did upload a beta of Core to PyPI before I started my travel.
For the real 3.1 we should probably do a coordinated release of all components, once everything's tested a little more thoroughly.
For sure.
Cheers, -Barry
On 12/02/2016 08:07 AM, Barry Warsaw wrote:
Hello Mailman 3 users and developers!
It's been a long slog but I think we are finally ready to begin the release process for Mailman 3.1. I am pretty happy about the state of the Core, and Florian is going to do some more integration testing with HyperKitty and Postorius. We still have a few issues and a merge proposal or two to address, but I am planning to spin a beta of Core this weekend to facilitate testing.
Barry,
I understand you need to feel comfortable about everything going into the core and this takes time and energy to review all the MRs, but I think it is pretty important to get the DMARC mitigations into the core. If there's anything I can do to help with this, let me know.
I will rebase my branch again and possibly make one minor tweak, but I think it should be OK.
I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Dec 09, 2016, at 09:37 AM, Mark Sapiro wrote:
I understand you need to feel comfortable about everything going into the core and this takes time and energy to review all the MRs, but I think it is pretty important to get the DMARC mitigations into the core. If there's anything I can do to help with this, let me know.
I will rebase my branch again and possibly make one minor tweak, but I think it should be OK.
Thanks for pushing back on this Mark. Obviously, I have a high degree of trust in your work, but yeah, my compulsive behavior is showing through. ;)
Please do rebase and if you can, remilestone the MR to 3.1. We'll get it in.
I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab.
My gut reaction is to add a separate DMARC Mitigations tab, but Florian and Terri have final say I think.
Cheers, -Barry
On 12/10/2016 12:52 AM, Barry Warsaw wrote:
Please do rebase and if you can, remilestone the MR to 3.1. We'll get it in.
Done. There is one "temporary" commit in my MR to work around <https://github.com/sphinx-doc/sphinx/issues/3212> and get "docs" to pass.
I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab.
My gut reaction is to add a separate DMARC Mitigations tab, but Florian and Terri have final say I think.
I have a WIP MR at <https://gitlab.com/mailman/postorius/merge_requests/194> that adds a tab. Maybe Florian and Terri can look at that and chime in.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Barry Warsaw writes:
I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab.
My gut reaction is to add a separate DMARC Mitigations tab, but Florian and Terri have final say I think.
I would find it more natural to have "Posting Policy" (which would include posting filters on size and list membership, as well as message alterations such as removing .exe files and enforcing plain text by removing or rendering HTML parts), and "Malware Mitigation", which would include IP, domain, and mailbox filters as well as DMARC. I think DMARC mitigation is probably too special to deserve its own tab.
Probably this is way too much reorganization to do at this point, but I'd like to keep this point in mind. We are already getting reports that configuration options are hard to find just because it's different from Mailman 2. I suspect that the REST API is sufficiently flexible and regular that we'll be tempted to proliferate options, so let's try to keep them organized.
Steve
On 2016-12-12 12:29 AM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
I can also work on Postorius. Also in this vein I have a question. Should the DMARC settings be added to the Alter Messages tab in the List Settings view or would it be better to have a separate DMARC Mitigations tab.
My gut reaction is to add a separate DMARC Mitigations tab, but Florian and Terri have final say I think.
I would find it more natural to have "Posting Policy" (which would include posting filters on size and list membership, as well as message alterations such as removing .exe files and enforcing plain text by removing or rendering HTML parts), and "Malware Mitigation", which would include IP, domain, and mailbox filters as well as DMARC. I think DMARC mitigation is probably too special to deserve its own tab.
Alter messages tab works for me, but DMARC is kind of a big enough deal (as far as mail delivery goes) and sufficiently different that I agree with Mark that it's not unreasonable to give it a separate tab. I'd be willing to start it on its own and move it if we're getting too cluttered later, as long as we document it in the release notes when we do. Florian, what do you think?
Probably this is way too much reorganization to do at this point, but I'd like to keep this point in mind. We are already getting reports that configuration options are hard to find just because it's different from Mailman 2. I suspect that the REST API is sufficiently flexible and regular that we'll be tempted to proliferate options, so let's try to keep them organized.
We also get reports that mailman 2.1 options are hard to find -- I think I personally help someone find something at least once a month (on irc, in person, or by email) for the past decade. :) I imagine Mark has answered a lot more of those than I have.
The big thing I want is good documentation here. There's never going to be an organization that works for everyone, but an easily searchable document with all the options would make a big difference. I only got to that level with the user docs not the list admin docs in 2.1
participants (6)
-
Barry Warsaw
-
Florian Fuchs
-
Mark Sapiro
-
Stephen J. Turnbull
-
Terri Oda
-
vince@vheuser.com