[Mailman-Developers] [Project Discussion] Approach for Implementing Admin Tasks

Barry Warsaw barry at list.org
Tue May 26 16:12:47 CEST 2015


On May 26, 2015, at 01:26 PM, Stephen J. Turnbull wrote:

>I really think we should reserve 3.1 for fixing major problems (and I expect
>to have a lot of user-noticable problems, starting with lots of Mailman 2
>functionality that went unimplemented for one reason or another).

+1.

I do intend to do a 3.0.1 of core at some point soonish to fix a few bugs.

Here's where we can start gathering high level tasks for 3.1:

http://wiki.list.org/DEV/Mailman%203.1

>I tend to sympathize with Bhavesh.  There are a bunch of things that
>really need help from core.  (Authn/z is the gaping wound: a *lot* of
>people have separate machines for mail and web, but as things stand
>that's not possible because Postorius has to live on the same host as
>core).

I'm not opposed to pulling things into the core where it makes sense.  I just
want a good rationale, a consistent design, and a logical organization of the
API resources.

> > Bhavesh, can you describe why a task model in the core is a better
> > way to go?
>
>Yes, please do: I'm not 100% sure I agree that it would be useful
>later in the series, but especially in cases where the conclusion is
>"let's not" it's best to get a pretty solid argument "for" on record.

There could be some good reasons to implement and expose the task model in the
core.  One of them might be to provide a better abstraction on top of the
currently disjoint implementation of held messages and subscription requests.
These currently have different types of ids/tokens and are held in different
tables.  There might be other benefits worth exploring.

I have some thoughts about how it might be best to implement something like
that in the core, but let's not go there yet.  If there's a really strong
reason to do it, I can outline my implementation thoughts.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150526/084321e3/attachment.sig>


More information about the Mailman-Developers mailing list