Getting to Mailman 3.0 final
Hi Mailman developers,
I really want to get Mailman 3.0 final out in the next month or so, absolutely definitely by the end of 2012. Clearly, the core won't have everything that everyone wants but I think it will have quite a bit, and be a useful release for people to start using in production.
In some ways, I view Mailman 3.0 in the same light as Python 3.0. It was critical for that version to be released because the reality is that most people won't test even a beta release. However, once Python 3.1 was released, we stopped recommending and maintaining Python 3.0 and just encouraged everyone to upgrade.
My biggest priority is to ensure that Mailman 3.0 is usable even without a web ui, and that major projects such as Postorius and HyperKitty can continue making good progress toward their own releases with 3.0.
To make it easier for me to understand your priorities and needs, I request that anything you think is missing in Mailman 3 today be added as a bug in our tracker: <http://bugs.launchpad.net/mailman>. You must add the 'mailman3' tag to the bug and bump the importance up to Critical. In a week or so, I'll start triaging the bugs and make my own assessments, and then anything marked critical will be fixed before the final release. There will be no High bugs, and everything else will be marked Low and postponed to Mailman 3.1.
In the bug comments, please add justifications or other information you think will be useful to me while doing a final triage. Of course, priority always goes to those bugs that have branches and merge proposals attached to them (i.e. contributions welcome!).
Cheers, -Barry
Oh, hey, this reminds me...
As I've mentioned before, I'm interested in seeing dynamic sublists replace topics in Mailman 3.0. We've got a student working on the port, but honestly he's been dragging his heels and I'm starting to doubt it's going to be done by the end of September.
What do you think the best timing for new feature-ish things? I'm guessing post-release makes more sense, but if there's a window of pre-release time that would make sense for this I might be able to help with the push and make sure we get in under the wire. Deadlines are always good motivation. ;)
Terri
On 12-09-10 12:04 PM, Barry Warsaw wrote:
Hi Mailman developers,
I really want to get Mailman 3.0 final out in the next month or so, absolutely definitely by the end of 2012. Clearly, the core won't have everything that everyone wants but I think it will have quite a bit, and be a useful release for people to start using in production.
In some ways, I view Mailman 3.0 in the same light as Python 3.0. It was critical for that version to be released because the reality is that most people won't test even a beta release. However, once Python 3.1 was released, we stopped recommending and maintaining Python 3.0 and just encouraged everyone to upgrade.
My biggest priority is to ensure that Mailman 3.0 is usable even without a web ui, and that major projects such as Postorius and HyperKitty can continue making good progress toward their own releases with 3.0.
To make it easier for me to understand your priorities and needs, I request that anything you think is missing in Mailman 3 today be added as a bug in our tracker: <http://bugs.launchpad.net/mailman>. You must add the 'mailman3' tag to the bug and bump the importance up to Critical. In a week or so, I'll start triaging the bugs and make my own assessments, and then anything marked critical will be fixed before the final release. There will be no High bugs, and everything else will be marked Low and postponed to Mailman 3.1.
In the bug comments, please add justifications or other information you think will be useful to me while doing a final triage. Of course, priority always goes to those bugs that have branches and merge proposals attached to them (i.e. contributions welcome!).
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/terri%40zone12.com
Security Policy: http://wiki.list.org/x/QIA9
On Sep 10, 2012, at 12:25 PM, Terri Oda wrote:
As I've mentioned before, I'm interested in seeing dynamic sublists replace topics in Mailman 3.0. We've got a student working on the port, but honestly he's been dragging his heels and I'm starting to doubt it's going to be done by the end of September.
What do you think the best timing for new feature-ish things? I'm guessing post-release makes more sense, but if there's a window of pre-release time that would make sense for this I might be able to help with the push and make sure we get in under the wire. Deadlines are always good motivation. ;)
I love this feature and would like to see it in Mailman at some point, but I think it's too late for 3.0. The ideal approach would be to continue to work on a branch of lp:mailman and even do a merge proposal of that when and if it's ready.
At some point close to 3.0 final, I'll create a maintenance branch (e.g. lp:mailman/3.0) and trunk will then be assigned to 3.1. I'll then fiddle the Launchpad metadata to indicate the 3.1 is the focus of development, and we'll just do bug fixes against 3.0.
Cheers, -Barry
Unfortunately, I did not have time to look at porting the optional authorship settings from the branch I did on mailman 2.1 to 3.0. I suppose this is too late to make the 3.0 deadline, but from what I saw of the 3.0 code, this does not seem a complicated change.
How can I register a bug, so that this change can be considered for 3.1?
https://code.launchpad.net/~mlm-author/mailman/2.1-author
Thanks.
----- Original Message ----- From: "Barry Warsaw" <barry@list.org> To: mailman-developers@python.org Sent: Monday, September 10, 2012 11:04:59 AM Subject: [Mailman-Developers] Getting to Mailman 3.0 final
Hi Mailman developers,
I really want to get Mailman 3.0 final out in the next month or so, absolutely definitely by the end of 2012. Clearly, the core won't have everything that everyone wants but I think it will have quite a bit, and be a useful release for people to start using in production.
In some ways, I view Mailman 3.0 in the same light as Python 3.0. It was critical for that version to be released because the reality is that most people won't test even a beta release. However, once Python 3.1 was released, we stopped recommending and maintaining Python 3.0 and just encouraged everyone to upgrade.
My biggest priority is to ensure that Mailman 3.0 is usable even without a web ui, and that major projects such as Postorius and HyperKitty can continue making good progress toward their own releases with 3.0.
To make it easier for me to understand your priorities and needs, I request that anything you think is missing in Mailman 3 today be added as a bug in our tracker: <http://bugs.launchpad.net/mailman>. You must add the 'mailman3' tag to the bug and bump the importance up to Critical. In a week or so, I'll start triaging the bugs and make my own assessments, and then anything marked critical will be fixed before the final release. There will be no High bugs, and everything else will be marked Low and postponed to Mailman 3.1.
In the bug comments, please add justifications or other information you think will be useful to me while doing a final triage. Of course, priority always goes to those bugs that have branches and merge proposals attached to them (i.e. contributions welcome!).
Cheers, -Barry
On Sep 11, 2012, at 05:38 PM, Franck Martin wrote:
Unfortunately, I did not have time to look at porting the optional authorship settings from the branch I did on mailman 2.1 to 3.0. I suppose this is too late to make the 3.0 deadline, but from what I saw of the 3.0 code, this does not seem a complicated change.
How can I register a bug, so that this change can be considered for 3.1?
For now, file the bug as normal, but add the 'mailman3' tag. At some point when I create the 3.1 series and start targeting bugs to that series, I will go through all the mailman3 tagged bugs and evaluate them as either new features (i.e. 3.1) or bug fixes (i.e. for 3.0.x).
Also, if you do port the code to lp:mailman, that would be great. You can push the branch and do a merge proposal against lp:mailman, which will always be the currently in-development branch. I'll create a maintenance branch for 3.0.x at some point.
Cheers, -Barryu
On Mon, Sep 10, 2012 at 02:04:59PM -0400, Barry Warsaw wrote:
My biggest priority is to ensure that Mailman 3.0 is usable even without a web ui, and that major projects such as Postorius and HyperKitty can continue making good progress toward their own releases with 3.0.
Part of the attraction in using Mailman 2, was that, for the majority of tasks end-users want to do, they can do it via the web interface; certainly an advantage over those "you have to do everything by email, in the proscribed manner, to the right address" 'alternatives' (I say 'alternatives' as I don't think they're fit for non-geeks (and even some struggle with those).
I would not roll-out Mailman 3 if there were not an end-users' web interface, at the very least for subscription management/alterations.
-- "Have you always been revolutionary socialists?" "No, we vote Conservative." (Simon Hoggart, interviewing a middle-class couple at a reading of Tony Benn's speeches)
On Sep 16, 2012, at 01:41 PM, Adam McGreggor wrote:
Part of the attraction in using Mailman 2, was that, for the majority of tasks end-users want to do, they can do it via the web interface; certainly an advantage over those "you have to do everything by email, in the proscribed manner, to the right address" 'alternatives' (I say 'alternatives' as I don't think they're fit for non-geeks (and even some struggle with those).
I would not roll-out Mailman 3 if there were not an end-users' web interface, at the very least for subscription management/alterations.
Maybe now that the core is pretty close to what it will be like when released, we can get more volunteers to help test Postorius, and perhaps contribute to it? It would be cool if we could do a simultaneous release, but OTOH, the architecture of MM3 expressly encourages separation of the web ui from the engine.
I do think that if we release them separately, we'll have to be very clear about setting expectations.
-Barry
Hi,
On 09/17/2012 04:50 PM, Barry Warsaw wrote:
Maybe now that the core is pretty close to what it will be like when released, we can get more volunteers to help test Postorius, and perhaps contribute to it? It would be cool if we could do a simultaneous release, but OTOH, the architecture of MM3 expressly encourages separation of the web ui from the engine.
I suggest, a good way to move forward would be to define a list of missing features and criteria we agree Postorius will need at a minimum to be worthy of being released alongside MM3.
Since I guess that not everybody is aware of all the existing features, I can prepare a list of those (as well as some comments on problems or decisions that need to be made), so we don't start the discussion with "It needs to be able to create new mailing lists".
I can't do that *right now*, but most definitely tomorrow.
Cheers Florian
- Barry Warsaw <barry@list.org>:
On Sep 16, 2012, at 01:41 PM, Adam McGreggor wrote:
Part of the attraction in using Mailman 2, was that, for the majority of tasks end-users want to do, they can do it via the web interface; certainly an advantage over those "you have to do everything by email, in the proscribed manner, to the right address" 'alternatives' (I say 'alternatives' as I don't think they're fit for non-geeks (and even some struggle with those).
I would not roll-out Mailman 3 if there were not an end-users' web interface, at the very least for subscription management/alterations.
Maybe now that the core is pretty close to what it will be like when released, we can get more volunteers to help test Postorius, and perhaps contribute to it? It would be cool if we could do a simultaneous release, but OTOH, the architecture of MM3 expressly encourages separation of the web ui from the engine.
I think if we release MM3 without 'a frontend' we will miss people's expectation to get a feature complete MLM - which includes a frontend in most peoples opinion I guess.
I do think that if we release them separately, we'll have to be very clear about setting expectations.
I wouldn't do it.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Patrick Ben Koetter writes:
I think if we release MM3 without 'a frontend' we will miss people's expectation to get a feature complete MLM - which includes a frontend in most peoples opinion I guess.
I agree on the basis of introspection (which is obviously a statistically biased sample), and pretty clearly the people who are currently posting "will I get feature X if I use Mailman 3" aren't thinking "I don't mind if I lose features Y, Z, and W, too" when they do.
It's possible that there's a vast silent majority who understand the implications of the regular statement that "Mailman 3 will not be a front end, but rather front ends will communicate with Mailman 3 via a RESTful interface". Even if so, I think the "what were they thinking, releasing without a bundled front end!?" crowd is going to be large, and they will leave and will not come back soon. In particular, I doubt we'll get any interest from cPanel et al[1], which to date has been an important way that Mailman gets introduced to people.
Footnotes: [1] They don't strike me as being creative enough to figure out that this means they can write their own proprietary front end.
I've been in lurk mode for quite some time, but I have to throw in my $0.02. As an admin of several busy servers, and mailman lists that send out close to a million emails per week, I can say that I don't have the time to deal with trying to create a new interface. I made my own cheat sheet of how to install Mailman on my servers, which already is not a simple process. But from my gatherings here, MM3 will -not- be a drop-in replacement, which is what I would need. It seems like there is a lot of stuff to configure, different packages, etc... And if there's no web GUI? That's useless to me. I'll be sticking with MM 2.x until MM3 -is- a drop-in replacement, in whatever form that comes in.
Its nice that there all these hooks into different parts of the program. But if it doesn't do what MM 2.x did out of the box, its not going to fly.
Suggestion: work on a self-contained complete solution. If people want to enhance and extend, then let them at the full MM 3 system. But I'm sure I'm not alone in wanting the least amount of software needed to run the package. I don't want more servers (processes). I need secure, low-footprint, low cpu-utilization processes.
Bob
Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
I think if we release MM3 without 'a frontend' we will miss people's expectation to get a feature complete MLM - which includes a frontend in most peoples opinion I guess.
I agree on the basis of introspection (which is obviously a statistically biased sample), and pretty clearly the people who are currently posting "will I get feature X if I use Mailman 3" aren't thinking "I don't mind if I lose features Y, Z, and W, too" when they do.
It's possible that there's a vast silent majority who understand the implications of the regular statement that "Mailman 3 will not be a front end, but rather front ends will communicate with Mailman 3 via a RESTful interface". Even if so, I think the "what were they thinking, releasing without a bundled front end!?" crowd is going to be large, and they will leave and will not come back soon. In particular, I doubt we'll get any interest from cPanel et al[1], which to date has been an important way that Mailman gets introduced to people.
Footnotes: [1] They don't strike me as being creative enough to figure out that this means they can write their own proprietary front end.
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
Security Policy: http://wiki.list.org/x/QIA9
Bob Puff@NLE writes:
I don't want more servers (processes). I need secure, low-footprint, low cpu-utilization processes.
You're not going to get more processes unless you want them. The processes currently planned are just called "runners" now, and will be less coupled than currently.
Whether the particular implementations under development are going to work for you, "you know it when you see them", I guess.
I wouldn't advise you to hold your breath if *secure* is really high on your list, though. I think the new architecture is going to be overall more secure (eg, better handling of authentication), but evaluating that in a corporate security context is going to be just as much effort and annoyance as any time you introduce a new application. (If not, you should worry about whether your security people are doing their job!<wink/>)
Steve
On Sep 18, 2012, at 11:03 AM, Stephen J. Turnbull wrote:
I agree on the basis of introspection (which is obviously a statistically biased sample), and pretty clearly the people who are currently posting "will I get feature X if I use Mailman 3" aren't thinking "I don't mind if I lose features Y, Z, and W, too" when they do.
If we can get Postorius in pretty good shape soon-ish, then I'm fine with waiting. I can use the time to fix bugs in the core, and add any critically missing features (mostly defined as, what does Postorius need to get us to a final release).
Looking forward to Saturday!
-Barry
On 12-09-17 1:12 PM, Patrick Ben Koetter wrote:
I think if we release MM3 without 'a frontend' we will miss people's expectation to get a feature complete MLM - which includes a frontend in most peoples opinion I guess.
I do think that if we release them separately, we'll have to be very clear about setting expectations. I wouldn't do it.
As the person who thought it was a bad idea to separate the two projects, I agree that I think releasing without a frontend will be pretty underwhelming for folk. But rather than delaying the core development, I think it might make more sense to have a mailman 3 core release and then a big advertised "Mailman 3 complete" release when the other related projects are available for a bundled release.
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
Terri
Terri Oda writes:
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
I don't think I can join but maybe .... Could you be a bit more specific than "all day" (especially time zone)?
Steve
On 12-09-17 11:39 PM, Stephen J. Turnbull wrote:
Terri Oda writes:
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
I don't think I can join but maybe .... Could you be a bit more specific than "all day" (especially time zone)? *laugh* That would help, wouldn't it?
I'm in US Mountain daylight time, which is UTC -600 I think?
I hadn't really set myself a schedule yet, but I'll probably be testing my setup and doing some prelim stuff on Friday night my time (probably 8pm mountain/2am saturday UTC or later) and then actually hacking starting sometime around 11am mountain/5pm UTC on Saturday probably running 'till around 11pm or later with some breaks for errands.
If I recall your time zone correctly, my evening is your morning, so if you want to stop by and argue with me, we should overlap Saturday morning for you/Fri night for me and ditto for Sunday/Saturday the next day.
Possibly helpful (I'm in Albuquerque, and the rest of you can add your own time zones):
http://timeanddate.com/worldclock/meetingtime.html?month=9&day=22&year=2012&p1=394&p2=37&p3=248&iv=0
On 09/18/2012 06:26 AM, Terri Oda wrote:
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
Excellent idea! I don't know yet how much time I'll be able to free up on Saturday, but I will definitely show up on IRC some time during the day...
Florian
On 09/18/2012 06:26 AM, Terri Oda wrote:
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
Sorry that I cannot participate this weekend. I have another activity that will keep me busy from Friday afternoon through the weekend.
Richard
On Sep 17, 2012, at 10:26 PM, Terri Oda wrote:
That said, I'm tentatively planning a personal postorious hackathon all day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman on freenode!
This is a great idea, thanks for suggesting it Terri! I'll definitely try to show up for as much of the day as I can, US/Eastern.
-Barry
participants (9)
-
Adam McGreggor -
Barry Warsaw -
Bob Puff＠NLE -
Florian Fuchs -
Franck Martin -
Patrick Ben Koetter -
Richard Wackerbarth -
Stephen J. Turnbull -
Terri Oda