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
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?
On Mar 25, 2016, at 05:58 PM, Aditya Divekar wrote:
>> A perhaps more convincing example would be an extension to anonymous
>> lists with personal reply-to. This could be accomplished by creating
>> a mailbox at the list host, which would be associated with the user so
>> she can set options for it (eg, which address to forward to), but
>> should not have a display name associated with it, and certainly not
>> the user-level display name (which in organizational contexts --
>> including Python! -- is likely to be a real name).
>Actually, the code has already been merged for the above mentioned
>automatic fallback on the user display name. So I'm not really sure about
>the next step in this issue, and think that Barry would be better qualified
>to give an opinion here than me.
Two things to keep in mind. This comes into play for messages that Mailman
crafts out of whole cloth for notifying the user of something. It won't be
used in messages posted to the list.
Also, although currently there's no distinction, there *could* be a difference
between None and the empty string for display_name. The former could mean
On Do, Mär 31, 2016 at 07:17:50 +0530, Aditya Divekar wrote:
> I'm sorry for the misdirect. I'm myself a beginner here!
Absolutely no problem, every hint is welcome :-).
I'm also a beginner with mailman 3 and absolutely no python expert
:-(. To be honest it is not easy to understand the full procedure of
installation of all needed components for mm3, at least if you like to
install not the mailman_bundler package. There are so many sites with
documentation and it is not easy to find out what is the right one. A
step to step guide to install all components, which also beginners or
not python programmers do understand, would be great. Maybe there is
some kind of such a guide, but I haven't found it. And if it is not, I'd
like to help to create such a guide, but I'd need support from people
with mor knowledge of python and all the things which are needed.
> This issue on gitlab is probably the same as the one you are facing.
> The fix recommended is the installation of falcon 0.3.0.1 or 0.3
If I understand it correctly, I already have a newer version of falcon
root@mm3:/opt/mailman-bundler# find . -name *falcon*
But as said before, I'mno python expert...
Ciao and thanks again for your help,
On Do, Mär 31, 2016 at 06:39:14 +0530, Aditya Divekar wrote:
>Try removing the /mailman3 part from the URL. i.e. try accessing the URL -
Using this address opens the webinterface for hyperkitty and I could
browse mailinglist archives, e.g., but what I'd like to do is setup a
new domain for the new installation.
If I open the settings page directly
(http://192.168.122.147:8000/mailman3/settings/) I ge tno error, but
after entering a mail and web host and a description and send the
formular another error occures :-(.
Seems that something is not correctly installed or configured, but what
Ciao and tia,
As soon as the latest CI passes, I am going to merge a massive code clean up
branch to the core's master branch. This integrates flake8 (pyflakes + pep8)
static analysis, with a few local customizations.
One of the most important checks is a customization to enforce our GNU Mailman
import style rules, which are codified in the style guide:
This branch also updates that style guide.
This merge will cause some churn and if you have merge proposals currently in
the queue, it's very possible there will be conflicts. To the extent that you
can rebase and push updates, that would be appreciated, but I will not require
it as I continue to review outstanding merge proposals. I apologize for any
disruption, but with GSoC coming, I want to be sure that to the extent
possible, CI will early detect simple style guide violations. That way,
reviews can focus more on the actual interesting bits rather than the boring
This branch also bandaids over the problem with the newest Falcon by pinning
that package's version to < 1.0. Issue #20 will address a more long-term
fix. I plan on releasing core 3.0.3 very soon which will have this fix
There are a few other minor code modernizations, and a local implementation of
the idea expressed in this Python bug:
It's been quite the eye-opener to see all the little violations that have
crept into the code, but everything will be better now <wink>.
nitish salwan writes:
> I know that was late but I wanted to take part in GSOC. And now
> when the submission deadline is over,can I contribute in this
> project through GSOC or separate contribution.
You can certainly contribute at any time. About GSoC, if you
submitted a proposal, I'm not allowed to say until the official
I know that was late but I wanted to take part in GSOC. And now when the
submission deadline is over,can I contribute in this project through GSOC
or separate contribution?