Am 06.01.2015 um 13:48 schrieb Barry Warsaw:
On Jan 06, 2015, at 01:37 PM, Aurelien Bompard wrote:
I must also consider how much work it would be to just port HyperKitty
KittyStore to Python3. All things considered, it may very well be faster and
more reliable.
Of course, I encourage
I must also consider how much work it would be to just port HyperKitty
KittyStore to Python3.
All things considered, it may very well be faster and more reliable.
A.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
On Jan 06, 2015, at 01:37 PM, Aurelien Bompard wrote:
I must also consider how much work it would be to just port HyperKitty
KittyStore to Python3. All things considered, it may very well be faster and
more reliable.
Of course, I encourage any porting to Python 3 just on principle :) and
What if a site wanted to run them on different VMs for example?
Yeah, but certainly there should be a limit to that. What if a site wanted
to run each mailman runner on a different VM for example?
Oh well, I guess there's no other way. I hope it's not going to be a mess
to configure, I'd like
On Jan 06, 2015, at 02:55 PM, Aurelien Bompard wrote:
What if a site wanted to run them on different VMs for example?
Yeah, but certainly there should be a limit to that. What if a site wanted to
run each mailman runner on a different VM for example?
There's already some support for that, in
Am 29.12.2014 um 00:26 schrieb Barry Warsaw:
On Dec 28, 2014, at 01:51 PM, Aurelien Bompard wrote:
As I mentioned, I think LMTP *could* work, but REST (inside HK) could
work too. Aurelien, what do you think?
I'd go with REST, it seems more flexible and we already have nice libraries
for
Am 29.12.2014 um 00:27 schrieb Barry Warsaw:
On Dec 27, 2014, at 08:41 AM, Florian Fuchs wrote:
How about a third option, a generic pub/sub or event archiver,
implemented in py3? It would meet all the above criteria (archivers on other
systems, no dependency on py3 -- or Python for that
Barry Warsaw writes:
What if I do A/B releases for 3.0b5?
Up to you; I have no objection.
But I'm only going to be looking at the Python 3 branch. I've already
ported my (work internal) Django site to Python 3 (which was mostly
trivial, I had more trouble with the Django upgrade itself).
Here's a crazy, probably stupid idea. I want to do one more release before
the end of the year, probably tomorrow.
What if I do A/B releases for 3.0b5?
A would be current snapshot of trunk, i.e. MM3 running on Python 2.7.
B would be current snapshot of the py3 branch, i.e. MM3 running on
This was a design mistake, I think.
Yeah, I see that now. But at that time, if I had known that I had two more
years (and counting) before MM3 was released, I'd probably have made
different choices.
I hope I'm not making the same mistake again.
As I mentioned, I think LMTP *could* work, but
On 12/26/2014 4:25 PM, Barry Warsaw ba...@list.org wrote:
On Dec 26, 2014, at 08:48 PM, Geoff Shang wrote:
FWIW, Debian Jessy (aka Testing/Frozen?) has Python 3.4.2.
Yep, Jessie will have 3.4, and Ubuntu has had it since Trusty Tahr (14.04
LTS). I don't know about other distros.
First,
On Dec 27, 2014, at 03:57 PM, Stephen J. Turnbull wrote:
By the way, I would say to adopt modern IETF practice here and drop
the X- (in practice collisions are rare while the annoyance of
fixing platforms to use the standardized name is frequent), and
include the algorithm in the name. Eg,
On Dec 28, 2014, at 09:23 AM, Tanstaafl wrote:
Second, I (for one, but there are many other debian admins maintaining
servers who feel the same) will not be upgrading my wheezy install to
jessie due to the ongoing systemd debacle.
I *definitely* don't want to infect this list with a debate about
On Dec 28, 2014, at 01:51 PM, Aurelien Bompard wrote:
As I mentioned, I think LMTP *could* work, but REST (inside HK) could
work too. Aurelien, what do you think?
I'd go with REST, it seems more flexible and we already have nice libraries
for it.
REST will be very nice, and I think with
On Dec 27, 2014, at 08:41 AM, Florian Fuchs wrote:
How about a third option, a generic pub/sub or event archiver,
implemented in py3? It would meet all the above criteria (archivers on other
systems, no dependency on py3 -- or Python for that matter).
We could start supporting one backend
Barry Warsaw writes:
I like the idea of putting this information in a List-* header, and
I'll take you up on the RFC offer.
OK.
Are you thinking about trying to push this through the IETF to make
it official?
Yes. It will depend on how much resistance I get, but having it
already
One of my top priorities has been to port Mailman 3 (core) to Python 3.
This
work is now complete, and ready to be merged into trunk. No doubt bugs
still
lurk, but at least the entire test suite is passing.
Congrats !
* A few database columns have changed from LargeBinary to Unicode. I
On Fri, Dec 26, 2014 at 04:38:08PM +0100, Aurelien Bompard wrote:
[...] then I'll merge this to trunk and do a 3.0b5 release as a
Python 3-only application. Mailman 3 will not be bilingual so Python 2
support will be dropped.
Wow. I am very surprised.
So we went from Python3
On Dec 26, 2014, at 04:38 PM, Aurelien Bompard wrote:
This should be pretty easy, something like the following command should work:
alembic -c src/mailman/config/alembic.cfg revision --autogenerate -m python3
port
I'm having some trouble with this because the system alembic doesn't have
access
On Dec 26, 2014, at 08:48 PM, Geoff Shang wrote:
On Fri, 26 Dec 2014, Pierre-Yves Chibon wrote:
This also means that mailman 3 will pretty much only not work on
server-oriented distro (except probably Debian that likely ships a python 3
version, although not being involved in Debian, I do not
Is there anything I can do to help with these? If there’s a task list maybe I
can work out what I could do.
This means I must now port HyperKitty and Kittystore to Python3, check that
we don't use Py2-only libraries, etc.
And mailman.client must be ported too, since it does import stuff from
On Dec 27, 2014, at 08:26 AM, Andrew Stuart wrote:
Is there anything I can do to help with these? If there’s a task list maybe I
can work out what I could do.
Hi Andrew, if you're interested in helping port Postorious and HyperKitty,
I'll defer to Aurelien and Florian.
Cheers,
-Barry
If it is released to version 1.0 with support for Python 2 then it will need to
support Python 2 for the forseeable future. It’ll be deployed all over the
place with Python 2 - when would the Python 2 be removed ever after 1.0? David
Murray has made substantial changes to email in Py3 -
I'm having some trouble with this because the system alembic doesn't have
access to the mailman source tree, which it needs (you get import
errors). I
tried to run alembic out of the .tox virtualenv, but that fails because the
mailman config system needs to be initialized.
Right, I'm
On Dec 27, 2014, at 08:21 AM, Andrew Stuart wrote:
If it is released to version 1.0 with support for Python 2 then it will need
to support Python 2 for the forseeable future. It’ll be deployed all over the
place with Python 2 - when would the Python 2 be removed ever after 1.0?
David Murray has
On Dec 26, 2014, at 10:32 PM, Aurelien Bompard wrote:
Right, I'm having issues too with the config file not being initalized.
I'll have a closer look.
Awesome, thanks.
I'm not exclusively using the REST API though. I'm importing a couple
interfaces, mostly the archiver interface. I'm also using
But there could be! I took a very quick look at HK (but not KittyStore)
and
it doesn't look like you need much. What if I added a REST API to access
the
core's system configuration settings?
That would work.
Yep, I missed that. Is it possible to feed HK messages out-of-process?
E.g.
Aurelien Bompard writes:
Barry writes:
One of the advantages of accessing the core through the REST API
is that it doesn't matter what clients like HyperKitty and
Postorious are written in.
I'm not exclusively using the REST API though. I'm importing a
couple interfaces, mostly
On Dec 26, 2014, at 11:02 PM, Aurelien Bompard wrote:
But there could be! I took a very quick look at HK (but not KittyStore)
and it doesn't look like you need much. What if I added a REST API to
access the core's system configuration settings?
That would work.
It turned out to be almost
On Dec 27, 2014, at 12:48 PM, Stephen J. Turnbull wrote:
Let's please take some care to think about this. ISTM this is like
the Nth time we've bumped into you need to be core to access config
data.
No more! See my other follow up. And there's no restriction on values.
Sometimes generic is
On Dec 27, 2014, at 12:42 PM, Stephen J. Turnbull wrote:
Remember, Mailman core is going to be distributing Internet mail.
Except in the case where 100.00% of the users are on one host, that's
going to be the bottleneck on message processing. Archiving simply
does not need to be fast. The
Barry Warsaw writes:
No more! See my other follow up. And there's no restriction on
values. Sometimes generic is easier than specific (shouldn't that
be a Zen of Python? :).
Uh-oh. Looks like somebody is using EggNog programming style! Or are
you just high on life? ;-)
Barry Warsaw writes:
Remember too that in MM3, messages only get fed to the registered
IArchiver interfaces by a separate archive runner. So they aren't
a bottleneck for delivery to the user, but on heavily trafficked
sites, they can potential consume a lot of resources if the
archiver
Am 27.12.2014 um 05:18 schrieb Barry Warsaw:
I tend to agree that a good design for any archiver is to be able to accept
messages over an IPC channel. A site may for example want to run the core on
one system and HK on another system (e.g. separate VMs perhaps). This would
only really be
One of my top priorities has been to port Mailman 3 (core) to Python 3. This
work is now complete, and ready to be merged into trunk. No doubt bugs still
lurk, but at least the entire test suite is passing. My intent is to merge
this to trunk and do another beta release before the end of the
Congratulations! Wow, Merry Christmas[1] to us!
Barry Warsaw writes:
One of my top priorities has been to port Mailman 3 (core) to Python 3. This
work is now complete, and ready to be merged into trunk.
Footnotes:
[1] Season to taste.
___
On Sat, Mar 24, 2012 at 12:15 AM, Barry Warsaw ba...@list.org wrote:
Not all of that will be needed. For example, I do want to eventually get rid
of zc.buildout, zope.testing, and zope.testrunner, so some of those
dependencies will go away as a result of that.
But presumably new dependencies
On Mar 24, 2012, at 03:41 PM, Stephen J. Turnbull wrote:
On Sat, Mar 24, 2012 at 12:15 AM, Barry Warsaw ba...@list.org wrote:
Not all of that will be needed. For example, I do want to eventually get rid
of zc.buildout, zope.testing, and zope.testrunner, so some of those
dependencies will go
Someone told me that I should poke Barry about Python3 support, so here
I am ;)
It's clearly something that can be done really soon, but I think it's
worth to start thinking about it.
In particular I noticed that lazr.config have been untouched since 2009,
which makes me think that is less
On Mar 23, 2012, at 08:19 PM, Andrea Crotti wrote:
Someone told me that I should poke Barry about Python3 support, so here
I am ;)
It's clearly something that can be done really soon, but I think it's
worth to start thinking about it.
Probably you meant s/can/can't/ ... but still, it may not be
40 matches
Mail list logo
