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

[Barry Warsaw]

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 documentation
> style for Mailman Core's config options. Internally, Mailman has
> all configurations defined in an ini formatted `schema.cfg` file, which
> serves as a schema for our `zope.configuration` library. We had that file
> simply embedded in the sphinx documentation previously as a wall of text.
> 
> I ended up writing a Sphinx (our documentation generator) plugin which
> parses the config file and presents the same documentation with more
> bells and whistles so it is easier to lookup and link sections and config
> options.[1]
> 
> The process of doing that was fun and I learnt how to write a simple
> sphinx plugin, so yay! It treats the comments above each config option
> in the ini file as it's doc and basically generates ReST text that it passes
> to Sphinx to parse and convert to the markup format that you see in
> browser. You can look at it in the source repo[2] .
> 
> Do note that not all sections are documented yet, I am still figuring out what
> would be a good way to document template sections like `[plugins.master]`
> and other similar sections of that kind.
> 
> [1]: 
> https://gnu-mailman--667.org.readthedocs.build/projects/mailman/en/667/src/mailman/config/docs/config.html#configuration-options
>  ((URL is for the PR,
> the main doc seems like is serving the cached version from an older
> build).
> [2]: https://gitlab.com/mailman/mailman/-/blob/master/_ext/configplugin.py
> 
> --
>  thanks,
>  Abhilash Raj (maxking)
> ___
> Mailman-Developers mailing list -- mailman-developers@python.org
> To unsubscribe send an email to mailman-developers-le...@python.org
> https://mail.python.org/mailman3/lists/mailman-developers.python.org/
> Mailman FAQ: https://wiki.list.org/x/AgA3
> 
> Security Policy: https://wiki.list.org/x/QIA9



signature.asc
Description: Message signed with OpenPGP
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 development of Mailman 3
> core.  I love Barry and deeply respect his judgment, but I find the
> idea itself offensive :-), so dealing with it on the core side is on
> my own TODO list.  Let's cooperate!

Love you too, man!  I actually don’t remember saying this, but definitely don’t 
take my word on that :).

If I did say it , what I probably meant is that there is some 
functionality which still needs to be exposed in the REST API, and other 
functionality that could use a more efficient surfacing through the REST API.  
For example, you want to reduce the roundtrips for common tasks against many 
objects.  This is difficult to do in REST — you basically have to expose 
collection resources, search resources, etc. but they all feel somewhat 
artificial to me.  GraphQL seems to handle things like this much better, but of 
course MM3 does not have a GraphQL API.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 answer is to simply not import passwords, and ask that users reset 
them if they need it, which they probably won’t.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 to create a new 
> subproject on gitlab for UX issues (I use this model of doing UX work under a 
> separate subproject and using the repo to host UX mockups for other projects 
> and it works well.)
> 
> If that sounds reasonable and you'd have me, can you help set me up with a UX 
> subproject? My gitlab username is mairin.

I’m not running the project any more, but it would be great to have you back Mo!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mm3/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 helped, and continue to make Mailman 3 a great project.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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; configuration options are read-only through REST because they are 
specified in the mailman.cfg file.  You wouldn’t want to (and probably even 
can’t) allow REST clients to change things that aren’t kept in the database.

On Jan 31, 2018, at 15:03, holger  wrote:

> sounds good.  Is it also possible to hook into the standard mm3 configuration,
> for adding a per-list configuration item that can then be processed by
> plugin code?

Per-list configurations are maintained in the database, configuration files 
(e.g. mailman.cfg) configure site-wide static settings.  That’s because lists 
are dynamic; they can be created, deleted, and modified.  But your plugin 
should be able to create its own tables and cross reference the mailing list 
tables (via the SQLAlchemy ORM).

Static configurations can be added to a [plugins.autocrypt] section, or better 
a separate autocrypt.cfg file, much like the way we separate out the 
postfix.cfg settings.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 for my works on pypy, tox or pytest but
> this mail will be about something else …

Indeed.  If autocrypt becomes even a fraction as amazing, joyful to use, and 
essential to our toolkits as those others that you work on, it will undoubtedly 
succeed.

> In the last year i co-instigated a new opportunistic mail encryption
> effort called Autocrypt (https://autocrypt.org). With Autocrypt Level 1,
> mail clients (e.g. enigmail, K-9 mail, Delta.chat, ...) send and parse
> public keys in "Autocrypt" e-mail headers and offer single-click
> encryption.  Releases are upcoming in spring 2018, we have been
> doing fun and well-received user-testing sessions already
> with in-development versions.

Have there been any talks about creating plugins for commercial MUAs like 
Mail.app, Postbox, and Outlook?  Do you have plans for webmail clients like 
Gmail or Outlook?

> In 2018, I'd like to tackle basic integration of Mailman and Autocrypt,
> to achieve opportunistically encrypted mailing lists.  The main idea is to
> grow a mailman mode/plugin to:
> 
> 1) have mailman lists maintain a public pgp identity that
>   is added through Autocrypt headers to outgoing mails.
> 
> 2) have mailman keep track of "incoming" autocrypt keys
>   and decrypt incoming mails if they are encrypted.
> 
> 3) encrypt to those subscribers where we have a proper Autocrypt key
> 
> Code wise, i'd like to tackle this based on the the new and evolving
> (and quite unpublic so far) "muacrypt" project:
> https://muacrypt.readthedocs.io
> 
>> From looking at archives and the GSOC idea page i see there were related
> efforts and ideas.  Are there pointers to draft implementations that
> are still somewhat up to date (with mm3)?

I’m not really sure what the state of those previous efforts are, i.e. whether 
they’d be applicable to the current code base without a serious rebase.  ISTM 
that at least some of the changes in general would still be applicable, e.g. 
model changes to manage keys.

> Also, i am considering to submit a project proposal for the
> Mozilla Mission Partners program which would include a few more
> things ... OnionMX routing for postfix, and documentation on
> how to setup a best-practise MM3 mail instance, and maybe organizing
> a sprint around the mentioned topics.

Cool.  I think for best-practices in standing up an instance, you should 
definitely look at Abhilash’s docker images.  A sprint would be fun for sure.  
Are you thinking Pycon US 2018 or elsewhere?

> collaboration welcome'ly yours,
> 
> holger
> 
> P.S.: i had discussed mm-encryption with Barry 2-3 years ago
> and feel now, with Autocrypt getting out the door, it's all
> becoming more feasible.

Indeed; having a specification and library for many of the details would help 
quite a bit.

I’ll say this; there have been countless discussions on the mailing list about 
whether list traffic encryption really helps or not, how easy it would be to 
subvert, and other related topics.  I still think it’s an interesting and 
useful feature that will satisfy enough use cases to make it worth working on.  
Then we have to ask whether this is of general utility to make it a built-in 
Mailman 3 feature.  That decision can certainly be deferred because you can 
probably get pretty far with the much better plugin support in Mailman 3.  I’m 
sure you could do a pretty good PoC as a plugin.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 added in a later version.

Yes, I see the problem with that.

> We need some way to associate attributes with a minimum Core version, which we
> can get from `/system` endpoint. Although, for now, it probably is an 
> overkill.
> I will do some static stuff to take care of this.

What happens when someone runs from say git head though?  /system/version won’t 
keep up with that, and besides, it’s going to become an increasingly big 
compatibility matrix over time.

> How bad do you think would it be for Core to silently drop extra attributes 
> and
> only use the ones that it needs?

I think it could be problematic, as Steve points out.

I don’t really have a good answer, and I’m wondering what the state of the art 
is.  Maybe we should ask some experts for advice (we do have some friends who 
are experts in this).

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 required for some
JavaScript libraries.  It couldn't be autodetected in all cases.  In
general though, we've mostly be able to manage changes in a backward
compatible way.

> However, one question that I have been thinking about recently is how to 
> handle
> additions to REST API that don't necessarily break the backwards 
> compatibility.

This problem is analogous to adding arguments to functions.  This is
usually handled in backward compatible ways in Python by appending new
arguments to the end of the parameter list and giving them default
values.  Or to use keyword-only arguments.  The analogy breaks down in
one specific case though.

> For example, Core added `max_message_size` attribute to MailingList's REST
> endpoint, but it hasn't made into any released version yet. Also, Postorius
> added max_message_size in `Message Acceptance` settings. The problem here is
> that the entire PUT/PATCH request is going to fail if the currently running
> version of Core doesn't have `max_message_size` attribute exposed (Unknown
> Attribute Error).

PATCH won't fail because it allows for partial representations.  PUT
does fail because it requires the entire new representation to be
included in the request (it's a complete replacement).  This is where
the analogy to function arguments break down.

I don't really know of any good way to handle this that still conforms
to REST principles.  I don't think we want to rev the API in these cases
since that'll result in a lot of version churn.

> There is no easy way to check for whether the Core has this attribute as API 
> is
> versioned at 3.1 for both cases.
> 
> So, how do we actually handle this and maybe future cases like this?

Simon suggests:

* The result of queries can be viewed as dictionaries
* New endpoints (urls) can be added anytime
* No endpoint is removed without a version bump
* Existing dict keys will not be dropped without a version bump
* The format of values assigned to existing keys will not change without
a version bump
* New keys (and values) can be added anytime

This is pretty much the criteria I've used in the past, and it works
well enough in practice except for the PUT exception.  A couple of
thoughts on how to handle this include, using PATCH in preference to
PUT, using PUT but catch any exception then fall back to PATCH, do a GET
first to get the list of keys.  None of those are great options,
although some caching might help.

Mailman's REST API is very dynamic so we don't even have a static
representation of it that can be queried.  I did a quick scan of RESTful
Web APIs (Richardson & Amundsen - my go to bible for REST design
philosophy) and didn't find a specific discussion on this topic.

Cheers,
-Barry


signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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.  That’s why for example a new API 
version was introduced to handle the UUID data type change.  There was no way 
to make that backward compatible, so we had to bump the API version, but we 
didn’t remove the old API version so clients written against that still work.  
Adding a new API generally doesn’t require bumping the API version.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 install, with manual 
> installs using the master branches for "experts" I wonder why you are using 
> Quay.
> It looks like it's a non-free system. Why use Quay but refuse to use a 
> non-free translation system like transifex?

Is there a free (software) equivalent to Quay?  Caveat: I don’t know anything 
about Quay, so I don’t know what services and advantages it provides.

> If this campaign succeeds, here is a road map of what I intend to get
>> done:
> Sounds great, what is the limit where the campaign succeeds? What will happen 
> to the funds if it doesn’t?

The funds all go to the GNU Mailman project’s FSF donation fund.  A portion of 
every donation goes to the FSF, and the Mailman Steering Committee ultimately 
decides what to do with what’s left in our account.  In the past we’ve used it 
sponsor GSoC students coming to Pycon sprints.

> To be honest, I don't think we should all in on containers.
> Yes they are nice, but I guess most people would prefer distro packages.
> Even if people want containers, I for instance would prefer plain 
> systemd-nspawn

There are folks working on Debian packages.  I’m not aware of similar efforts 
for other distro ecosystems.  But I don’t think it’s all or nothing, and it 
does make sense for us (the GNU Mailman project) to support containers to help 
with adoption, experimentation, and deployment, while working with distro 
volunteers to package the code up for those platforms.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Signing commits with gpg

[Barry Warsaw]

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 and releases for Core.

> Another thing that just came to mind: how does commit squashing work? You'll 
> probably have to do that offline and not use gitlabs autosmashing…

I would think that squash merges would destroy the record of any intermediate 
signed commits.  Core doesn’t have a firm policy either way; sometimes I squash 
merge sometimes not.  I’m philosophical   opposed to squash merging, but git 
often really makes me want to do it anyway.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Signing commits with gpg

[Barry Warsaw]

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.,
> 
> where linus argues that "Signing each commit is totally stupid." and
> that you should sign tags but not commits.
> 
> I don't know enough about the internals of this to have an opinion, and
> as I said I will be signing my commits going forward, and the post I
> link to is over 8 years old and things might have changed, but there it
> is for what it's worth.

I’m not sure that any of the points Linus brings up in that thread have 
changed, but I’m also not sure how relevant they are to our workflow.  It’s 
interesting enough that Gitlab is now showing the verified tag for signed 
commits, although TBH, I’m also not sure how much that buys us in practice.  
Still, it’s easy enough to experiment with, so let’s do it and see if it has 
any practical impact on us, either pro or con.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Signing commits with gpg

[Barry Warsaw]

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 has enabled this!  Thanks for sending the recipe too.  I 
definitely encourage folks (especially core devs) to start signing commits.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Renaming a list

[Barry Warsaw]

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 aliases are
> not added to the postfix_lmtp file, as a result emails sent to the old
> address are just bounced at the Postfix level.
> Is this the intended behavior ?

It is.  The thinking is that whatever email addresses end up funneling to a 
list is really outside of Mailman’s control.  That’s really part of your MTA’s 
configuration, and acceptable aliases are just a way of telling Mailman to 
expand its implicit address logic.

> BTW, changing the list_name attribute is sufficient to rename a list,
> right? I didn't find anything else to change since everything seems to be
> keyed to the list_id but I thought I'd check with you.

Correct.  List name is mutable but list-id is not, even if you move it to a 
different domain!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 double-diamond
> application.  As I wrote in a different thread, I don't think Mailman
> 3 is going to be ready for the mom & pop listowner for a while.  If
> versions of Centos (or whatever) don't support Python 3 by then, "let
> them run containers". :-)

Yep, and we have a good container story now, so I think that’s entirely viable. 
 There is work being done on Debian packaging for MM3 and I think having 
everything on Python 3 should make that story better too.  (Debian unstable 
does have Python3 Django).

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GDPR

[Barry Warsaw]

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 Safe Harbour) as well as
> enterprises in EEA member countries and, outside of the  EEA,  countries
> whose  privacy laws have been assessed for adequacy.  Operators of lists
> such as MM are as much called-to-account as are  the  vast  corporations
> behind  popular  social media that currently absolve themselves as being
> mere publishers.

GDRP may be well-intentioned, and may even be a good idea, but I know
for a fact that many organizations both commercial and volunteer are
struggling mightily to comply within the required timeframe.  I suspect
that many such organization will simply not be able to comply.

Realistically, there is no way the GNU Mailman project can comply given
our available resources.  One outcome could be that our downstream
consumers take over that responsibility.  Another is that volunteers in
our community step up with offers to provide us with their expertise,
guidance, and code.  We will welcome such volunteers and help ensure
that the legal requirements align with project goals, sensibilities, and
timelines.

So, if you want to see a GDPR compliant GNU Mailman, please find some
people to help us.

Cheers,
-Barry


___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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
> we think that people know how to do that.
> 
> The now defunct mailman-bundler has a sample systemd mailman3.service
> file but that's it.
> 
> This click issue is a definite gotcha however and should be mentioned.
> Perhaps an additional section at 
> could mention it. It wouldn't necessarily need to give entire scripts,
> but just mention that click requires that a minimal locale setting be
> exported before issuing 'mailman' commands.

See what you think about https://gitlab.com/mailman/mailman/merge_requests/316

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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.

Can you suggest a good place to document this?

-Barry


signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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  wrote:
> 
> On 09/02/2017 08:50 AM, Mark Sapiro wrote:
>> The only thing that has changed is the
>> /etc/init.d/qcluster script (attached as qcluster.txt). This existed
>> before, but was changed to use start-stop-daemon and to add a 'stop'
>> function.
>> 
>> I also did 'update-rc.d qcluster defaults' to create the rc*.d entries
>> for qcluster which I had neglected to do before. The entries for
>> mailman3 are there (unchanged in over a year).
> 
> 
> The issue seems unrelated to qcluster. As a test, I stopped qcluster,
> removed /etc/init.d/qcluster and the /etc/rc*.d entries and rebooted the
> server and mailman still wasn't started on reboot.
> 
> --
> Mark Sapiro The highway is for gamblers,
> San Francisco Bay Area, Californiabetter use your sense - B. Dylan
> ___
> 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/barry%40list.org
> 
> Security Policy: http://wiki.list.org/x/QIA9



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Plugins

[Barry Warsaw]

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, especially if you don’t 
follow the GitLab MRs too closely.

For reference, here’s Jan’s original MR:

https://gitlab.com/mailman/mailman/merge_requests/288

Here’s my MR that builds on top of that.  My current intent is to land this MR 
instead:

https://gitlab.com/mailman/mailman/merge_requests/308

It may not be terribly helpful at this point to scour the MR’s comments.  
Instead, please read the documentation on plugins here:

https://gitlab.com/mailman/mailman/blob/3572b11c2d42de0fa749786d35df5e660b21c4b3/src/mailman/plugins/docs/intro.rst

GitLab does a passable job of rendering this, but it will look even better once 
this MR lands and the RTD docs are built.  Notably, you’ll miss the “literal 
includes” which show how some of the configuration files and hook modules will 
look.  Check out the branch and run `tox -e docs` to see the locally rendered 
page, or just view the source of the MR.

You should be able to get enough of a gist about how it’ll work.

Comments welcome, either here or in MR!308.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Mailgun email libraries

[Barry Warsaw]

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 Flanker library for email address and MIME parsing.  
Flanker is Apache 2.0 licensed although unfortunately only Python 2 currently.  
Here’s a blog post about it, along with their GitHub repo:

http://blog.mailgun.com/we-just-open-sourced-flanker-our-python-email-address-and-mime-parsing-library/
https://github.com/mailgun/flanker

This is mostly an FYI email since I’ve only had time to read the blog post and 
briefly skim the docs, but there may be interesting things we can learn from 
their work.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Click CLI branch

[Barry Warsaw]

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-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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Click CLI branch

[Barry Warsaw]

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
> additional help, see --details.
> 
> The additional arguments are not actually passed as subsequent
> positional arguments to the callable.  They are passed as a single
> positional argument which is a tuple of the additional arguments.
> 
> --details is correct in its example showing
> 
> def change(mlist, args):
>mlist.display_name = args[0]
> 
> but the --run description makes me think it should be
> 
> def change(mlist, name):
>mlist.display_name = name

Thanks Mark.  I’d like to preserve the API of Mailman 2.1, so I’m changing that 
back to passing them in as positional arguments (i.e. to match the —run 
description).

Just testing that change locally now.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Click CLI branch

[Barry Warsaw]

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

https://github.com/pallets/click/issues/834

TL;DR: Your workaround provided the essential clue.  The main difference
between the original code and your workaround is that the latter omits the
embedded newlines.  Click apparently dedents the text but doesn't remove the
newlines and that confuses click's formatting code.

In the meantime, I have a workaround that I'm in the process of implementing.

Cheers,
-Barry


pgp8ccNVJ2Ny9.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Click CLI branch

[Barry Warsaw]

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 signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Click CLI branch

[Barry Warsaw]

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 additional search paths, and 
probably some better documentation that would be part of a general “Extending 
Mailman” section.)

Along the way I think I’ve made several other improvements, including (I hope!) 
reducing or eliminating the occasional hangs we see on CI, speeding up the test 
suite a bit, and making things more robust.

Please feel free to review it and play with it.  It’s finishing CI now but I’ll 
hold off on merging it for a day or two.  I’m especially interested to hear 
what Jan thinks for the plugin work he’s doing.

The big downside could be that because this is such a big change, existing MPs 
may have to be rebased.

It’s a big branch with lots of little sweater threads that took longer than I 
expected, but I should be done now, and I think it will be a good improvement 
to the code.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 refused

What does `mailman info` say?  That will print the hostname:port that the REST
server is listening on, and the basic auth credentials in use.  All of those
are of course configurable in your mailman.cfg file.

If your curl arguments match what `mailman info` says, then there must be
something else going on.  Maybe there's a firewall issue?  You can also check
the Mailman logs to see if you're getting some exception or other in the
server, and of course you can also adjust the logging level in the mailman.cfg
file.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 what I'm using (python command line, curl, etc).  I'm
>feeling like apache doesn't know where to point port 8001, and I don't know
>what to tell it.

To supplement what Mark said, there are a few things to keep in mind with the
REST API.  First, you really don't need to put Apache in front of it, as
Mailman Core already provides an HTTP server for the REST API [*].

Second, you definitely do *not* want to expose the REST API on the public
internet.  It's an administrative API so it has full access to you list
server.  It only provides very basic authentication and no user based
authorization, so any process with the basic auth keys can do anything.

We have a *very* nascent project called Lemme which is geared toward a public
facing authenticating REST proxy.  While we have ideas for how it would work,
we haven't had many resources available to work on it.  Contributions of course
would be greatly welcomed!

https://gitlab.com/mailman/lemme/blob/master/README.rst

Cheers,
-Barry

[*] By default we use the stdlib simple wsgi server, which is convenient but
makes no claims of being very performant.  Hopefully for 3.2 I will switch to
aiohttp, uvloop, or some other better performing substrate.
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Next Postorius release

[Barry Warsaw]

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 CPython, but I've been watching its development and
it looks like an awesome tool.  I don't know how specific it is to Github or
CPython's workflow yet, but it's worth investigating.

-Barry


pgpUmgmVjScdT.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 changes to improve plugins to the core, but I really like the
direction you've chosen.

Cheers,
-Barry


pgpzzikINa9X_.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] GitLab 9.3 feature

[Barry Warsaw]

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.

https://about.gitlab.com/2017/06/22/gitlab-9-3-released/?utm_medium=email_source=marketo_campaign=newsletter_content=June+22+2017_tok=eyJpIjoiWlRneU5qUmlZamhoTXpFdyIsInQiOiI1U01mZkFYck1Ia3YxNkdhUWxMS0Z5K1pCSkd5bWxcL1BLUWh6YTN5d2JpWGdvcEI0M29pZmoyZ2hjUmxoNUFkcGdrQXEzWmU4K1IzaGJUU0FkNk4xQkc4MHVXb1o2NEw3cjBPaGJtMjRTZm43RU9XZGY5QkwzWUE0Q2hCa3dFdXUifQ%3D%3D#multi-project-pipeline-graphs

Cheers,
-Barry


pgpNSuHMQG4du.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 (src/mailmanclient/_client.py) to
>seperate class based modules. The current setup works but is huge (1300+ LOC)
>and that is ok for now, but I want to add docstrings to classes/methods and
>it would definitely make it too big!

+1!

-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 up with
anything better!

I have just a few questions, though we can hash out specifics on the MRs.

On Jun 08, 2017, at 12:45 AM, Jan Jancar wrote:

>Add plugin infrastructure
>-
>[mailman!288](https://gitlab.com/mailman/mailman/merge_requests/288)
>
>This MR is the biggest one and certainly the most important one for the
>pgpmailman plugin and other potential Mailman plugins. It adds a notion
>of a plugin to Mailman Core. To explain what I mean by a plugin, it's
>best to look at its example configuration:
>
>[plugin.example]
>path: example_plugin
>class: example_plugin.plugin.ExamplePlugin

I'm curious as to why you define both a `path` and a `class`, where the latter
has the former as the first component.  I'm not making a judgment (and haven't
looked at the branch yet), so I'm just wondering what led you to this decision.

>Mailing list styles currently have an attribute for name, which for the
>default styles is:
>
> legacy-announce
> legacy-default
>
>Which is not particularly human-readable, well it is, but doesn't look
>like something to be shown in a web ui such as Postorius. Mapping these
>style names to their descriptions in Postorius is possible, however
>since the styles are dynamically found and instantiated, it's not
>something practically doable.
>
>So this MR adds a description attribute to IStyle and adds the
>appropriate descriptions to the default styles. Also exposes said
>description to REST clients.

Have you thought about how these descriptions will be internationalized?
We'll clearly want to present style descriptions in the natural language of
the admins who are creating new lists with a particular style.

Cheers,
-Barry


pgpsGvJ1z4YzH.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] ANNOUNCE: Mailman 3.1.0 final!

[Barry Warsaw]

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, this version contains a
huge number of improvements across the entire stack.  Many bugs have been
fixed and new features added in the Core, Postorius (web u/i), and HyperKitty
(archiver).  Upgrading from Mailman 2.1 should be better too.  We are seeing
more production sites adopt Mailman 3, and we've been getting great feedback
as these have rolled out.

Important: mailman-bundler, our previous recommended way of deploying Mailman
3, has been deprecated.  Abhilash Raj is putting the finishing touches on
Docker images to deploy everything, and he'll have a further announcement in a
week or two.

Feedback is welcome:
https://github.com/maxking/docker-mailman

What is GNU Mailman?

GNU Mailman is free software for managing electronic mail discussion and
e-newsletter lists.  Mailman is integrated with the web, making it easy for
users to manage their accounts and for list owners to administer their lists.
Mailman supports built-in archiving, automatic bounce processing, content
filtering, digest delivery, and more.  Mailman 3 is released under the terms
of the GNU General Public License, version 3.

The best places to start for all things related to this release:

http://docs.mailman3.org/
http://www.list.org/
https://gitlab.com/mailman

(Note: due to timezone skew, some of the tarballs may not be available on PyPI
until tomorrow.)

Happy Mailman Day,
-Your friendly neighborhood cabal

An overview of what's new in Mailman 3.1


Feature parity with Mailman 2.1
---
* You should be able to do just about everything that you could do in Mailman
  2.1 *except* for topics and sibling/umbrella lists.

Core

* Added support for Python 3.5 and 3.6
* MySQL is now an officially supported database
* Many improvements with importing Mailman 2.1 lists
* DMARC mitigations have been added, based on, but different than the same
  feature in Mailman 2.1
* The REST API requires HTTP/1.1
* A new REST API version (3.1) has been added which changes how UUIDs are
  interpreted, fixing the problem for some JavaScript libraries
* Many new REST resources and methods have been added
* Individual mailing lists can augment the system's header matching rules
* `mailman create` now creates missing domains by default
* `mailman digests` now has `--verbose` and `--dry-run` options
* `mailman shell` now supports readline history
* `mailman members` can filter members based on their subscription roles
* A new template system has been added for all messages originating from
  inside Mailman.
* The Message-ID-Hash header replaces X-Message-ID-Hash
* New placeholders have been added for headers and footers
* Unsubscriptions can now be confirmed and/or moderated

Postorius/HyperKitty

* General U/I and U/X improvements
* Many more features from the Core's have been plumbed through
* We've adopted Django social auth logins and dropped Persona (since it's no
  longer supported upstream).  You can now log in via Facebook, Google,
  GitHub, and GitLab.

Backward incompatibilities
--
* Core/REST: Held message resources now have an `original_subject` key that is
  not RFC 2047 decoded.  `subject` is now RFC 2047 decoded.
* Core/REST: If you've run pre-release versions from git head, and stored
  welcome and goodbye templates via REST, the template key names have changed
  backward incompatibility.


pgp3i5M1JIjBs.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 the 3.1 milestone on them, and I think the 1st one should really
>be fixed (I sent a merge request) before we release.
>
>What do you think?

I'm reviewing these now.  Follow ups on the issues.

-Barry


pgpAFGTYLVULT.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 barring any unforeseen last
minute problems, I plan on just bumping the version number and releasing it.

I'm happy for others to do the tagging and releasing the other components, or
I can help with that if you prefer.  The only project I can't release to PyPI
is HyperKitty.  Aurelien, we can leave that to you or you can defer to me, but
you have to give me upload rights on the HyperKitty (and Core plugin) PyPI
project for the latter.

I'm hoping we can work on some release notes and an announcement tomorrow
while we put the finishing touches on it.

3.0 was released just over 2 years ago.  It's exciting to see all the new and
fixed stuff in 3.1; I hope you are too!  My deep thanks to the core
developers, and to all of you in the community.  As has been said at Pycon
many times this week: come for the code, stay for the community.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 for taking a look at the milestoned issues.  It looks like
HyperKitty has no more open issues or merge requests milestoned to 3.1, and
you're confirming that all HyperKitty systems are "go".

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] HyperKitty issues and MRs for 3.1

[Barry Warsaw]

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 release,
or whether we need to assign some to 3.1 and fix them before the release.

Here are some issues we have questions about.

#104 - Server Error (500) upon login with duplicate email addresses
(we're thinking maybe just turning that into a non-500 error?)

#127 - Server Error (500) upon signup

#128 - hyperkitty/setup.py should require Django<1.11
(Assigned to a sprinter, should be easy)

There are also a bunch of merge requests which we're unsure about.

Can you do a quick triage and assign anything needed to 3.1 for HyperKitty?

Thanks!
-Barry



pgpuHOskhKZw5.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Multiple REST servers

[Barry Warsaw]

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 identifying this Aurelien.  Could you open an issue on Core for
this?

Have you done any other analysis on where the bottlenecks are?  Is it CPU, db,
I/O?

Currently the REST server uses Python's stdlib wsgiref WSGIServer which I'm
positive is not performant enough for your lists.  There are a couple of
options that would be worth investigating.  I played with trying to use
gunicorn, but deleted the branch a while ago (IIRC, there were problems and I
didn't have time to investigate further).  At the very least, I want to look
into asyncio-based REST server (e.g. aiohttp, uvloop), but maybe there are
other parts of the stack we need to look at too.

-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailing lists exploited

[Barry Warsaw]

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
part of their address.

-Barry


pgpehM40Sb_Gr.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailing lists exploited

[Barry Warsaw]

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 adding a configuration option to either obfuscate the
>addresses further (e.g. drop the domain entirely) or replace the text with
>something like "Listname list run by listname-ow...@example.com".

I'm a little confused by the OP.  Is it:

1) A message to the posting address From: listname-ow...@example.com is not
being moderated?  I would expect it to be since that address is not a member
of the list.

2) Emailing To: listname-ow...@example.com directly which would end up
spamming the list owners?

MM3 doesn't currently moderate messages sent to the list owners, but it
could.  Messages to -owners flows through a different, shorter chain of rules
and pipeline, but I've always thought that that would be configurable.

-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 mailman(2|3) should support? To me it looks useful.

I probably need more convincing that it would actually be used out in the
field, since there are a lot of email standards that have been ignored (by
some tools) for decades.  But OTOH, if it's of some utility it doesn't look
like it would be difficult in core to support the extra header.  We'd need a
small bit of REST and db schema/style setting work so that the list itself
could be configured for one-click or not, depending on the web u/i being
used.  (E.g. maybe one-click unsub is supported in Postorius, but other sites
might not support it.)

>It would certainly make it easier to deal with grumpy gmail users,
>since gmail does not provide junk button feedback.

Let's call that the Grumpy 800lb Gorilla principle. :)

>The disadvantage is that every recipient needs to get a separate copy
>of each message, because the list and user info has to be encoded in
>the list-unsubscribe URL.  That's been standard in commercial e-mail
>for a decade, but a lot of discussion list operators still imagine
>that it's too slow.

For a while now I've thought about changing the defaults to individual
personalization (i.e. everyone gets a unique copy, but we don't modify the
headers).  I think the constraints leading us to no personalization may not
be all that prevalent any more, and there's no question that personalization
improves the user experience.

-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 would introduce
>permission-based granularity to the REST API. Then multiple
>user:password pairs could be specified in a config with different
>permissions and so Mailman could provide different levels of API access
>to different apps.

Our intention is to support permission based access to the REST API via an
"authenticating proxy", which we call lemme:

https://gitlab.com/mailman/lemme/tree/master

and for an outline on how this might work:

https://gitlab.com/mailman/lemme/blob/master/OUTLINE.rst

We had good discussions about this at Pycon 2016, but haven't gotten very far
in implementation details.  I'm hoping we can spend a little bit of time on
that this year.

Cheers,
-Barry


pgpYeAo5cY8pt.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 equation.  You also need to
publish the static definition of the REST API so that HTTP clients could
discover it.  That's my understanding of the role that WADL serves.

Cheers,
-Barry



pgpwaeFD0FVWY.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 conceivably eliminate mailman-client if you could do it, and
other languages could auto-generate bindings to the REST API.  I haven't kept
up on the state of the art, but IIRC, there were Python libraries that could
generate bindings based on WADL.

Cheers,
-Barry


pgpWUNDtMcI44.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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

It's probably near impossible to automate, because the Core's REST API isn't
programmatically discoverable.

As a counter-example, Launchpad's REST API provides a WADL[1] description
extracted from the code, but this makes it way too heavyweight for my tastes.
And because the Core uses a dynamic object-based traversal system (inherited
from restish and ported to falcon) it would make any kind of static REST API
description pretty difficult to generate.

Cheers,
-Barry

[1] https://en.wikipedia.org/wiki/Web_Application_Description_Language
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 compromised, if those messages are encrypted, then
at least they likely will be very difficult for the attacker to decrypt since
the keys won't likely be colocated with the emails.  Sure you can probably
phish specific individuals, but it won't be "crack the server and now you have
a million secret messages".  It's the same as with encrypted person-to-person
messages (which almost no one uses because Reasons).

>You have my permission to say "I told you so" if we're forced to
>abandon this as a silly idea.  Until then, I think you're wasting
>bandwidth in opposing it from the get-go.  Once again, I'd be happy to
>hear where our threat models are deficient once we start to talk about
>them.  But none of the proposals so far have really identified a
>threat model let alone a corresponding use case!  So there's nothing
>to criticize yet.

I should state for the record that my personal interest in this feature isn't
so much encrypted mailing lists per se, but the architectural and design
pressure it will put on Mailman 3, and our responses to that.  Encrypted lists
are the kinds of things I want to make possible with Mailman 3, so the APIs,
hooks, configurations, and plugins that would be needed to implement encrypted
lists (assuming, IMHO correctly that they won't be integrated into the core)
will be of use to others who want to do Interesting Things with mailing lists.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 aware of any mainstream mobile email readers that support
encryption?  Or webmail interfaces?  I seem to remember a recent announcement
that Gmail will soon be supported plugins that could be used to read and send
GPG/PGP encrypted messages.

An encrypted mailing list won't help you much regardless of the compromised
nature of your device if you can't even read the encrypted messages. ;)

-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 assumes an open membership policy.  Wouldn't much of this be mitigated
with a closed subscription policy?  I agree that the security of an encrypted
remailer such as we're discussing is only as secure as its recipients.  Yet
there still may be value in encrypting the communication channels into and out
of Mailman, even if that can be compromised at the end-points.

Does that make it worth it to add as a supported feature in the core?  It
depends.  What I would be very interested in -at least as a first step- are
ways to enable experimentation into such features by the addition of hooks and
APIs that allow third-party plugins that could support this feature.
Presumably such plugins would have utility for other use cases too.

>I can sadly report that the problem is getting worse and will continue
>to get worse, because (a) all of the various factors contributing to it
>are also getting worse and (b) there are no reasons for anyone to
>significantly invest in making it better.

(b) is not necessarily true.  There is lots of work going on to provide secure
base platforms on which to implement IoT devices.  Since that's mostly off
topic for this list, I'll avoid plugging technologies here, but if you know me
and my $dayjob, you can probably guess.  Feel free to email me off-list if you
want more information.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 and password everytime.

If you're only pulling from the GitLab git repo, there shouldn't be any
difference in content.

-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 project (in the interest of
>minimizing the motion of the target platform for the intern; that's
>also why I specify OpenSSL[1] for algorithm support).

Fair enough! :)

-Barry


pgpkjCABTWsdd.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 3.1
will -and current core git HEAD does- officially support 3.6.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 [-0-9a-z!#$%&'*+./=?@_`{}~].
>
>Since list names form parts of a URI, both in Postorius/HyperKitty and
>in the Core's REST API, it is clear that characters that will cause
>problems there should not be allowed. These include [#%&/?] and maybe
>others.

I suppose if we did continue to allow them, they would have to be escaped in
the URL.  I'm not sure how much that helps, or even whether it should be part
of our decision to allow them or not.

>Additionally, I don't think we want @ in an email address local
>part and + and = might cause problems with VERP which whittles it down
>to [-0-9a-z!$'*._`{}~], but I'm thinking of being even more conservative
>and going with just [-0-9a-z._].

I think it's entirely reasonable for Mailman to narrow the list of allowable
characters in the local part of list names.  We already make some opinionated
decisions about allowable email addresses; for example, we support
case-preserving, case-insensitive addresses so we treat b...@example.com and
b...@example.com as identical.

I'm amenable to the conservative set you propose (obviously, case
insensitive), although I have some concerns about how dots in the local part
would interfere with any List-ID operations.  E.g. foo@example.com becomes
List-ID: foo.bar.example.com.  As an identifier with comparison rules
according to RFC 2919 I think it's fine (it just has to be unique).  I'm not
sure whether in practice it would cause problems with the core.

The other question is whether we're unfairly closing the door on i18n list
names.  OTOH, we haven't yet had any requests for that afaict.

>I don't intend to change the email address validation except maybe to
>remove @, but the code is such that an address with multiple @ won't
>validate anyway.
>
>I'd like feedback on this. What are your thoughts on what characters
>should be allowed in list names?

Certainly some narrowing is appropriate.  We could just clamp it down as you
suggest, understanding that there may already be lists in existence that use
the more liberal character set, and acknowledging that we may want to relax
the set based on future bug reports.

What about this: come up with an absolute black list set, e.g. the ones that
will break Mailman.  Come up with a second set of discouraged but allowed
characters, and a third set which is the narrow list you propose.  Then make
the allowable set configurable, except that the black list characters are
always disallowed.  Now, that might be too complicated, so I'm also fine with
making it narrow now, and letting the set relax based on user feedback.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 think it's related to the database rollback.

Oh that's scary then!  I'll see if I can track someone at Gitlab down.

-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 3 weeks ago, but GitLab gives me a 404 and says there is no
>issue #310.

I'm not positive, but I have a theory.  GL says there are only 309 issues of
both closed and open state on the mailman project.  It's possible that this
one got caught up in their database incident:

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

and the email was queued up before then, since it's date of 09-Feb-2017 is
well after the incident was resolved.  It's known that about 6 hours of
issues, MRs, comments, etc. were irretrievably lost.

I did move an issue from mailman to postorius, but I believe that what happens
in that case is that a new issue is created in the target project (with
duplicate contents but a different issue number in sequence with the target),
while the source project's issue just gets closed.  I can't find that one
right now to confirm.

Anyway, Aurelien would probably need to say whether his issue falls within the
timeline of the GL database snafu or not.  I think there's no option but to
try to re-submit the issue if that's the case.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Development Enviromnent setup

[Barry Warsaw]

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 returned me with this (error)[
>http://pastebin.com/wLzDQwAu], Kindly help.

That makes me think that your Python installation is broken.  Can you tell
us more about what OS you're on, what version of Python you're using, and how
Python was built/installed on it?

FWIW, I tried this on Ubuntu 17.04 (devel) and it works fine.  I build my venv
a little differently, but that shouldn't matter:

$ python3 -m venv /tmp/mm3
$ source /tmp/mm3/bin/activate
$ python setup.py develop
$ mailman info -v


I'll also mention that very often I don't create a separate venv, but just use
the ones that tox builds, since I almost always have them around by running
the test suite.  If you want to build those without running the tests, you can
do something like this:

$ tox -e py35-nocov --notest -r
$ .tox/py35-nocov/bin/mailman info -v

You don't need to activate the venv to use it.

All that said, if you can't import _sqlite3, then your Python installation is
messed up.  That's a stdlib module so it should always be around.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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
--- a/src/mailman/core/runner.py
+++ b/src/mailman/core/runner.py
@@ -92,23 +92,24 @@ class Runner:
 signal.SIGINT: 'SIGINT',
 signal.SIGUSR1: 'SIGUSR1',
 }.get(signum, signum)
-if signum in (signal.SIGTERM, signal.SIGINT, signal.SIGUSR1):
+if signum == signal.SIGHUP:
+reopen()
+rlog.info('%s runner caught SIGHUP.  Reopening logs.', self.name)
+elif signum in (signal.SIGTERM, signal.SIGINT, signal.SIGUSR1):
 self.stop()
 self.status = signum
 rlog.info('%s runner caught %s.  Stopping.', self.name, signame)
-elif signum == signal.SIGHUP:
-reopen()
-rlog.info('%s runner caught SIGHUP.  Reopening logs.', self.name)
-# As of Python 3.5, PEP 475 gets in our way.  Runners with long
-# time.sleep()'s in their _snooze() method (e.g. the retry runner) will
-# have their system call implemented time.sleep() automatically retried
-# at the C layer.  The only reliable way to prevent this is to raise an
-# exception in the signal handler.  The standard run() method
-# automatically suppresses this exception, meaning, it's caught and
-# ignored, but effectively breaks the run() loop, which is just what we
-# want.  Runners which implement their own run() method must be
-# prepared to catch RunnerInterrupts, usually also ignoring them.
-raise RunnerInterrupt
+# As of Python 3.5, PEP 475 gets in our way.  Runners with long
+# time.sleep()'s in their _snooze() method (e.g. the retry runner)
+# will have their system call implemented time.sleep()
+# automatically retried at the C layer.  The only reliable way to
+# prevent this is to raise an exception in the signal handler.  The
+# standard run() method automatically suppresses this exception,
+# meaning, it's caught and ignored, but effectively breaks the
+# run() loop, which is just what we want.  Runners which implement
+# their own run() method must be prepared to catch
+# RunnerInterrupts, usually also ignoring them.
+raise RunnerInterrupt
 
 def set_signals(self):
 """See `IRunner`."""
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman 3 Dockerfile

[Barry Warsaw]

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 technology to use (e.g. Docker, Salt, Chef, Juju, etc.)  other than it
should be relatively easy to use on a wide variety of *nix platforms.  It
doesn't need to handle anything more than the simple common case of deploying
it all to the same server.  That's not to say that we can't point to lots of
good alternatives, and even distro packages once they're available.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 progress is at 98%, so we
>hope it will be ready in the coming days. Great!

I should point out this this milestone technically only describes Core.  A
potentially more comprehensive overview for the entire suite is at:

https://gitlab.com/groups/mailman/milestones/31?title=3.1

but TBH, I'm not sure whether Postorius and HyperKitty are as slavishly
focused on milestoning as I am for Core. ;)

>Regarding this, when the new 3.1 version is finished, will it be in a 'Beta'
>phase, or directly a public release?

Beta 2 of Core is already available on PyPI:

https://pypi.python.org/pypi/mailman/3.1.0b2

>In the case of being a Beta release, do you know an estimate time of when it
>will became fully released?

The last major feature for 3.1 Core is done (DMARC mitigation) so we just have
a few more minor issues to pick off.  Mark Sapiro is already running all the
git HEADs on lists.mailman3.org so we're essentially testing integration in
production already.  We need to concentrate on finishing Postorius and
HyperKitty (and mailmanclient, but that should be easy).  It doesn't look like
a ton of work, but it probably could use some well-placed help here and there.

I can't give you an ETA, but once Core is at 100% milestone, I'll release it
as an RC, and then jump over to the other projects to help.  I do think we're
close enough for folks to start using it in anger, and more importantly,
providing feedback, bugs, and code.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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.  I'm not sure how
>Mailman 2 was translated, but I guess most of the translators did it
>offline. You can download translation files from pootle and later upload
>them. So anyone that doesn't want to translate in the browser, can still do
>it offline.

Since gettext will be the interchange format, it will probably not be that
difficult to switch to a different service if we ever find we need to.

I appreciate your feedback on Zanata, and honestly we just need an i18n
champion to make it happen.  My apologies for such a long delay in responding
here, but Simon, if you're still willing to take the lead on i18n, I will be
happy to defer to your preferences.

>So If you give me the ok, I write the gnu pootle maintainers and ask
>them to create three projects for us.

+1 - if you're still willing, let's do this.  Core is very nearly ready to
start rc'ing for 3.1 so I think this is a great time to being building the
infrastructure for i18n.

>I guess we could add links in postorius and hyperkitty that request
>assistance with translation.

+1

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Contributing to Mailman Core

[Barry Warsaw]

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 merge requests to postorius and read the documentation of maiman
>along with videos on mailman architecture by barry warshaw.

Hi Nikhil; apologies for the delayed response.  It seems that with travel and
holidays, this message got buried in my inbox.

I see that you have some interest in Core issue #300.  Have you spent time
since then looking at how REST works in Core?  Do you have any additional
questions?  We're winding down development on 3.1 so this would be targeted
for 3.2.  We can discuss further on the specific issue, but if you have any
general questions, this is the place to ask!

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Aspiring for GSoC

[Barry Warsaw]

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 contributing. I know some web-development, Python and of course
>Django. And yeah! this is my first time with open-source contributions, So I
>would be obliged to get your help.

Welcome Sayak!

It's true, we haven't yet decided if we're going to participate in GSoC this
year, but we of course still would still welcome your contributions.  If
you're into web development, both Postorius and HyperKitty are great places to
start.  There's no web front-end work in the Core, but there's still
interesting things to do there.  I'm hoping that we're winding down toward a
3.1 release now though.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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


pgpBE38rGL6RE.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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


pgpLhknRAsbWa.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Mailman 3.1 beta coming soon

[Barry Warsaw]

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=opened=%E2%9C%93_title=3.1

and merge requests:

https://gitlab.com/groups/mailman/merge_requests?scope=all=opened=%E2%9C%93_title=3.1

Except that HyperKitty isn't on this list.

Please do test whatever you can and let us know how it goes.

Cheers,
-Barry


pgpdKRaVtw1wf.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] PGP support for MM3

[Barry Warsaw]

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
list-specific key management so that you can encrypt a message to a mailing
list.  Then users/addresses would each also have key management.  Those touch
the database layer.  There will probably be branches that touch the REST API,
and handler/rules, etc.  Then there are likely changes to Postorius, possibly
HyperKitty, etc.

>Encrypted mailing for groups of people is still a mess in 2016:
>
>*  Either the group is relatively static or you never encrypt the mail
>  for all people.
>*  All members need to know each other. And you need the keys of all
>  the other members.
>
>So far for the motivation. Below there are some initial thoughts:
>
>**Treat mail differently based on their signing status:**
>
>1. Whether it has a signature or not.
>2. Whether the signature is valid or not.
>3. Whether the signing key matches the key of the list member.
> 
>**Treat mail differently based on their encryption status**
>
>Whether it is encrypted or not.

You could certainly do these things.  Once the basic key management
infrastructure is in place, you could fairly easily add various rules and
handlers to effect some of these features.  E.g. a rule could say "if this
message does not have a valid signature, discard it".  That could be useful
even without full encryption.  For outgoing encryption, you'd need a pre-MTA
handler if you wanted to do personalization, e.g. encrypt the message to each
user's registered key.

>**Other opportunities**
>
>1. A public key per list.
>2. Signing of outgoing mails with that list key.
>3. Encryption of outgoing mails with that list key.

#2 and #3 could be done with list-wide handlers, since they aren't
personalized.

>4. Send a mail with the lists public key on request.

Fairly easy to add a command to do this.

>Which one of these points a worth an implementation?

All?  None?  Some?  :)

It really kind of depends on what people want.  At a minimum, I would really
like the option of running a mailing list which requires valid signatures for
posting, to avoid blindly trusting the sender headers.  That still requires
user-based key management, so perhaps that's a good place to start.

Cheers,
-Barry


pgpzkWqFVWgXk.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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, probably in (a) venv(s), and make a source
>tarball from that, venvs and all.  Something like a top-level setup.py
>to install it all in $prefix.
>
>Folks who don't want that (distros, seasoned admins) can probably
>handle git.  Probably... ;-)  And following readthedocs for config.

I think I missed a reference to Simon's script, but I'd be interested in that
approach too.  At this point it sounds like we shouldn't fixate on a single
deployment mechanism; we can provide some official containers, help distro
packagers, and above all, have really good documentation.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 like to get Mailman 3.1
out in December.  I'm going to be pretty brutal about triaging Core bugs and
merge requests to get it down to a reasonable number, and I'd like to try to
do a beta release in a couple of weeks.

How do the other subprojects look for a December release?

This is a good link to track the project-wide milestone:

https://gitlab.com/groups/mailman/milestones/31?title=3.1

One problem is that it doesn't include HK, so we need to figure that out.  And
we need to figure out whether we want to continue to support the bundler or
use some other container-based release mechanism (I am going to continue to
play with building a Snap for the bits and pieces).

Another reason to do the 3.1 release: I want to retire the 3.0.x branch.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 crippled (can't even set tags).

Thanks Steve, great idea.  Thanks Mark for adding back Simon.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MM3 DMARC mitigations

[Barry Warsaw]

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
>authenticated direct mail.  This is a mailing list which re-sends
>your mail after processing, and therefore you are not allowed to
>post according to your email provider's policy.  Please repost
>from an address which allows you to post to full service mailing
>lists.
>
>Note: A few large providers claim to permit posting to mailing
>lists, but publish "p=reject" anyway.  They privately acknowledge
>doing so to protect users from spammers and phishers who have
>stolen millions of address books and other private information of
>users from them.

With some verbiage massaging perhaps, I am supportive of a "hammer" option
such as this.  Maybe we can't enable it by default, but I don't think it's
unreasonable for site/list admins to be able to be more proactive in their
rejection of such messages.  It will probably make no difference, but if we
can inform users as to the real culprits in this mess, they can either
complain to their ISPs or vote with their feet and find a new provider.  That
won't happen if they continue to blame the list software or site.

(If we're serious about this, we should likely have a locked down wiki page
with more detail, linked to from the default p=reject rejection message.)

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 for the long delay in responding, and in any
delays in reviewing your work on core.  Like others, it was a stressful
(northern hemisphere) summer for me and after my travel I got quite
backlogged.  Work and family come first of course.

But I am actively working now to reduce the core backlog.  I am working
through merge requests now, but it's difficult to get through more than one in
a sitting.  I think there are some GitLab workflow issues that slow me down,
but also, most branches require fairly deep thinking, testing, and review.
Still, that doesn't help you when you're frustrated by the progress.

I hope you won't leave us in anger just yet though.  Patience does win
eventually, and we do value your contributions.

Thanks also to Terri and Steve for their thoughtful insights on this thread.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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
>development environment.
>
>I'll create an issue and a MR to fix it, but probably not until tomorrow
>evening or Thurs.

Cool, no worries.  My huge unsub-workflow branch is nearly ready to land,
which will remove the bottleneck on core.

One thing to keep in mind though is that not all attributes of the domain
resource are writable.  `description` should be of course, and if you look in
the model, domains also have an `owners` attribute that's not currently
included in the GET.  If it were, that should be writable too, as well as your
new `alias_domain` attribute.

But `mail_host` should be read-only.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 if I stash my changes and
>revert to the branch head, edits fail in the same way.

Hi Mark.

The way Falcon works is that you need an on_() method for every HTTP
METHOD that a resource implements.  If you look at the ADomain class (or the
_DomainBase base class), it only implements an on_get() and an on_delete(),
but no on_put() or on_patch().  So when you try to invoke PUT or PATCH on a
domain resource, you get a 405, i.e. Method Not Allowed.

And afaict, your MR doesn't an on_patch().

It's a bit more work to implement PUT and PATCH, so not every resource
currently supports it.  There are several examples in the code though, and
often on_put() and on_patch() differ only in the set of required attributes.
By definition, PUT requires a complete resource and PATCH allows for partial
resources.  Take a look at ListArchivers in rest/lists.py for an example.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Sequence of steps?

[Barry Warsaw]

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')
>GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index('Hold'), 'MimeDel')

Anybody looking for something fun to do in MM3 might consider how to surface
the creation and shuffling of rule chains (moderation) and pipeline handlers
(munging) through REST so Postorius could present an easy configuration screen
for list managers.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 more than once for an
email/mailing list combination.  It's possible to spam every list at least
once though, and I'm not sure what you could do about that.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 some of the sizing and colors. The theme also is no more
>"responsive" than list.org on small screens.
>
>If there are no objections, I will install the new theme on
>wiki.list.org under a new name so that users can configure their
>preferences and provide feedback. (Or I can move my playground out
>somewhere publicly accessible.)

I really appreciate you working on this Jim.  Is there a way to preview the
new theme?  When I go to wiki.list.org and look at my preferences, I'm using
the 'mailman' theme.  There are other choices, but it's not clear to me if any
of those are your new theme.

I'm assuming you don't need another machine or domain to demo the theme.  If
you do, I can easily set something up on the mailman3.org domain (which I
own), but it's a little harder to add to the list.org domain (which JV owns).

In any case, I trust you to JDFI when you feel the time is right!

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Thinking about Gmane

[Barry Warsaw]

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 to Mailman, providing free archives
for open source mailing lists of all kind.  My favorite thing about it is the
NNTP interface to mailing list archives.  Remember Usenet?  It's really NNTP
underneath and there are some excellent news readers that let you have very
good access to years of older posts.  I am a Claw-Mail user and it provides a
fairly seamless integration of regular email and news (e.g. Gmane over NNTP).

The powerful thing for me is that for mailing lists I care about, but don't
want to be subscribed to, I can just catch up every so often on the Gmane
newsgroup.  I can even post from the Gmane mirror, and I don't have to keep
personal archives of any mirrored public mailing list.  All the Mailman lists
are available on Gmane.

But Lars has apparently burned out and is considering shuddering Gmane.  This
would be a huge loss for the FLOSS community IMHO, and I hope the outpouring
of goodwill on his blog posts (along with any donations of time, resources,
and money) will keep Gmane alive.  It seems like all might not be lost:

https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502

Getting back to Mailman, I've long wanted a built-in NNTP interface to mailing
list archives.  Long ago I prototyped a bridge from Mailman 2 to NNTP via
Twisted.  It wasn't that much work, but of course it was only a prototype.
With Mailman 3's architecture, I think it would be a fairly straightforward
project, so I'm here to hopefully excite and challenge one of *you* to think
about doing it. :)

Of course, it wouldn't be Gmane, and I'm not sure we need exactly that.
First, it wouldn't be federated across the wide FLOSS world, but it would
still be extremely useful.  Second, we have so much goodness in HyperKitty
that the web side of Gmane wouldn't be as important for us.  Still, the
ability to have direct NNTP access to mailing list archives built into Mailman
3 would be really darn cool, IMHO.

As an aside, Lars would make the whole of the Gmane spool available, and it
might be really cool to see how well HK can consume and vend it.  Given that
Lars seems to say that it's more likely that the NNTP/SMTP bridge will
survive, but not the web ui.  Wouldn't it be cool if HK could serve as a
modern version of a web ui to the Gmane treasure trove?

Anyway, I'm putting this out there - hopefully some one of you might be
willing and able to take it up.

Cheers,
-Barry


pgp4qgwdJYhRo.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 Core issues and I
think you have a plan for going forward.  There's still a little sticky bit
about how to handle the database migration, but we should be able to figure
that out.

Keep up the great work!

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 take a look.

>Terri was working on this one, it's not critical but nice to have for
>usability
>https://gitlab.com/mailman/postorius/merge_requests/159

ack.

>I have a mr pending for mailmanclient that should be included in the
>next release
>https://gitlab.com/mailman/mailmanclient/merge_requests/10

I've added a 3.1 milestone to mailmanclient and assigned this one to it.

>Postorius has a number of merge requests open. I'm not sure which of
>them should be merged before the next release

Florian, do you have time in the next few weeks to do some Postorius triaging?

>Does your template branch in core need any immediate modifications to
>mailmanclient and/or postorius?

It shouldn't, at least for API 3.0.  All the new template APIs are exposed on
v3.1 only, and when using the v3.0 API, they should map the old attribute
names to the new mechanisms, so it should all be transparent.  Modulo bugs of
course. ;)

I think it would be nice if mailmanclient and/or Postorius used the v3.1 API
to get the full power of the templates branch, but it's probably not critical
for the current release.  Flo and I did talk about adding a cli that Postorius
could call when installing it next to a v3.1 Core, e.g. to install some
default templates for a cohabitating Postorius, but on further thought, it
would be just as easy to write a bit of Python code to install those
templates.  Note though that someone would have to write the templates and
ship them with Postorius, but they could be done using file: URLs into the
Postorius install directory.  That would be a fun project for someone to
tackle, and I'd be happy to answer any questions that come up.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Countdown to the 3.1 release

[Barry Warsaw]

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 left:

https://gitlab.com/mailman/mailman/milestones/2

I think these are important enough to fix for 3.1 and I welcome merge requests
while the other three branches are ongoing.

Please take a look at any other bugs not assigned to milestone 3.1 and let me
know if you think any are serious enough to block the 3.1 release.  I'll say
in advance that I'm going to be brutal in assessing them, because 3.1 really
needs to be released soon!

Note too that there may be blockers for Postorius, Hyperkitty, and
mailman.client, but I haven't looked at those subprojects yet.  How close are
they to being release ready?

Cheers,
-Barry


pgpnuaSxAQotj.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Templates branch for Mailman 3.1

[Barry Warsaw]

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 feature but there's no MR for that yet.

The templates feature is very nearly done, so I think now is a good time to
ask for testing, feedback, and review.  This is a generalization of the
welcome_message_uri feature in MM3.0 where you could specify e.g. the welcome
message as a URL to download and cache when necessary.  This is important
because Core doesn't know whether there is even a web ui (e.g. Postorius)
involved, or where things like clickable links to unsubscribe would be.  Sites
also want to customize footers to include information like codes of conduct,
etc.

Now (or when this branch lands), you will be able to specify a URL to retrieve
any template that Mailman uses internally, whether they are confirmation
messages, bounce probes, welcome and goodbye messages, etc.  These can be
templates for administrators, users, and members.

Because I'm hoping to get some reviews, I'll point you at the documentation
for more details:

https://gitlab.com/warsaw/mailman/blob/templates/src/mailman/rest/docs/templates.rst

The branch did end up being much bigger and tentacled than I expected, but
it's all hanging together pretty well now, and all the tests pass.  There's
still a small number of to-dos, but some of them will get punted, and the
others won't have a major effect on the overall use and visibility of the
feature.

https://gitlab.com/warsaw/mailman/blob/templates/TODO.rst

Note also that if you interact with the REST API v3.0, nothing changes
externally, but the old IMailingList attributes are mapped onto the new
templates mechanism.  API v3.1 is where you see all the actual new feature
end-points exposed.  Of course, any MM2 list converted to MM3.1 will use the
new templates stuff too.

Feedback very much welcome, either here or on the MR:

https://gitlab.com/mailman/mailman/merge_requests/170

I'd like to land this some time in the next week or so.  Then I'll work on the
other two big branches and start to release some betas.

Cheers,
-Barry


pgpqDBjSzCuui.pgp
Description: OpenPGP digital signature
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 category named db.
>
>It seems that the database layer hasn't got initialized by the time
>this event was fired. Is there any way of fixing this or any other way
>using which I can populate the database when mailman starts?

That's right.

Getting the initialization sequence correct is pretty tricky, and it's true
that the configuration subsystem is initialized before the database connection
is created.  If you think about it, it has to be this way since there are
settings in the config files that control how the database is set up.

What I think this means for you is that you can't use the
ConfigurationUpdatedEvent to set up your stylets until the database is set
up.  Unfortunately, right now there aren't any events fired when
initialization is completely, but just the other day Aurelien and I sketched
out an event-based plugin mechanism for better HK integration, and one of the
things I realized we needed was some additional event notification for the
various stages of initialization.

Right now, your best hope is to use the [mailman]post_hook which gets run
during initialize_3() and is guaranteed to be run after both the configuration
subsystem and the database connection is set up.  Eventually the pre_hook and
post_hook will be deprecated because they aren't really set up well for
plugins, and we'll have events for the various phases of initialization, so
you could register a handler for one of those events.

If you decide to keep the ConfigurationUpdatedEvent handler (e.g. because you
want to do other stylet things if the configuration changes once the system is
up and running), just check for the existence of the config.db attribute, or
catch the AttributeError.  If the attribute is missing, you know the
ConfigurationUpdatedEvent is too early for your purposes.

Hope that helps.
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New Interface

[Barry Warsaw]

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 the stylets would be stored in the
existing database, and we'd use NULLs to indicate that a particular style
variable is not set in the stylet.  Thus, when that stylet is applied, it
would just skip over that attribute.

> > 3: If I go for style composabiltiy as described by you then how would
> > I represent that idea in REST and Postorius?  
>
>Basically the same way.

Just sketching things out (IANAWD :)

You'd be able to create new stylets, giving them a name.  For each variable in
a stylet you'd be able to say whether the variable is enabled or not.  If it's
not, then the stylet won't change that variable.  If it is enabled then it can
be set in that stylet.

You probably want to be able to clone and delete stylets too.

You'd then have a second interface which would be for composability.  I think
you should be able to select named stylets and include them in your style
(which would also be named).  You'd be able to reorder the stylets in a style,
add and remove them from the stack, etc.

Bonus would be to keep track of which styles and/or stylets apply to a
particular list so you could do interesting things like:

* find out which lists use(d) a particular style or stylet
* change an existing mailing list by changing a style or stylet (which differs
  from how things work today.

Of course styles and stylets would be exposed in REST, and we'd have to
discuss where those resources live inside the tree.  But we can do that later,
once/if the basic model sketched out here and in Steve's response ends up
making sense.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New Interface

[Barry Warsaw]

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 can mark that as a tech-debt
issue and address it outside of the context of your work.

>From core's point of view this idea seems to be fine but I am unable to think
>of any way of representing this idea in Postorius(since new styles would be
>created there)?

Yes, the ui issues are challenging. ;)  I think it would be fairly easy to
represent in REST.

>Earlier while discussing we decided to make style composable in terms of
>other styles(inheritance and fallback mechanism). For example, if a user
>wants to modify only the the autoresponses attributes of Style1, then, he may
>create a child style of Style1 and change only the attributes related to the
>autoresponses and rest of the attributes will take their values from the
>parent style(Style1).  Also is there any advantage of making styles
>composable in terms of stylets?

It allows the admin to only be concerned with the attributes defined in the
stylet.  It can be fairly difficult otherwise to figure out what a specific
stylet modifies.

>The new interface will contain only styleable attributes and not any
>immutable attributes like created_at. All the immutable attributes
>will reside in the existing 'IMailingList' interface.

Cool.

>> Then it may be possible to do a lot of cool things on stylets, such as
>> impose permissions on changing or using one; recording the stylets used
>> with a particular mailing list, so if you change the stylet, the mailing
>> list automatically changes, etc.
>
>How will be the permissions enforced without authorization system?

Postorius would enforce it for now.  When we have the authproxy, it will do it
for scripts.

>> The only other comment on the above paragraph has to do with requiring a
>> style to contain *all* the attributes.  How would you handle the
>> composability in that case?
>
>All attributes will be required only in case the style doesn't inherit
>from any other base style. In case the style inherits from some other
>base style then the dictionary(argument to the constructor) will
>contain only those attributes which the user wants to change and rest
>of the attributes would be taken from the parent style.
>
>Also could you suggest some default value(such as 'DEFER') for
>styleable attributes that would trigger the fall back mechanism to
>take values from the parent style.

That's tricky.  If we weren't interfacing to a database (i.e. in pure Python),
we'd have a marker object, e.g. `INHERIT = object()` but we have to worry
about database column types.  I'm not sure what the right thing to do there
is.

-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Postorius issue tracker labels

[Barry Warsaw]

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 use the term 'mailman'
for the whole umbrella project.  'wait-for-core' is a little better but it
doesn't accurately describe blockers on mailman.client.  'wait-for-api'?  I'm
also okay with leaving it as it us until/unless we figure out something
better.

-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New Interface

[Barry Warsaw]

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 like the mixin structure, so for MM3, I collapsed all the
style attributes into a single IMailingList interface.

As you've noticed, some of the attributes in the model class aren't described
in the interface.  Those are mostly the legacy attributes which should
eventually go away (because they are unused or represent features we don't
want to support), or converted to better database types (see the PickleType
for accept_these_nonmembers).  It's gotten a lot better, but there are still
some holdovers from the old MM2.1 code, so more opportunities to clean up and
modernize.

I've always wanted styles to be composable, by which I mean that a style can
describe just a partial set of attributes.  For now I'll call these stylets.
One stylet might define how autoresponses work, while another might describe
how digests work.  In a sense, this is analogous to how the composition was
broken down in MM2.1, but without all the ugly mixin stuff.

The current IStyles support this, but of course they are only applied to
mailing lists when they are created, and changing a style does not change any
list to which the style was applied.

On Jun 01, 2016, at 11:47 PM, Harshit Bansal wrote:

>I am thinking of adding a new interface named 'IStyleable' to the
>mailman core. All the styleable attributes from the current
>'IMailingList' interface will be moved to this new interface. The
>current 'IMailingList' interface does not provide documentation for
>all the styleable attributes. This new interface will contain all
>styleable interfaces arranged in an orderly way with proper
>documentation. This new interface then can be extended by the existing
>'IMailingList' interface and the new 'IStyle' interface that I am
>writing.

I think this makes sense.  You're refactoring out the interface for the
attributes of a mailing list apart from the functionality that a list
provides.  There may be some attributes which aren't style related,
e.g. created_at, and perhaps some that shouldn't get refactored because they
identify the list (e.g. list_name and list_id), but we can discuss that.

Once you have that refactored, then I think you need a way to say "this stylet
sets attributes A, B, and C, but doesn't touch X, Y, and Z".   That gives you
back the composability without having to worry about partial interfaces;
i.e. all IStylet (actual name TBD) interfaces *can* change any style
attribute, but it's okay if they change only a subset.

Then it may be possible to do a lot of cool things on stylets, such as impose
permissions on changing or using one; recording the stylets used with a
particular mailing list, so if you change the stylet, the mailing list
automatically changes, etc.

>Why I felt the need of a new interface?  For constructing a new style I am
>taking a dictionary as an input to the constructor which is supposed to
>contain all the necessary styleable attributes and their corresponding values
>as key value pairs and to check whether the dictionary contains all the
>styleable attributes or not I will need to have a list of all the styleable
>attributes and that can be done very easily if I have an interface
>containning all the styleable attributes. I know there are other methods of
>getting a list of all the attributes but they are neither pythonic nor stable
>as all of them depend on python internals which are liable to change with the
>version of python.

Let me see if I understand: you want to query the IStyleable interface to know
what attributes are allowed in a style.  It makes sense in that case to use a
separate interface just for that purpose, without cluttering it up with all
the other interface bits specifically for mailing list operation
(e.g. get_roster(), subscribe(), and immutable attributes like created_at and
list_id).

The only other comment on the above paragraph has to do with requiring a style
to contain *all* the attributes.  How would you handle the composability in
that case?

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Code Duplicacy

[Barry Warsaw]

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 src/interfaces/styles.py in IStyle interface. For example,
>
>advertised = Attribute(
>"""Advertise this mailing list when people ask for an overview of the
>available mailing lists.""")
>
>This piece of code is now present in both src/interfaces/mailinglist.py and
>src/interfaces/styles.py.

This is in some respects a quirk held over from Mailman 2.  The MailList class
is a mixin of several other classes which hold both settings and functionality
(methods).  During the port to Mailman 3, I essentially collapsed all of that
into a single MailingList class.

Styles are a separate thing bolted onto the side of that, which is why they're
implemented as applying to a mailing list only at creation time.  You're right
that a style has many of those attributes, but also keep in mind that a style
can have a *subset* of attributes, as you should be able to see in the
existing style classes.  Styles are meant to be composable, so for example,
you could define an "announce-only" style that only modifies some of the
related attributes, but allows others to be defined in other style classes.

MailingList instances OTOH contain all the style related attributes.

>Is there any way to correct it or is it fine?  One approach that I am able to
>think of is to write one seperate interface containning all the styleable
>attributes and implement that interface both in src/model/mailinglist.py and
>src/model/styles.py.

I'm not sure.  Given that styles can be partial collections of attributes,
maybe it doesn't make sense to name them all in the IStyle interface.  Leaving
them only in the IMailingList doesn't have much of a functional effect; in
this case the interface isn't much more than documentation and marker (it
declares the @implementor class as being of that interface so it's easier to
look up).

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 offer the same languages for core and
>postorius and I'm not sure how we would pass the languages to core...

Probably Accept-Language could be used to specify that, but I (think I) agree
it's not the right approach.  My only hesitation is to remember that Postorius
isn't technically the only web front-end that could be connected to the core.
If some homegrown ui also wanted translations, it's not clear how much they
could leverage of existing work if all the translations lived in Postorius.

>I propose core to return an error code with each request. That way
>postorius can add strings for all the errors that it cares about and
>translate them accordingly. This would require an api change. Since 3.1
>would change the api anyway, it would be nice to include the changes there.

If we're going to return an application-specific error code (in addition to
the HTTP response code we already return), then I think it means we'll be
returning a JSON structure even on error conditions.  Right now, JSON is only
returned on success, and strings are returned on errors.

If we say in API 3.1 that JSON is always returned, then we have some
additional options.  What makes the most sense to me would be to always return
a dictionary with some well-defined keys.  That at least gives us a chance to
evolve the API probably without having to rev the API version in the future.

One problem with returning Mailman-specific error codes is that we'll need *a
lot* of them.  Essentially one for every error condition in the REST API.
I've always found such arrangements a nightmare to maintain and debug.  Error
codes have no obvious meaning so the mapping of code to meaning always has to
be looked up.  We could segment the error space so that there's some semantic
equivalence (e.g. 01xx means a list-specific error, 02xx means a
membership-specific error, etc.) but there's always some twisting that goes on
the keep those up-to-date and meaningful within the semantics we give them.

And it's still not enough, because as you point out, there is always going to
be variable data that has to be associated with the error.  A good example is
when a mailing list is created within a nonexistent domain.  The error reason
is something like:

'Domain does not exist: example.net'

which gets interpolated on the server side.  So obviously an error code like
0135 won't help because you could only translate that to 'Domain does not
exist' without also knowing the name of the domain that failed.

So now we also have to include some variable data in the JSON response.  Which
leads me to think, why do we need error codes when we already have a format
perfectly suited to the cause, and which we already use internally for other
translatable contexts, i.e. PEP 292 strings ($-strings).

Thus, our error responses could be something like:

{
'reason': 'Domain does not exist: example.net',
'template': 'Domain does not exist: $domain',
'data': {
'domain': 'example.net',
},
}

'reason' would always be the interpolated English (i.e. source) string.
'template', and 'data' should be obvious.  We need a separate namespace for
the interpolation data.

A front-end could just use the English reason, or it could translate the
template and interpolate the data dictionary into it.

Making this change would be a lot of work, but it could be done in several
branches.

One branch would provide the infrastructure to return JSON error responses.
These would only be done for API 3.1, and possibly you'd also want to check
the Accept header to make sure the client is prepared to accept JSON.  Then
all of the error reporting call sites would have to be changed to pass in the
template and data dictionaries, with the helpers doing the interpolation for
'reason' and the setting up of the response correctly.  Then tests and
documentation. :)

If you like the general approach we can hash out implementation details.
Given however that Pycon is near and I *really* want to get 3.1 out during
Pycon and there are already at least two big features that still have to be
added (unsubscription workflow and template support), it might be better to
defer this to core 3.2 and API 3.2.  That way, we can get it right without
rushing it in.

Cheers,
-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 Zanata yet?  How would you
compare the two systems?

>The main question would be selfhosting vs using gnu's hosted version.

I'd really prefer not to self-host.  I don't think we're a big enough
organization to commit to long-term maintenance.  I'm not at all questioning
your eagerness, abilities, and availability, but life has a way of throwing
curve balls at us[*] and I worry about 5 years in the future if interests or
availability changes.  Also, I wonder if we wouldn't be giving up some
economies of scale by sharing translation infrastructure with other projects.

>If you want I can spin up an instance on my server and provide
>interested people credentials to play with. (existing demo instances
>don't allow adding/managing projects)

If the i18n community wants to play with a pootle, I think that's fine.  We
can certainly use it to compare against other services.

>From my perspective, I don't have too many requirements, other than that we
can upload .pot files and download .po files when it makes sense for the
project, which would be disconnected from the timeline for translators to
submit translations.  Right now for MM2.1, Mark has to request updates timed
to his releases, and I really want to avoid that.  IWBNI whatever system we
choose had nice git integration, but that's not required.

My only other requirement is that whatever we choose be comfortable enough
that translators *want* to use it.  As a pretty typical monolinguist, I'm
definitely not qualified to judge that.

Cheers,
-Barry

[*] Is that a euphemism that translates outside of North America? ;)
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

>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
>> https://translate.zanata.org/project/view/hyperkitty
>> 
>> I'm hesitating to ask people to translate because zanata is really slow
>> and I'm afraid of scaring people away from translating mailman in the
>> future :D
>> 
>> Anyhow, I'm writing to ask for your opinions.
>> What do you think about zanata? Maybe you can try translating a couple
>> of things and report how you feel about it.
>> 
>> I stumbled across a few other open source solutions:
>> https://translatewiki.net
>> http://pootle.locamotion.org/
>> https://demo.weblate.org/
>> 
>> This mediagoblin issue discussed some alternatives when they switched
>> away from transifex. https://issues.mediagoblin.org/ticket/913
>> 
>> There seems to be a pootle server run by gnu itself.
>> https://chapters.gnu.org/pootle/
>> 
>> What do you think?

>From a project standpoint, we have a few considerations.

We're a GNU project, so we have a hard requirement that any service we choose
must run on free software.

>From my own perspective, I'd like to separate out what we as project leaders
and developers care about from what translators care about.  Meaning, we
should be able to extract the pot file and templates and upload them whenever
it makes sense from a project standpoint.  Translators can do their job on
their own schedule and don't need to be tied directly to project milestones.
To the extent that we have to include any translation artifacts in the
software we release, we should be able to get a snapshot when needed and just
include it in our release.

Then all I care about is that translators are happy enough with the system
that they'll actively translate!  It does us no good if the service is too
painful for translators to use.  As a monolinguist, I don't really have any
insight into that. ;)

We need a Mailman 3 translation champion, someone who understand the technical
and more importantly, social issues involved, and can spend time and energy on
helping bring a good story to fruition.  I'm happy to give wide latitude to
the champion to help shape a solution that works for us.  Maybe that's you
Simon?

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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

In MM2 we had the advantage that the web ui and the core were tightly
integrated, but because they're separated in MM3, the core can't assume
anything about the web front-end.  At a high level, it will be possible to
define a custom template for all confirmation messages, and those templates
can be filled with whatever clickable confirmation link makes sense for
whatever web ui is in place.  I imagine that for a typical Postorius-fronted
installation, we'll have some standard templates and a simple config file that
will provide a minimal effort click-through-Postorius functionality.

>I don't see a reason why we should implement that in mailman, if it can
>easily be added in the front-end.

Right, the core will *not* provide such a clickable confirmation link.

>Doing this has one downside in my opinion. Storing the same addresses in
>several places (which isn't bad perse, as a matter of fact microservices
>encourage duplicating data and synchronizing it) would need
>synchronization. Ideally mailman would offer signals for various events that
>front-ends can hook in to. They would probably be similar to the hyperkitty
>archiver plugin I guess.

Yes.  While orthogonal to the templates work, the core has a fairly rich
ability to link internal events to external notifications.  We simply need to
define the API for calling back into Postorius (or whatever web front-end
needs notification), and then we can dispatch internal events to that API.
E.g. a webhook or similar.

Alternatively, Postorius can make queries of the core's REST API at whatever
decision point makes sense.

>Sorry but I have to disagree with that. Postorius _has_ to be able to send
>out mails.  In case any server errors occur, django tries to send out emails
>to administrators defined in the settings.

That's different though.  What I mean is that any list traffic, including to
list members, owners, and moderators, should only be sent by the core.  It's
different if a Django error occurs and it wants to send an email notification
to the Django administrator (although do also think about the Mailman site
owners).

>There is one more issue that needs to be discussed which is relevant to all
>templates: Translation.  Django has builtin methods to translate and through
>the browser's preferred language can choose one.  The core would require
>associating a language with each user in the settings.

We already do that.  Members, users, and addresses have preferences, and those
preferences have a preferred language.  When sending notifications, the core
will use the preferred language of the appropriate preference.  The core will
use gettext based translations, but when using a template, we have a mechanism
for looking up a template in a particular language.  If one is available,
we'll use that, if not we always fall back to the site language (which is
usually English) or the system language (i.e. shipped templates, always
English).

Whatever translation service we end up using should support translating both
gettext and templates, but ultimately it's up to the site administrator and
system administrators of whatever front-end is used, to provide the
appropriate translated templates.

>From a usability point of view I would like Postorius to be able to set all
>templates and not just link to files in mailman. There are a couple of
>businesses that manage thousands of lists and I guess they would appreciate
>it if list owners could do this without direct access to the mailman server.

The template system I'm working on does not require file system access to the
Mailman server machine.  It will work on any URL (my intention is to use
requests for the underlying fetch machinery, with a mailman: extension for
file system access for those sites that do want to use that).  The templates
don't even need to reside in Postorius.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 where addresses will be verified.  Are they
going to be via confirmations emailed by core or via Postorius?

I think the core has to support emailed confirmation messages because
Postorius is technically an optional component.  So if a site were to build
their own REST front-end, they'd at least want to allow the core to handle
email verifications without having to build that into their front-end.

That doesn't necessarily prevent Postorius from doing it, and when used with
Persona, we see how nicely that can work.  It's also of course possible that
any 3rd party front-end will have its own way of verifying email addresses.

The other thing to think about is that the core already must know how to talk
to the outgoing MTA, to provide proper reputation services, signing, etc.  I
don't know that we want to make site admins have to configure that in two
places, and we almost certainly don't want Postorius to send out emails
directly.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 user's un-verified address? This does not seem
>possible in REST at the moment (unless I missed it), and should be
>protected against multiple checks.

This is why POST on members (i.e. create a subscription) has a pre_verified
flag, which defaults to False.  The core already has a subscription workflow
to send the address a confirmation email if the subscribing address is not
already verified, and pre_verified is False.

(It will send a similar confirmation email if pre_confirmed is False and the
mailing list is set to confirm or confirm_then_moderate.)

By default, confirmation can only effectively happen by email reply, but the
intent is that you could modify the confirm.txt template[1] to include the
appropriate link back into Postorius which would effect the same verification
step as a mail-back.  This link would POST to /addresses//verify
to verify the user's email address.

Thinking about it the terms you describe above, I guess there's another
workflow that isn't directly covered.  When Postorius creates the user, an
address is also created and linked to the user, but it cannot be set as the
preferred address until it's verified.  I can see where you might want to send
the verification email at some point before a subscription event, so that the
linked address gets verified and thus could be set as their preferred
address.  If that's a use case you think we need, do file a bug.  I don't
think it would be too difficult to implement.

Cheers,
-Barry

[1] Or w.r.t. GL issue #112, set a 'confirm.txt' template URL.
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 a new
connection and a new transaction, I think you might have created a
subtransaction which didn't get flushed to the database.  It probably doesn't
have anything to do with the db backend specifically, but just how SA works.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 current approach I am taking towards committing transaction is first
>creating a connection object by calling config.db.engine.connect() . After
>that, I am creating a transaction object by calling connection.begin() .
>Finally after creating domain and address objects, I call
>transaction.commit(),which executes succesfully, but I am unable to see
>changes being reflected in the database.

Which database backend are you using, SQLite or PostgreSQL?

When you're checking the database, is this from a different process?   How are
you checking the database?  Can you give us the exact set of commands you're
using both to change things and to check things?  E.g. maybe paste a console
session so we can reproduce it.

`mailman shell` exposes some globals, such as commit(), abort(), the config
object, and the mailing list `m` object if you gave the -l option.  I don't
think you normally need to do the config.db.engine.connect() call or the
connection.begin() call, and I don't know whether those are create
subtransactions or otherwise interfering with your operations.

Cheers,
-Barry
___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

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

[Barry Warsaw]

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 changed?

The easy answer is that rosters (and the IRoster interface) predates
ISubscriptionService by quite a bit.  The latter was added primarily to
support REST APIs for member searchers.

The concept of a roster as a query is pretty fundamental, and the idea was
also that rosters should be composable.  I'm not keen on changing these
interfaces.

Cheers,
-Barry

___
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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9