[Mailman-Developers] Re: Better documentation for Mailman Core's config options

Wow, this is amazing Abhilash! So much better than the old wall of text, and so cool that you learned how to write a Sphinx plugin while you were at it. Cheers, -Barry > On Aug 7, 2020, at 12:31, Abhilash Raj wrote: > > Hey All, > > For the past few days, I've been trying to improve the

[Mailman-Developers] Re: New Admin Interface for Mailman 3

On Mar 2, 2020, at 00:14, Stephen J. Turnbull wrote: > > brian_carpen...@emwd.com writes: > >> 3. To reveal everything that Mailman core has via the new admin >> interface > > I myself am not sure why, but Barry has stated that it's hard to do > this, at least in the face of current pace of

[Mailman-Developers] Re: Improving the speed of mailman import21

On Oct 7, 2019, at 21:51, Abhilash Raj wrote: > > It is tricky how multiple-password world get translated to single-password > world, it makes the final password somewhat non-deterministic, depending on > what the last mailing list imported was, which does not sound right anyway. Maybe the

[Mailman-Developers] Re: New gitlab subproject for UX?

On Oct 18, 2018, at 21:57, Máirín Duffy wrote: > > I'm Mo, I haven't worked on Hyperkitty in a long while but have done a lot of > UX work on it in the past. > > Due to various circumstances I am interested in coming back to the project > and contributing again. I was hoping to maybe be able

Re: [Mailman-Developers] Announcing Mailman Suite 3.2 release

On Jul 10, 2018, at 23:50, Abhilash Raj wrote: > > I am very pleased to announce the release of Mailman Suite 3.2. Congratulations! This was a release long in the making, and I’m so happy that Abhilash was able to take it over the finish line. Thanks to all the community members who also

Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt

On Jan 31, 2018, at 09:28, Jan Jancar wrote: > Plugin configuration is done through the Mailman configuration and those > are read-only through the REST interface. However a plugin might supply > it's own REST endpoints for example for per-list setup/configuration. Yep;

Re: [Mailman-Developers] opportunistically encrypted mailman lists with Autocrypt

Hi Holger. Very cool initiative. I just skimmed the specs for now, but I do like how it takes an opportunistic approach to key management, in order to simplify the UX and increase adoption. > On Jan 21, 2018, at 00:47, holger krekel wrote: > > maybe some of you know me

Re: [Mailman-Developers] Handling additions to REST API in client side

On Dec 28, 2017, at 19:50, Abhilash Raj wrote: > PATCH won't fail when running partial updates, but it won't silently drop the > attributes that it doesn't support. So from client side, there is no real way > to > understand when to include that attribute which was

Re: [Mailman-Developers] Handling additions to REST API in client side

Abhilash Raj wrote: > Core's REST API is versioned and any change that break backwards-compatibility > cause the version to bump so that clients can take care of that. The 3.1 version bump happened because there was no backward compatible way to handle the UUID as int vs hex string change

Re: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman

On Nov 12, 2017, at 11:06, Simon Hanna wrote: > Scenario: Core changes something about rest that is backwards incompatible. > The change is commited to master. The REST API is versioned, so it would be a bug to introduce a backward incompatibility in the same API version.

Re: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman

On Nov 8, 2017, at 04:38, Simon Hanna wrote: > > On 11/08/2017 12:03 AM, Abhilash Raj wrote: >> New images are available on quay.io and, moving forward, the rest of >> the image builds will also be moved to Quay[4][5]. > Since docker deployment is currently the recommended

Re: [Mailman-Developers] Signing commits with gpg

On Oct 25, 2017, at 12:14, Simon Hanna wrote: > > I guess more important would be to sign the releases. At least archlinux > likes to have signatures for source archives and often requests upstream > projects to add this. Definitely. I (try to remember to) sign both tags

Re: [Mailman-Developers] Signing commits with gpg

On Oct 24, 2017, at 18:56, Mark Sapiro wrote: > > I remember looking into signing commits when we first switched from bzr > to git because I was used to signing all commits. At that time, it > seemed controversial. See, e.g., >

Re: [Mailman-Developers] Signing commits with gpg

On Oct 24, 2017, at 16:52, Abhilash Raj wrote: > > Gitlab now supports verification of commit signatures and it would be > awesome if we start signing commits. It is a relatively painless process > and happens automatically with little configuration. Very cool that GL

Re: [Mailman-Developers] Renaming a list

On Oct 23, 2017, at 11:48, Aurelien Bompard wrote: > > I wanted to rename a list (only the list_name, not the list_id) and I > figured I would make the transition smoother by adding an "AcceptableAlias" > with the old name. I did that and realized that the acceptable

Re: [Mailman-Developers] Migrating Postorius and Hyperkitty to Python 3

On Oct 9, 2017, at 03:55, Stephen J. Turnbull wrote: > > Do we need to worry about current distros? Probably not, as you point out. > We're still seeing plenty of questions about new installations of > Mailman 2 on mailman-users. Mailman 3 is still a

Re: [Mailman-Developers] GDPR

noskcaJ leahciM wrote: > GDPR is nearing the last 7 months of its 2 year transitional > implementation before becoming part of the law in EU countries (inc., > despite Brexit, the UK), affecting 0.5bn citizens together with US > enterprises in under Privacy Shield (replacing

Re: [Mailman-Developers] Mailman 3 not restarting after reboot [addendum]

On Sep 5, 2017, at 14:51, Mark Sapiro <m...@msapiro.net> wrote: > > On 09/05/2017 02:25 PM, Barry Warsaw wrote: >> >> Can you suggest a good place to document this? > > > We really don't say anything about running Mailman as a service. I guess >

Re: [Mailman-Developers] Mailman 3 not restarting after reboot [addendum]

On Sep 5, 2017, at 12:54, Mark Sapiro wrote: > > (Thank you!)*10. All it needed was the addition of > > export LANG=en_US.UTF-8 > > to the init.d script. It now works. Thanks for figuring this out, and sorry that I’ve been traveling and sprinting and couldn’t help more.

Re: [Mailman-Developers] Mailman 3 not restarting after reboot [addendum]

It would be interesting to know if the problem is in the init script or Mailman. You may have to crank up logging of both to find out. Also, I wonder if the same problem occurs if you use systemd? Other than that I don’t have any ideas. -Barry > On Sep 2, 2017, at 13:31, Mark Sapiro

[Mailman-Developers] Plugins

As part of his GSoC project, Jan Jancar implemented a plugin architecture for Mailman Core. I really liked a lot of it, and it serves as the basis for a set of my own tweaks on top of his branch. I think it’s very close to being ready to merge so I wanted to give folks here a heads up,

[Mailman-Developers] Mailgun email libraries

Hi folks - apologies for the cross-posting; there is some intersection on the topic so I don’t want to leave anyone out. This past weekend, I was at PyBay 2017 and attended an excellent talk by Christine Spang, founder and CTO of Nylas, an email syncing platform. They’ve been using Mailgun’s

Re: [Mailman-Developers] Click CLI branch

On Jul 20, 2017, at 03:56 PM, Barry Warsaw wrote: >This will close #319 and #346 and make adding new `mailman` subcommands much >easier. This is now merged! -Barry pgpSeSITuYKLP.pgp Description: OpenPGP digital signature ___ Mailman-Deve

Re: [Mailman-Developers] Click CLI branch

On Jul 21, 2017, at 11:46, Mark Sapiro wrote: > > Another thing I noticed is the help for the withlist --run option says > in part: > > If additional arguments are given at the end of the command line, they > are passed as subsequent positional arguments to the callable. For

Re: [Mailman-Developers] Click CLI branch

On Jul 20, 2017, at 02:26 PM, Mark Sapiro wrote: >The first thing I notice right away is the help text doesn't fill. E.g., Now that you remind me, I noticed this too and I was going to file an upstream issue on this, but I forgot. I did some pdb tracing through the click source and figured out

Re: [Mailman-Developers] Click CLI branch

On Jul 20, 2017, at 02:12 PM, Mark Sapiro wrote: >I'll look at it. I'll also rebase !301 and !202 after it lands, and I'll >now delete my branch >as this supercedes that. Thanks Mark! -Barry pgpighh58zCwB.pgp Description: OpenPGP digital

[Mailman-Developers] Click CLI branch

Just a quick note to mention that my big branch to adopt click for command line option parsing should now be done. https://gitlab.com/mailman/mailman/merge_requests/292 This will close #319 and #346 and make adding new `mailman` subcommands much easier. (We still need the bits to define

Re: [Mailman-Developers] Telling Apache about Mailman Rest API

Hi Erin, On Jul 12, 2017, at 11:57 AM, Erin Test wrote: >To access the REST API I've tried both command line curl calls: >curl -I -u restadmin http://localhost:8001/3.1/system/versions >Enter host password for user 'restadmin': >curl: (7) Failed to connect to localhost port 8001: Connection

Re: [Mailman-Developers] Telling Apache about Mailman Rest API

On Jul 11, 2017, at 05:50 PM, Erin Test wrote: >All of that being said I'm missing something in getting my basic setup >finalized. I have a web server (Apache) running and have installed mailman >core. When I try to access the REST API I get some variation of connection >refused depending on

Re: [Mailman-Developers] Next Postorius release

On Jun 30, 2017, at 07:24 PM, Abhilash Raj wrote: >Have you looked at Mariatta's new cherry-picker tool for CPython >workflow? It seems to make the cherry-picking and backporting a bit easier. > >[1]: https://github.com/python/core-workflow/tree/master/cherry_picker I haven't yet used it for

Re: [Mailman-Developers] [GSoC] Encrypted mailing lists - first evaluation

On Jun 28, 2017, at 01:49 PM, Jan Jancar wrote: >Overall I am quite confident in where the project is now. Seeing it run >tests with Mailman Core running and pass (just some basic tests atm) >feels good. Thanks for the update, and really great work Jan! I'm slowly making my way through the

[Mailman-Developers] GitLab 9.3 feature

Gitlab 9.3 was just announced. I wonder if this would help with some of our problems coordinating between our various services, especially with the VCR tape generation.

Re: [Mailman-Developers] Breaking mailmanclient into seperate modules

On Jun 07, 2017, at 10:18 PM, Abhilash Raj wrote: >Since we launched 3.1, I have been trying to add more docs in whatever free >time that I get. Thanks Abhilash! >One thing that I wanted to announce before I start is breaking up >mailmanclient from one giant module

Re: [Mailman-Developers] [GSoC] Encrypted mailing lists - update v4

Hi Jan, I haven't had a chance to look at the MRs yet, as it's my first week at a new job. But I have to say that your descriptions below look really great; I'm impressed at how well your design fits in with Mailman overall, and how clearly you've described them. I'm not sure I could have come

[Mailman-Developers] ANNOUNCE: Mailman 3.1.0 final!

Hello Mailpeople! On behalf of the entire team and all our wonderful contributors, I'm happy to announce the release of GNU Mailman 3.1 final. My deep thanks go to all the Mailman project sprinters at Pycon 2017 for getting us over the line! Two years after the original release of Mailman 3.0,

Re: [Mailman-Developers] Postorius and MRs for 3.1

On May 24, 2017, at 11:33 AM, Aurelien Bompard wrote: >Don't worry I'll do the releasing of HyperKitty when Mailman is up. Thanks! >However, I have just found two rather simple bugs: >- https://gitlab.com/mailman/mailman/issues/336 >- https://gitlab.com/mailman/mailman/issues/337 > >I have set

Re: [Mailman-Developers] Postorius and MRs for 3.1

On May 23, 2017, at 06:09 PM, Terri Oda wrote: >Your turn for the "last chance to tag things for 3.1" email now that >Aurelien's weighed in. ;) (I'm cc'ing the rest of mailman-developers in case >anyone else wants to advocate for a bug too...) I uploaded Core 3.1rc1 to PyPI this afternoon, so

Re: [Mailman-Developers] HyperKitty issues and MRs for 3.1

Hi Aurelien! On May 23, 2017, at 11:29 AM, Aurelien Bompard wrote: >I hope you're having a great time at PyCon :-) We are! >Fixed already, thanks to the sprinter for closing the bug. > >I'll work on the documentation issues, but it shouldn't block you from >releasing 3.1. Great! And thanks

[Mailman-Developers] HyperKitty issues and MRs for 3.1

Hi Aurelien, We're missing you and Florian at the Pycon sprints, but we have a good group of folks, and we're psyched to release Mailman 3.1 this week. We're noticing that there are no bugs or MRs assigned to milestone 3.1 for HyperKitty so our question is whether that's accurate and we can do a

Re: [Mailman-Developers] Multiple REST servers

On May 18, 2017, at 07:01 PM, Aurelien Bompard wrote: >We now have enough lists and activity that Mailman's REST API is >becoming a bottleneck, since it only answers one request at a time. >Is there a way to start mutiple REST runners? Or to make the REST >runner multithreaded? Thanks for

Re: [Mailman-Developers] Mailing lists exploited

On May 16, 2017, at 09:29 AM, Jonathan Knight wrote: >There's not a lot that can be done to protect against that other than >changing the "list is run by" so that the administrators real email address >isn't obvious. I suppose we should either use the moderator's real name, or just the local

Re: [Mailman-Developers] Mailing lists exploited

On May 15, 2017, at 11:03 AM, Mark Sapiro wrote: >It's not done in Mailman 3. > >For mailman 2.1, the administrator email addresses are a mailto: link the >goes to the LISTNAME-owner address, but the email addresses are exposed and >only mildly obfuscated ('@' -> ' at '). > >I would consider

Re: [Mailman-Developers] Signaling One-Click Functionality for List Email Headers

On May 10, 2017, at 05:05 PM, John Levine wrote: >>I'm not sure if anyone has followed development of RFC 8058 "Signaling >>One-Click Functionality for List Email Headers" located at >> and brought this topic up on this >>list. >> >>Is that something

Re: [Mailman-Developers] How to set up mailman 3

On Mar 30, 2017, at 09:45 PM, Jan Jancar wrote: >This would also go well with an idea I had about the current state of >the REST API and encrypted lists. With having decorators like >"@exported_REST", another one could get introduced, something like >"@requires_permission("some.perm.name")" which

Re: [Mailman-Developers] How to set up mailman 3

On Mar 31, 2017, at 03:01 AM, Stephen J. Turnbull wrote: >That sounds cool, but I tend to feel that WADL gets pretty heavy. If >we can't just mark things with something like "@exported_REST", it's >not clear that the maintenance burden is worth it. Agreed, but note this is only one half of the

Re: [Mailman-Developers] How to set up mailman 3

On Mar 30, 2017, at 12:57 PM, Stephen J. Turnbull wrote: >Would you recommend against even exploring for a lightweight approach >for some reason? Ie, the idea is bad according to some principle? To the contrary, I think if it were possible it would be pretty nice. In fact, you could

Re: [Mailman-Developers] How to set up mailman 3

On Mar 29, 2017, at 02:07 PM, Stephen J. Turnbull wrote: >Would it be possible to automate this? I haven't thought carefully >about it, specifically security issues. However, there could (in >theory) be an automated export of "all parameters" in "expert mode" or >"site/list initialization

Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

On Mar 23, 2017, at 12:06 AM, Stephen J. Turnbull wrote: >FYI: Encrypted lists *are* occasionally requested. Another possible use case would be attempting to prevent the wholesale compromise of email storage. Meaning, if you keep your email on some external server, and that server is

Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

On Mar 21, 2017, at 07:27 PM, Stephen J. Turnbull wrote: >Not if the target membership isn't already paranoid. Remember, >20%-40% of devices are already compromised. Even at the low end, >assuming uniform draws, with *three* members odds are *even* that one >is compromised. Is anybody even

Re: [Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

On Mar 15, 2017, at 09:47 PM, Rich Kulawiec wrote: >What all of this means is that once a list passes N members, where >we can debate about N, the probability that at least one of those >members has already been compromised even before they've joined the >list starts rapidly increasing. That

Re: [Mailman-Developers] Dev-env setup query

On Mar 09, 2017, at 03:02 AM, raditya wrote: >Dear mentors, for some reason i'm not able to setup the dev-env on my >machine using the SSH key method so i figured that i can do it using >HTTPS as well. Is there any drawback of doing so other than the fact >that i will have to input my username

Re: [Mailman-Developers] In regard to GSoc-17

On Mar 07, 2017, at 06:29 PM, Stephen J. Turnbull wrote: >Barry Warsaw writes: > > > Note that 3.4 is also an officially supported version for core. > >Yes. Let me clarify that I was referring to what the mentor (me ;-) >is willing to support for this GSoC pro

Re: [Mailman-Developers] In regard to GSoc-17

On Mar 06, 2017, at 07:11 PM, Stephen J. Turnbull wrote: >Python 2.7, Python 3.5 (both 2.7 and 3.5 are currently *required*), >plus Python 3.6 if you're adventurous (GNU Mailman 3 doesn't >officially support Python 3.6 yet) Note that 3.4 is also an officially supported version for core. Mailman

Re: [Mailman-Developers] What characters should be allowed in listnames

On Feb 12, 2017, at 03:58 PM, Mark Sapiro wrote: >Core validates listnames by ensuring the fqdn_listname is a valid email >address. This is too liberal. RFC 5321 allows many characters in the >local part of a list name. We don't allow quite all of them, but we >allow this set

Re: [Mailman-Developers] Fwd: Mailman | The unsubscribe process using the -leave address does not work because of an `assert` in the code (#310)

On Feb 09, 2017, at 08:39 AM, Mark Sapiro wrote: >Except that Issue #309 was opened yesterday, well after the GL database >incident. So I would think that Issue #310 would have to have been >created after that. > >It seems that something erased or lost issue #310 after it was posted, >but I don't

Re: [Mailman-Developers] Fwd: Mailman | The unsubscribe process using the -leave address does not work because of an `assert` in the code (#310)

On Feb 09, 2017, at 07:38 AM, Mark Sapiro wrote: >@abompard I don't know what's going here. I received the notice below from >GitLab. I tried to go there to comment that this looks like a duplicate or at >least very similar to which >was fixed about

Re: [Mailman-Developers] Development Enviromnent setup

On Feb 01, 2017, at 11:57 AM, Diptanshu Jamgade wrote: >I have clonned the mailman gitlab repo(forked version) and created a >python3 virtualenv using `virtualenv p- python3 `. Then I >activated the virtualenv and did `python3 setup.py develop`. On completion >I did `mailman info -v`. This

Re: [Mailman-Developers] Serious issue with Mailman MR 238, PEP 475

On Feb 01, 2017, at 08:13 AM, Mark Sapiro wrote: >Yes, that seems good. Thanks Mark. When GitLab returns, I'll get that patch landed. Cheers, -Barry pgpPHqi0kS_TM.pgp Description: OpenPGP digital signature ___ Mailman-Developers mailing list

Re: [Mailman-Developers] Serious issue with Mailman MR 238, PEP 475

On Jan 31, 2017, at 09:28 PM, Mark Sapiro wrote: >I.e. when logrotate SIGHUPs the master to reopen logs, all the runners >except for 'rest' exit. Can you try this? -Barry diff --git a/src/mailman/core/runner.py b/src/mailman/core/runner.py index 9f80941..707ad5e 100644 ---

Re: [Mailman-Developers] Mailman 3 Dockerfile

On Jan 26, 2017, at 07:38 PM, Simon Hanna wrote: >Please note that mailman-bundler currently doesn't produce a usable >environment. I think bundler does more harm than good. We should probably just abandon it, we don't really have anything better. I don't have any strong opinions about what

Re: [Mailman-Developers] About Mailman 3.1 release date

Hi Ruben, On Jan 13, 2017, at 04:08 PM, Ruben Ibanez wrote: >From our organization we are really looking forward for the coming 3.1 >release of Mailman as we would like to migrate our current Mailman 2.1. We >are looking that in your git page >https://gitlab.com/mailman/mailman/milestones/2 the

Re: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3

Reviving an ancient thread. On May 28, 2016, at 10:27 PM, Simon Hanna wrote: >I used Zanata, but found it not very intuitive to use. It's also >painfully slow. > >I'm unaware of any big projects that use zanata. Well openstack does, but >they use a self hosted version and that one is not faster.

Re: [Mailman-Developers] Contributing to Mailman Core

On Dec 09, 2016, at 04:59 PM, Nikhil Rayaprolu wrote: >Hello, I would like to contribute to mailman core . Can any one mentor me >by picking some issues in core application which could make me understand >the code structure. and also guide me through understanding the core module. > >I made two

Re: [Mailman-Developers] Aspiring for GSoC

On Jan 03, 2017, at 03:02 PM, Sayak Sen wrote: >I've already setup the mailman components and started to contribute in some >of the bugs in Postorius. But recently, I get to know that Mailman may not be >accepting projects based on Postorius. So, In what other Mailman component I >should try

Re: [Mailman-Developers] [MM3-users] Re: Mailman 3.1 beta coming soon

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

Re: [Mailman-Developers] Mailman 3.1 beta coming soon

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

Re: [Mailman-Developers] Mailman 3.1 beta coming soon

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 begi

[Mailman-Developers] Mailman 3.1 beta coming soon

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

Re: [Mailman-Developers] PGP support for MM3

On Nov 18, 2016, at 04:26 PM, Dominik wrote: >I'd like to see PGP support for MM3 but I thought it might be a little >to early to file an issue. I think full PGP support as many people want will be a multi-issue, multi-branch effort. For example, I can imagine a branch that enables

Re: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016 Canada

On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote: >It was a good idea at the time, but IMO it will be way too much work >to keep up to date as is. If we must provide a bundle, I think we >should use something like Simon's script (AIUI) to create a fully- >provisioned tree from git,

Re: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016 Canada

On Nov 15, 2016, at 03:37 AM, Stephen J. Turnbull wrote: >Also, I've done a little tracker curation (specifically HyperKitty), >mostly tagging -- probably you should assume nothing important is >happening if you get notices. Thanks Steve! I guess I should use this opportunity to say that I'd

Re: [Mailman-Developers] Adding gitlab group members and permissions

On Nov 15, 2016, at 04:26 AM, Stephen J. Turnbull wrote: >I added a new group member (mdupuis) with Reporter permission, and >upgraded existing members (adammendoza, aniketshukla, khushbuparakh) >to "Reporter". Dunno what policy is but Reporter looks pretty >harmless, and Guest is pretty

Re: [Mailman-Developers] MM3 DMARC mitigations

On Nov 06, 2016, at 05:39 PM, Stephen J. Turnbull wrote: >Maybe it's time to default to rejecting posts from p=reject domains, >with the explanatory message: > >Your domain publishes a "p=reject" DMARC policy, which is a >statement to recipients that they allow you to send only >

Re: [Mailman-Developers] Request to process merge requests faster

On Sep 13, 2016, at 12:43 AM, Simon Hanna wrote: >I know all core devs are volunteers, and no one is maintaing the Mailman >projects full-time, but it's a little frustrating to have your merge request >open for a couple of months without any/much reaction to it... Simon, I personally apologies

Re: [Mailman-Developers] REST returns 405 to PATCH in development environment.

On Oct 18, 2016, at 10:11 PM, Mark Sapiro wrote: >I get it and I will fix. > >I also note that in my production installs (current branch heads) >Postorius can't edit a domain for the same reason. That's what threw me >off as I assumed editing a domain worked in general and just not in my

Re: [Mailman-Developers] REST returns 405 to PATCH in development environment.

On Oct 17, 2016, at 07:23 PM, Mark Sapiro wrote: >It all seems to work except editing. I can create a domain with or >without an alias_domain, see it all listed and delete the domain, but >any attempts at editing the domain fail with the core REST server >returning 405 to the PATCH request. Even

Re: [Mailman-Developers] Sequence of steps?

On Aug 29, 2016, at 05:46 PM, Mark Sapiro wrote: >Here's what I've had in mm_cfg.py to do this on my production site for a >long time > ># ># Put MimeDel ahead of Hold so "too big" is based on content filtered ># message. ># >GLOBAL_PIPELINE.remove('MimeDel')

Re: [Mailman-Developers] wiki.list.org theme

On Aug 26, 2016, at 11:11 AM, Mark Sapiro wrote: >I haven't really done any deliberate testing, but I've been using it for >over a week with no issues that I have noticed. Me too, looks great. >I have now set the wiki's default theme to listorg. \o/ Thanks Jim, Mark. -Barry

Re: [Mailman-Developers] Remediation for fake member creation

On Aug 22, 2016, at 01:03 PM, Franck Martin wrote: >While mailman does double opt-in, one can still fill a mailbox with account >confirmations, what are the methods to stop a bot submitting email addresses >for registration across several lists? Mailman 3 will not pend a registration request

Re: [Mailman-Developers] wiki.list.org theme

On Aug 17, 2016, at 06:25 PM, Jim Tittsler wrote: >I have moved the old wiki theme from Launchpad[1] to GitLab[2] (which >turned out to be harder than it should have been[3] :-). Yeah, I've hit that one myself. ;) >The theme now copies much of the list.org theme, but I am not yet happy >with

[Mailman-Developers] Thinking about Gmane

You may have seen this post from Lars Ingebrigtsen of Gnus and Gmane fame; it was linked from Slashdot over the weekend: https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ If you're not familiar with Gmane, you really should check it out while you can. I think it's the perfect companion

Re: [Mailman-Developers] Blog Post: GSoC : Message Queue based archiver project

On Jul 29, 2016, at 02:06 PM, Anirudh Dahiya wrote: >I've put up a blog post mentioning the progress made in the project. >http://codefullofsummer.blogspot.in/2016/07/a-long-due-post-status-update.html Very cool, thanks for the blog post! We had a great discussion this morning on IRC about the

Re: [Mailman-Developers] Countdown to the 3.1 release

On Jul 13, 2016, at 12:18 PM, Simon Hanna wrote: >I guess https://gitlab.com/mailman/mailman/issues/219 should be fixed in >the next release. If 3.1 find its way into repositories, we will get >lot's of issue reports for this I suppose. Thanks Simon. I've put this in the 3.1 milestone and will

[Mailman-Developers] Countdown to the 3.1 release

Previously I mentioned the three big outstanding branches that I'd like to land for Mailman 3.1 Core, the templates branch, the MySQL support branch, and the unsubscription workflow branch. I've now also gone through all the bugs previously targeted to milestone 3.1, and there are only three

[Mailman-Developers] Templates branch for Mailman 3.1

Hello developers! There are three big features still in progress for Mailman 3.1, the templates branch, MySQL support, and unsubscription workflow. There is already a merge request for MySQL support and I'm hoping to merge that soon. Abhilash is also working on the unsubscription workflow

Re: [Mailman-Developers] GSOC:Populating two default styles

On Jun 24, 2016, at 03:14 AM, Harshit Bansal wrote: >I was trying to populate the two default styles in the database. For >this purpose, I was trying to use ConfigurationUpdatedEvent as used in >the earlier style manager but I am recieving following error: [...] >AttributeError: No section or

Re: [Mailman-Developers] New Interface

Steve's got it right. Just a few other thoughts. On Jun 06, 2016, at 03:35 PM, Stephen J. Turnbull wrote: >(2) SQLAlchemy (and the underlying RDBMSes) allow you to have optional >fields. This is implemented by storing NULL in the missing field. I think we'd prefer this method, i.e. that

Re: [Mailman-Developers] New Interface

On Jun 04, 2016, at 07:38 PM, Harshit Bansal wrote: >Would you like to keep these attributes(those which are unused and we >don't want to support) or should these be removed? For now, keep them. It would probably make sense to open an issue on gitlab listing the unused attributes to delete. We

Re: [Mailman-Developers] Postorius issue tracker labels

On Jun 04, 2016, at 08:46 AM, Terri Oda wrote: >I'm not sure "rest" is the way it's currently being used either: it might be >more useful to rename it to be like the wait-for-mailman tag to indicate bugs >that occur due to mailmanclient. 'wait-for-mailman' is just a little weird given that we

Re: [Mailman-Developers] New Interface

Thanks for posting this Harshit. This is a useful discussion to have, and I have some thoughts, but first a little history. In MM2.1, the MailList class is composed of a number of mixins, each of which implements a general chunk of functionality, such as NNTP or digests, etc. I really didn't

Re: [Mailman-Developers] Code Duplicacy

On May 24, 2016, at 11:48 PM, Harshit Bansal wrote: >I was writing the new 'IStyle' interface and after completing some part of >it I realised that the code has become a bit repetitive as all the >styleable attributes which are present in src/interfaces/mailinglist.py are >to be copied to

Re: [Mailman-Developers] Translating notifications raised by mailman-core in postorius

On May 17, 2016, at 11:15 AM, Simon Hanna wrote: >Theoretically the core could translate the messages before passing them >to postorius. This would require core to know about the language it >should translate to. I don't think this is a very good approach because >we would have to make sure we

Re: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3

Hi Simon, On May 17, 2016, at 03:31 PM, Simon Hanna wrote: >I guess I could take some sort of lead on that. I played around a little >with pootle and I really like it. It's easy to use, fast and anyone that >registers can start translating. Just by way of comparison, have you played with

Re: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3

>On 04/12/2016 03:27 PM, Simon Hanna wrote to Mailman-Developers: >> Hi, >> >> I just completed setting up the Mailman 3 projects on zanata.org >> They can be found here: >> >> https://translate.zanata.org/project/view/mailman >> https://translate.zanata.org/project/view/postorius >>

Re: [Mailman-Developers] Postorius and verified email addresses

On Apr 07, 2016, at 02:46 AM, Simon Hanna wrote: >I don't mind the core being able to handle verfications. But I'm pretty sure >everyone that offers a web interface for managing mailman will want the >ability to confirm emails using http links. Absolutely. This is the focus of my "templates"

Re: [Mailman-Developers] Postorius and verified email addresses

On Apr 07, 2016, at 12:26 AM, Simon Hanna wrote: >Short version: it supports both external (social) and internal (django) auth >systems and offers options to combine/switch between them . Allauth provides >Signals that I used to verify the addresses in Mailman. I think we have to decide how and

Re: [Mailman-Developers] Postorius and verified email addresses

On Apr 06, 2016, at 06:08 PM, Aurelien Bompard wrote: >In that case, how should this address be validated? Should Postorius >consider that the login system always validates addresses and set them as >verified in Mailman? Should it ask mailman to verify the email addresses >when it encounters a

Re: [Mailman-Developers] Unable to commit changes from mailman shell to database

On Apr 03, 2016, at 01:30 AM, Gurkirpal Singh wrote: >Maybe it was there because I'm using PostgreSQL but it worked for me. Cool, so it's working now? I believe SQLAlchemy opens a transaction automatically, so that the bound commit() and abort() methods operate on that transaction. By creating

Re: [Mailman-Developers] Unable to commit changes from mailman shell to database

On Apr 02, 2016, at 06:17 AM, Anirudh Dahiya wrote: >I have been playing with mailman shell but upon creating objects like >domains and addresses, and subsequestly committing them to database by >calling transaction.commit() I am unable to see changes in the database(and >thus on Postorius) >The

Re: [Mailman-Developers] Rosters not using 'ISubscriptionService' Interface.

On Apr 01, 2016, at 01:59 AM, Harshit Bansal wrote: >I was looking at the 'rosters.py' and I am unable to understand that >why are rosters not using 'ISubscriptionService' interface instead of >making raw queries for finding members? Is there any reason for doing >so and if no then should it be

  1   2   3   4   5   6   7   8   9   10   >