Mailman Sprint happening NOW at PyCon 2016 Canada
Just to let you know.
Also, I've done a little tracker curation (specifically HyperKitty), mostly tagging -- probably you should assume nothing important is happening if you get notices.
Steve
On Nov 15, 2016, at 03:37 AM, Stephen J. Turnbull wrote:
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
On Nov 15, 2016, at 12:17 AM, Simon Hanna wrote:
Thanks Simon.
I guess you need to somehow create a milestone in hyperkitty itself.
Yep. I just created the 3.1 milestone. Can you see if you can assign issues to that milestone?
I'm not sure how useful bundler is either. I don't think Mark used it when he deployed MM3 on python.org. Container-based solutions seem like the better option, and I think we could support multiple container formats without much trouble (although, it would be good to have some CI around them).
Cheers, -Barry
On 14 November 2016 at 15:52, Barry Warsaw <barry@list.org> wrote:
Containers does makes things very easy but I am not sure how much comfortable people are with containers running in production for long periods of time, unattended. Dockers seems to be still tinkering with the public facing APIs and breaking compatibilities across versions of clients and server (which itself is another issue due to security). Other solutions like rkt and others are still not very mature and would mean a lot of deployment errors and bugs. However, we can have them as an *option* for deployments along with os specific packages.
I'd be willing to help with build automation and maintain containers for all the sub projects. Although, I won't be able to spare a lot of time in next 15 days as I have a paper deadline coming in very soon.
-- thanks, Abhilash Raj
On 11/14/2016 03:52 PM, Barry Warsaw wrote:
I'm not sure how useful bundler is either. I don't think Mark used it when he deployed MM3 on python.org.
Actually I did, but at this point I wouldn't use it for a fresh install. It was useful for me when I didn't understand how all the pieces fit together, and I still use the mailman-post-update script that it creates to run several Django commands that may be needed following updates to HyperKitty and Postorius.
It would need work. It doesn't know to install django-mailman3 nor the changes in Django settings for that and Allauth.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 11/14/2016 03:52 PM, Barry Warsaw wrote:
I'm not sure how useful bundler is either.
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.
Steve
On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote:
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
On 11/15/2016 04:01 PM, Barry Warsaw wrote:
It's not really a script. It's a django project configuration (Which you'll need to run postorius/hyperkitty) But it's built so that you can easily choose which components you want to actually use. However you may want to deploy Mailman, you'll have to use such a structure. It's pretty much barebones, with the added complexity resulting from allowing you to choose to run only one of postorius or hyperkitty.. And I tried to write up everything important in the readme...
It doesn't actually install anything on its own, but instructs on the different options available... It also includes nginx and uwsgi config files since I'm using them for deployment
It should work as is for the master branches, but my setups are a little behind right now...
Note updated Subject. ;-)
First time as a sprint leader, got really lucky with the sprinters. ellmetha did a bunch of work (4 MRs!) without a word [of English ;-]; I talked with mdupuis quite a bit but didn't need to look at any of his code at the time. I don't know if the code is up to snuff, but they picked useful things to work on!
Back in the conversation about distribution, Barry Warsaw writes:
I think I missed a reference to Simon's script, but I'd be interested in that approach too.
I didn't understand it correctly myself, but Simon explains in a parallel followup to your message.
What I have in mind is a script that
(1a) takes an argument which is a tuple of git refs, defaulting to our most recent release tags in the version for that release (1b) takes an argument which is a non-existent directory to create (1c) takes an argument which is the install prefix, default /usr/local (2) checks for prereqs, if not satisified exits with error message (3) creates the directory, cds there (4) creates appropriate venvs (5) clones 6 projects from gitlab (6) checkouts each project at its configured ref, see (1) (7) builds each project with appropriate venv (8) installs to $prefix/usr/mailman and $prefix/var/mailman (ignoring distro policy if different!) (9) prints a message pointing to instructions for configuring MTA and webserver
Maybe we can do better than (9) for Postscript, Exim (which is what I use, so my hand is up for that), and Apache.
I don't know about containers, I'm old-fashioned (and the only useful things my damn accountants will let me spend money on is travel and computers, I'm swimming in hosts although not IPs or time to play with containers). How much work would that be? Can we really expect our mom-and-pop users to have containerized hosts available? Do cPanel hosts do containers?
But as you know "really good documentation" is (a) a lot of work and (b) the product of reponsive users, especially beta testers. We shouldn't promise that yet.
Just-back-to-JP-from-PyConCA-and-a-successful-Mailman-sprint-ly y'rs,
On Nov 15, 2016, at 03:37 AM, Stephen J. Turnbull wrote:
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
On Nov 15, 2016, at 12:17 AM, Simon Hanna wrote:
Thanks Simon.
I guess you need to somehow create a milestone in hyperkitty itself.
Yep. I just created the 3.1 milestone. Can you see if you can assign issues to that milestone?
I'm not sure how useful bundler is either. I don't think Mark used it when he deployed MM3 on python.org. Container-based solutions seem like the better option, and I think we could support multiple container formats without much trouble (although, it would be good to have some CI around them).
Cheers, -Barry
On 14 November 2016 at 15:52, Barry Warsaw <barry@list.org> wrote:
Containers does makes things very easy but I am not sure how much comfortable people are with containers running in production for long periods of time, unattended. Dockers seems to be still tinkering with the public facing APIs and breaking compatibilities across versions of clients and server (which itself is another issue due to security). Other solutions like rkt and others are still not very mature and would mean a lot of deployment errors and bugs. However, we can have them as an *option* for deployments along with os specific packages.
I'd be willing to help with build automation and maintain containers for all the sub projects. Although, I won't be able to spare a lot of time in next 15 days as I have a paper deadline coming in very soon.
-- thanks, Abhilash Raj
On 11/14/2016 03:52 PM, Barry Warsaw wrote:
I'm not sure how useful bundler is either. I don't think Mark used it when he deployed MM3 on python.org.
Actually I did, but at this point I wouldn't use it for a fresh install. It was useful for me when I didn't understand how all the pieces fit together, and I still use the mailman-post-update script that it creates to run several Django commands that may be needed following updates to HyperKitty and Postorius.
It would need work. It doesn't know to install django-mailman3 nor the changes in Django settings for that and Allauth.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 11/14/2016 03:52 PM, Barry Warsaw wrote:
I'm not sure how useful bundler is either.
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.
Steve
On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote:
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
On 11/15/2016 04:01 PM, Barry Warsaw wrote:
It's not really a script. It's a django project configuration (Which you'll need to run postorius/hyperkitty) But it's built so that you can easily choose which components you want to actually use. However you may want to deploy Mailman, you'll have to use such a structure. It's pretty much barebones, with the added complexity resulting from allowing you to choose to run only one of postorius or hyperkitty.. And I tried to write up everything important in the readme...
It doesn't actually install anything on its own, but instructs on the different options available... It also includes nginx and uwsgi config files since I'm using them for deployment
It should work as is for the master branches, but my setups are a little behind right now...
Note updated Subject. ;-)
First time as a sprint leader, got really lucky with the sprinters. ellmetha did a bunch of work (4 MRs!) without a word [of English ;-]; I talked with mdupuis quite a bit but didn't need to look at any of his code at the time. I don't know if the code is up to snuff, but they picked useful things to work on!
Back in the conversation about distribution, Barry Warsaw writes:
I think I missed a reference to Simon's script, but I'd be interested in that approach too.
I didn't understand it correctly myself, but Simon explains in a parallel followup to your message.
What I have in mind is a script that
(1a) takes an argument which is a tuple of git refs, defaulting to our most recent release tags in the version for that release (1b) takes an argument which is a non-existent directory to create (1c) takes an argument which is the install prefix, default /usr/local (2) checks for prereqs, if not satisified exits with error message (3) creates the directory, cds there (4) creates appropriate venvs (5) clones 6 projects from gitlab (6) checkouts each project at its configured ref, see (1) (7) builds each project with appropriate venv (8) installs to $prefix/usr/mailman and $prefix/var/mailman (ignoring distro policy if different!) (9) prints a message pointing to instructions for configuring MTA and webserver
Maybe we can do better than (9) for Postscript, Exim (which is what I use, so my hand is up for that), and Apache.
I don't know about containers, I'm old-fashioned (and the only useful things my damn accountants will let me spend money on is travel and computers, I'm swimming in hosts although not IPs or time to play with containers). How much work would that be? Can we really expect our mom-and-pop users to have containerized hosts available? Do cPanel hosts do containers?
But as you know "really good documentation" is (a) a lot of work and (b) the product of reponsive users, especially beta testers. We shouldn't promise that yet.
Just-back-to-JP-from-PyConCA-and-a-successful-Mailman-sprint-ly y'rs,
participants (5)
-
Abhilash Raj -
Barry Warsaw -
Mark Sapiro -
Simon Hanna -
Stephen J. Turnbull