On Nov 15, 2016, at 03:37 AM, Stephen J. Turnbull wrote:

Also, I've done a little tracker curation (specifically HyperKitty), mostly tagging -- probably you should assume nothing important is happening if you get notices.

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:

I went ahead and tagged a couple of issues from Postorius and mailmanclient with the milestone. They are all user facing and I think would result in a lot of new issues, if they are not addresses before.

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 using it and I guess I won't be in the future. I'm using a git repository for my configuration that can be found here https://gitlab.com/thelinuxguy/mailman-suite along with a local branch that holds all my deployment specific changes. I still don't really understand what bundler does, and I always have to look through all the directories to try and find the file that I want to edit.

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

On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote:

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.

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

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.

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.

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,