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
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-defaultWhich 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