[Maria-developers] Moving from Launchpad lists to something else... ?
![](https://secure.gravatar.com/avatar/2a8811aac5b504a5658b08d6e2608b62.jpg?s=120&d=mm&r=g)
Hi, I was speaking to Otto (CEO, MariaDB Foundation) and discussing that we should move the lists from Launchpad to something else. We obviously want to preserve the archives, and this isn’t going to happen overnight (something like an aim by the end of the year). Would you be ok with running on Google Groups? Would you prefer being on Mailman? Do you have another self-hosted or (preferably free) hosted solution as your preference? Today, we have several lists (maria-discuss, maria-developers, maria-docs) that are hosted on Launchpad. We also have a few lists (ambassadors, announce, commits, mirroring, maria-buildbot-reports) hosted on Mailman at lists.askmonty.org. Let us know what you think about this Kind Regards, Colin Charles -- Colin Charles, Chief Evangelist, MariaDB Corporation blog: http://bytebot.net/blog/ | t: +1-347-903-3201 | Skype: colincharles | Twitter: @bytebot
![](https://secure.gravatar.com/avatar/06fb7e7f8217ef0e572a8334567b7559.jpg?s=120&d=mm&r=g)
Personal opinion:
I know that nowdays we're all subscribed to multiple Google services, but this shouldn't be required to be part of a list. I'd prefer a solution other than Google Groups.
Regards
Federico
--------------------------------------------
Mer 14/10/15, Colin Charles
![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Colin Charles
I was speaking to Otto (CEO, MariaDB Foundation) and discussing that we should move the lists from Launchpad to something else. We
The most important is that people can subscribe to the list without having
to create an account. This is the problem with Launchpad.
However, the problem with the mailing list is not where it is hosted. It is
that the majority of development happens off-list!
The developer mailing list is the core of a healthy open-source project that
treats developers equally. It is where everyone, newbie or core developer,
can first learn how the project runs, and later follow what is going on.
But not so in MariaDB. So many people from SkySQL casually divide the world
into first-class SkySQL employees, who are included in discussions. And
second-class others, who are casually kept out, as a matter of course.
Just look at the below random example from a closed mailing list open only
to employees. Stuff like this happens all the time, on closed mailing lists,
closed IRC channels, and latest I think a company-internal chat tool called
"Slack".
Basically, MariaDB is turning into a proprietary project to build a business
for a struggling venture-funded startup. It just happens to be bound by the
original GPL license to release source of the main product, though even that
is desperately attempted being circumvented by stuff like "MariaDB
enterprise".
So Colin, and others: Why bother working to move the mailing list elsewhere?
Spend first your efforts to coerce everyone to actually use the mailing
list, and to remove non-public communication channels. Start with yourself.
Cc all mails you send to the public mailing list. Stop using non-puclic IRC
or other channels, and ask people to use the public channels if they want to
contact you.
Thanks,
- Kristian.
=======================================================================
From: Rasmus Johansson
Hi all,
I've now populated sprint 10.1.8-4 with the issues that we agreed upon yesterday on the maria call or over IRC after that. The sprint can be found here:
https://mariadb.atlassian.net/secure/RapidBoard.jspa?rapidView=27
There are a few things missing still which I hope we can add today: - Bar will add some issues from the list of debian patches - Holyfoot might have one issue missing. I had documented that MDEV-7817 should be added to Holyfoot, but I think I got that number wrong. HF, could you give me the correct number?
PLEASE NOTICE that this now is the last sprint of 10.1.8 after which the plan is to release it as the first stable GA release of 10.1 as discussed on the call. The release will happen after next week's Maria call. Please scream and shout if you think there are some issues in addition to the ones on the sprint that you think still must be fixed before going GA.
/me screaming #1:
https://mariadb.atlassian.net/browse/MDEV-8813
I don't see how we can go GA with binlog encryption (even disabled by
default), but without any ability to use the logs for
backup/SST/investigation/what-not.
And it's a new feature, which we technically cannot add after GA.
Regards,
/E
(to be continued)
=======================================================================
From: Colin Charles
On 1 Oct 2015, at 23:43, Elena Stepanova
wrote: PLEASE NOTICE that this now is the last sprint of 10.1.8 after which the plan is to release it as the first stable GA release of 10.1 as discussed on the call. The release will happen after next week's Maria call. Please scream and shout if you think there are some issues in addition to the ones on the sprint that you think still must be fixed before going GA.
/me screaming #1: https://mariadb.atlassian.net/browse/MDEV-8813
I don't see how we can go GA with binlog encryption (even disabled by default), but without any ability to use the logs for backup/SST/investigation/what-not. And it's a new feature, which we technically cannot add after GA.
mysqlbinlog is a client utility. It already has “differences”, i.e. no
streaming backup, needing GTID support
(https://mariadb.atlassian.net/browse/MDEV-4989), etc. I don’t see how
this can hold back our GA, so that we can include this tool to work
with things post-GA (maybe even for 10.2)
But of course, I agree we should aim for everything to be “usable”. I
don’t have a good solution to this problem, and I don’t see a time
estimate for adding support to this for MDEV-8813. I also know that we
definitely have to release 10.1 as GA *before* 5.7 is GA, so
presumably all this happens before our company/dev meeting.
Maybe we can just add this as a warning in the release notes and also
when someone is turning on encryption?
cheers,
-colin
=======================================================================
From: Elena Stepanova
mysqlbinlog is a client utility. It already has “differences”, i.e. no streaming backup, needing GTID support (https://mariadb.atlassian.net/browse/MDEV-4989), etc. I don’t see how this can hold back our GA, so that we can include this tool to work with things post-GA (maybe even for 10.2)
But of course, I agree we should aim for everything to be “usable”. I don’t have a good solution to this problem, and I don’t see a time estimate for adding support to this for MDEV-8813. I also know that we definitely have to release 10.1 as GA *before* 5.7 is GA, so presumably all this happens before our company/dev meeting.
Maybe we can just add this as a warning in the release notes and also when someone is turning on encryption?
Okay, I understand -- at the end, business needs are above everything
else (no sarcasm). Usability and quality are first to give way.
But then, this call for "issues that must be fixed" is a pointless
exercise -- there is nothing we can realistically add to the sprint
without postponing the release, so lets just agree right now that 10.1
goes GA next week no matter what, and add a warning "if you use this
server, you will get problems" (sarcasm... kind of).
And please actually *remember* this decision, so that there is no "how
come nobody said there were problems, we would have of course fixed
everything before releasing" complaints later. I clearly remember them
after our previous business-need-driven releases, and it was not fun.
In fact, given that Daniel probably leaves for the meeting next
Thursday (?), and knowing our buildbot and other infrastructural
instability, we should aim to release the tree which we will have on
Tuesday, the very latest. Which basically means it should be frozen on
Saturday, to let it build fully, and leave Monday for fixing whatever
gets broken by Friday pushes.
Among other things, it most likely means *no* to systemd -- unless we
are unbelievably lucky and the first systemd-enabled builds in
buildbot (which will hopefully happen tonight) show great success,
there will be no time to fix anything.
Regards,
/E
=======================================================================
From: Colin Charles
Okay, I understand -- at the end, business needs are above everything else (no sarcasm). Usability and quality are first to give way.
But then, this call for "issues that must be fixed" is a pointless exercise -- there is nothing we can realistically add to the sprint without postponing the release, so lets just agree right now that 10.1 goes GA next week no matter what, and add a warning "if you use this server, you will get problems" (sarcasm... kind of).
Overall, very good arguments and I cannot really claim to deviate from them. Rasmus might want to chime in, based on pressures from the products team?
And please actually *remember* this decision, so that there is no "how come nobody said there were problems, we would have of course fixed everything before releasing" complaints later. I clearly remember them after our previous business-need-driven releases, and it was not fun.
I wonder, what we do in situations like this. I mean there’s also the MariaDB Foundation whom are supposed to decide on things like this, but in theory we’re all captains… Do we query support @ MariaDB Corporation to figure out if this is something acceptable for them?
In fact, given that Daniel probably leaves for the meeting next Thursday (?), and knowing our buildbot and other infrastructural instability, we should aim to release the tree which we will have on Tuesday, the very latest. Which basically means it should be frozen on Saturday, to let it build fully, and leave Monday for fixing whatever gets broken by Friday pushes.
Among other things, it most likely means *no* to systemd -- unless we are unbelievably lucky and the first systemd-enabled builds in buildbot (which will hopefully happen tonight) show great success, there will be no time to fix anything.
Again more good points that I can’t argue with.
Original email says, "The release will happen after next week's Maria
call. Please scream and shout if you think there are some issues in
addition to the ones on the sprint that you think still must be fixed
before going GA.”
You bring up a good point that nothing realistically gets fixed from
now till then. So while I’m not Rasmus, maybe we do have to “delay”
the release till we’re at the company meeting. Again, I have no idea
what can get done from now till… whenever we freeze
Frankly, as long as we release before 19 Oct, I think we’ll be before
MySQL 5.7. However I think we need to also plan this as MariaDB
Corporation will want to do marketing around this (and we now have new
marketing lead(s)).
I think the GA release is 5.7.9, seeing
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-9.html, but
also remember
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-10.html is
out, which means they’ve pretty much baked GA and are doing “internal
smoke testing”, while ensuring that bug fixes go into 5.7.10. So to
me, their GA is “Ready”, and I can only imagine when they’ll drop it
to the world
=======================================================================
From: Rasmus Johansson
<skip>
Overall, very good arguments and I cannot really claim to deviate from them. Rasmus might want to chime in, based on pressures from the products team?
And please actually *remember* this decision, so that there is no "how come nobody said there were problems, we would have of course fixed everything before releasing" complaints later. I clearly remember them after our previous business-need-driven releases, and it was not fun.
I wonder, what we do in situations like this. I mean there’s also the MariaDB Foundation whom are supposed to decide on things like this, but in theory we’re all captains… Do we query support @ MariaDB Corporation to figure out if this is something acceptable for them?
It's easy to predict the feedback from support, as they are the ones who have to deal with customers' problems in GA. I suppose that's why they were kept out of the loop on previous occasions, at least they what they claimed. To make sure that at least members of this list are well-informed, I collected some quick statistics off the top of our JIRA. It's not very accurate, but it gives a good enough approximation. *5.5* (bugs said to affect 5.5 and possibly higher versions) ~100 bugs of Major Priority or higher; out of them, ~27 crashes. *10.0* (bugs said to affect 10.0 and possibly 10.1) ~ 178 bugs of Major Priority or higher; out of them, ~36 crashes. *10.1* (bugs said to affect 10.1 only) ~50 bugs of Major Priority or higher; out of them, ~14 crashes. Don't get excited yet. Most of 5.5 bugs affect 10.0 and 10.1. Probably nearly all 10.0 bugs affect 10.1. Remember, all of this is open statistics, everyone who wants can do the same search in JIRA. It does not evaluate the actual quality of the release, but it can tell people what *we know* about the quality of the release. Like, it makes it clear that we are about to release GA with ~70 crashing bugs, give or take. "Wrong result" bugs, which are actually even worse for many real-life scenarios, are more difficult to count, but there are plenty of them as well. I can admit right away that the release is by no means sufficiently tested, not even close. The problem is, even if it was tested more, the quality would not have become better -- as you can easily see from the numbers above, we don't have enough manpower for bugfixing.
In fact, given that Daniel probably leaves for the meeting next Thursday (?), and knowing our buildbot and other infrastructural instability, we should aim to release the tree which we will have on Tuesday, the very latest. Which basically means it should be frozen on Saturday, to let it build fully, and leave Monday for fixing whatever gets broken by Friday pushes.
Among other things, it most likely means *no* to systemd -- unless we are unbelievably lucky and the first systemd-enabled builds in buildbot (which will hopefully happen tonight) show great success, there will be no time to fix anything.
Again more good points that I can’t argue with.
Original email says, "The release will happen after next week's Maria call. Please scream and shout if you think there are some issues in addition to the ones on the sprint that you think still must be fixed before going GA.”
You bring up a good point that nothing realistically gets fixed from now till then. So while I’m not Rasmus, maybe we do have to “delay” the release till we’re at the company meeting. Again, I have no idea what can get done from now till… whenever we freeze
Frankly, as long as we release before 19 Oct, I think we’ll be before MySQL 5.7. However I think we need to also plan this as MariaDB Corporation will want to do marketing around this (and we now have new marketing lead(s)).
If we really must release before 19 Oct, I would not count on
releasing during the meeting, it's too optimistic, we don't even know
how well the connection will work.
And bugfixing during the meeting should also be minimized, previous
experience shows it does not do much good, probably due to all the
distractions.
Regards,
/E
=======================================================================
From: Sergei Golubchik
To make sure that at least members of this list are well-informed, I collected some quick statistics off the top of our JIRA. It's not very accurate, but it gives a good enough approximation.
*5.5* (bugs said to affect 5.5 and possibly higher versions)
I've also looked at bugs that we plan to fix in 5.5, that's about 2/3rd of affected.
~100 bugs of Major Priority or higher;
~67 bugs here, including, say, "MDEV-8557 [PATCH] Spelling mistakes".
out of them, ~27 crashes.
*10.0* (bugs said to affect 10.0 and possibly 10.1)
~ 178 bugs of Major Priority or higher; out of them, ~36 crashes.
*10.1* (bugs said to affect 10.1 only)
~50 bugs of Major Priority or higher; out of them, ~14 crashes.
Remember, all of this is open statistics, everyone who wants can do the same search in JIRA. It does not evaluate the actual quality of the release, but it can tell people what *we know* about the quality of the release.
Yes. In average (over last two years) we're getting ~20 major (or higher) bugs for 5.5 in a month. And fixing about as much.
If we really must release before 19 Oct, I would not count on releasing during the meeting, it's too optimistic, we don't even know how well the connection will work. And bugfixing during the meeting should also be minimized, previous experience shows it does not do much good, probably due to all the distractions.
It's not difficult to find good internet connection in Amsterdam.
I woulnd't suggest to do bugfixing at the meeting, but there's still a
week before it. And releasing on the meeting is possible, we've done it
before.
Regards,
Sergei
=======================================================================
From: Elena Stepanova
Hi, Elena!
On Oct 02, Elena Stepanova wrote:
To make sure that at least members of this list are well-informed, I collected some quick statistics off the top of our JIRA. It's not very accurate, but it gives a good enough approximation.
*5.5* (bugs said to affect 5.5 and possibly higher versions)
I've also looked at bugs that we plan to fix in 5.5, that's about 2/3rd of affected.
~100 bugs of Major Priority or higher;
~67 bugs here, including, say, "MDEV-8557 [PATCH] Spelling mistakes".
From the external perspective, I find 'Affects version' more useful
Right. than 'Fix version', because the former shows something real: version X.Y[.Z] is, or once was, affected by this bug. The meaning of our 'Fix version' field is vague, it's something like "We would like to fix it in version X.Y[.Z] and now we think there is a chance we will do it, but there is no guarantee when it will happen, or whether it will happen at all". Normally, users should not pay attention to it. My point was to show what an interested party (or an unfriendly blogger) can gather about any of our GA releases by a simple JIRA search. In fact, I'm surprised nobody out there blogged about our releases in this manner yet, they could make a good fun of us by matching these results with our release criteria published in the KB. Sooner or later it will happen, and I'd rather remind about it now than later listen to complaints from marketing or sales "It's bad for business, how could engineering allow it to happen?!".
It's not difficult to find good internet connection in Amsterdam. I woulnd't suggest to do bugfixing at the meeting, but there's still a week before it. And releasing on the meeting is possible, we've done it before.
Of course it's possible, it's just not reliable (even less reliable than doing it from home). What I meant was that if we really, really *must* release by 19th, I would not rely on doing it on the meeting. But even if we decide to do it from Amsterdam -- the current sprint ends on Tuesday, developers leave on Friday, so there is only Wednesday and Thursday to fix last-moment failures in buildbot, thus there is still no much room for fixing anything apart from the current sprint. Regards, /E =======================================================================
![](https://secure.gravatar.com/avatar/2a8811aac5b504a5658b08d6e2608b62.jpg?s=120&d=mm&r=g)
Hi Kristian, Memories of September 2013 are coming back… Standard disclaimers apply: I am speaking for myself here, and I get paid by MariaDB Corporation to work on MariaDB Server. I am *not* on the Management Team (but am on the Extended Management Team, basically as a mariadb guy without portfolio) of MariaDB Corporation, and largely a lot of the work I do is meant to benefit MariaDB Server and the community at large. But also I offer insight/opinions/etc in a role that spans organisation wide.
Colin Charles
writes: I was speaking to Otto (CEO, MariaDB Foundation) and discussing that we should move the lists from Launchpad to something else. We
The most important is that people can subscribe to the list without having to create an account. This is the problem with Launchpad.
However, the problem with the mailing list is not where it is hosted. It is that the majority of development happens off-list!
The developer mailing list is the core of a healthy open-source project that treats developers equally. It is where everyone, newbie or core developer, can first learn how the project runs, and later follow what is going on.
Development does happen off-list, sometimes in #maria, and sometimes in #maria-call (which we are trying to kill for #maria only — this largely inspired by you, who only joins #maria), but overall many things are just in the open. While I can’t speak for Rasmus, I think the sprint information he sends to people that report to him as opposed to the developers mailing list because the community doesn’t report to him. Can we make it public? I don’t see why not. I’m also a creature of habit, and while I try to send all relevant emails to maria-developers@ or maria-discuss@, I also have hardwired in me, Shift+Mac+R, which basically is reply-all. I rarely bother adding/removing email addresses because that involves me using the trackpad. I agree with you re: the developer mailing list; I think we should have less discussions on IRC and document everything on the lists. Its important to know why things happen. I continually refer back to Jira when I want to know why we make decisions as well. However I guess with being distributed, like many an OSS project, its clear that immediacy needs to happen in discussions sometime hence the use of IRC. As a bonus, we do have archives — http://marialog.archivist.info/ I know you don’t join the Maria call we have, but even I miss out on many of the calls due to my hectic travel schedule. I will admit to enjoying talking to my colleagues (fellow Maria captains employed by MariaDB Corporation and MariaDB Foundation) when I get the chance to. Do you suggest we also have an open call for all? I don’t see why not if it can add value and not take precious time away from crucial development
But not so in MariaDB. So many people from SkySQL casually divide the world into first-class SkySQL employees, who are included in discussions. And second-class others, who are casually kept out, as a matter of course.
I cannot control what happens when support people (or consultants, or product management) send you email. I am very happy that generally you always CC the list in your responses, but even I myself don’t get those emails unless it hits the list. And if you’re referring to actual support questions, I guess its clear that people use the support system and since you and I get paid by MariaDB Corporation, we have to use their tools to ensure that our customers are getting the best service possible.
Just look at the below random example from a closed mailing list open only to employees. Stuff like this happens all the time, on closed mailing lists, closed IRC channels, and latest I think a company-internal chat tool called "Slack”.
I guess the discussion you quoted could have happened on maria-developers@ (though I think no one on that list appreciates you sharing company-internal discussion, externally). I’m looking at to:all@mariadb.org and I see mostly boring stuff like: [All] Leaving from hotel to dev meeting at 9:00 [All] The booking.com boat tour signup You have a session to lead at the MariaDB Developers Meeting [All] Current MariaDB sprint [All] Daniel out for the next week [All] Can't do the Maria call [All] Book your flights for company and developers meeting [All] back from vacations JIRA SOAP API will be removed In fact the only email I sent there in 2015 was titled: MySQL Meetup Monday night 6.30pm (TONIGHT) With a very boring body: — We have a meetup tonight, at 6.30pm. You are all encouraged to give a 5-10 minute talk, so bring your laptops :) We can meet by 6pm at the lobby and leave together. The address is: Marktplaats/eBay Office Amsterdam Wibautstraat 224, Amsterdam See you all tonight and there will be pizza & beer/soft drinks. — So I’m not sure that it’s a big deal that all@mariadb.org exists. The discussion you quoted is something *extremely* rare (most don’t even have replies). Though I’m happy my “prediction” of Oct 19 as GA for 5.7 pretty much came true. Again I’m a Shift+Mac+R person, so didn’t even see where the discussion happened (yes, I do not filter my email, it all comes to INBOX because all emails are equally important to be dealt with — whether MariaDB Corporation or community related) Slack is a tool that the company ( MariaDB Corporation ) not the project or the MariaDB Foundation uses. I can’t speak on behalf of the MariaDB Foundation but project stuff generally happens on #maria on freenode. Slack exists so that people within MariaDB Corporation can speak to other colleagues, esp. on issues like support, etc. But also to act as a watercooler. You’ve resisted joining Slack and its your own personal choice, but I’m on it, just so I can interact with my new (well, now 2+ years since the merger of SkySQL Ab and Monty Program Ab) colleagues.
Basically, MariaDB is turning into a proprietary project to build a business for a struggling venture-funded startup. It just happens to be bound by the original GPL license to release source of the main product, though even that is desperately attempted being circumvented by stuff like "MariaDB enterprise”.
While I’m not privileged to know if MariaDB Corporation is a struggling venture-funded startup, I can assure you that I did not sign up to work on anything proprietary (and probably neither did you). MariaDB Server is 100% opensource GPLv2. MariaDB MaxScale (which I don’t personally work on) is also 100% opensource GPLv2. And last I checked, this whole idea of MariaDB Enterprise is also 100% GPLv2 and opensource (again something I do not work on). Whether the idea is a good one or not, is a topic for another discussion, but if you think there is any circumvention, please let me/Rasmus know so we can fix it.
So Colin, and others: Why bother working to move the mailing list elsewhere? Spend first your efforts to coerce everyone to actually use the mailing list, and to remove non-public communication channels. Start with yourself. Cc all mails you send to the public mailing list. Stop using non-puclic IRC or other channels, and ask people to use the public channels if they want to contact you.
Kristian, I admire your zeal when it comes to things being done in the open. When MariaDB Corporation people ask me how to reach you, I always say, “use the public lists or ping him on irc”. When it involves customer specific cases, I hope you understand why they can’t do that? I do try to coerce everyone to actually use the list (I myself like using it — except in instances like this where we wash dirty linen in public). I can’t remove myself from non-public communication channels because my salary is paid by MariaDB Corporation and I am duty bound to read their emails. I can’t CC all mails I send to a public list, considering I also deal with customers, sales people, support, products, etc. My role spans much of the organisation so its quite hard to CC everything to the public (and again I can’t ask MariaDB Corporation employees to use public lists for everything either). We have brought up and said that most discussions will happen on #maria. If you came to Amsterdam a little earlier, you will note that this was a goal from that meeting. I hope this alleviates your concerns, and I wish you will act with tact and consideration going forward cheers, -colin -- Colin Charles, Chief Evangelist, MariaDB Corporation blog: http://bytebot.net/blog/ | t: +1-347-903-3201 | Skype: colincharles | Twitter: @bytebot
![](https://secure.gravatar.com/avatar/81476f70a6281904d909dabab08d081a.jpg?s=120&d=mm&r=g)
Hello Kristian!
2015-10-21 8:48 GMT+03:00 Kristian Nielsen
The most important is that people can subscribe to the list without having to create an account. This is the problem with Launchpad.
In this sense plain Mailman seems to be the best. It also creates an account but the password is automatically created, so it feels like there is no account requirement. On http://www.discourse.org/ federated login can be used, e.g. Github. On Google groups the admin can add email addresses directly and no account is required, but I didn't find a way for users to self-subscribe without using a Google account. I'll continue to evaluate these options.
However, the problem with the mailing list is not where it is hosted. It is that the majority of development happens off-list!
The developer mailing list is the core of a healthy open-source project that treats developers equally. It is where everyone, newbie or core developer, can first learn how the project runs, and later follow what is going on.
From what I've seen you are an excellent engineer and I remember that you've raised some very important issues on the list, like for example last winter regarding that way too often buildbot tests fail and that developers don't have enough discipline to push only all green stuff.
I this case I however think you are over-reacting. The fact that company staff discuss development internally is not a problem. I can see plenty of discussions in the public on this mailing list and on irc #mariadb. I am sure all important things are discussed on bigger forums. I am sure Facebook and Google staff who work on MariaDB/MySQL also have a lot of internal discussions for example regarding their own priorities and what to invest their time on. That kind of stuff is supposed to stay internal and it is not relevant for others. [..]
Just look at the below random example from a closed mailing list open only to employees. Stuff like this happens all the time, on closed mailing lists, closed IRC channels, and latest I think a company-internal chat tool called "Slack".
I don't work for the corporation and I don't have access to the Slack you refer to, or other company confidential stuff, but I am sure that internal and non-public communication channels exist for a reason. People should be allowed to enjoy the safety those havens provide. Please don't publish internal communications. If you notice that something is discussed internally that might be of interest to a wider audience, then ask those people to write about it in public (as you just did), and keep asking them again on case-by-case basis if a categorical request to discuss everything on a public mailing list does not work for them.
So Colin, and others: Why bother working to move the mailing list elsewhere?
It does matter for a lot of people. Please don't undermine other people's efforts by claiming that they are in vain. The community is constantly growing and what discussion tools are used is essential and worthwhile to do well. Your point of view of the status quo is not a generic community view, so you need to factor in the employee/corporation things that apply to you but that other contributors don't experience. What that in practice means is something you need to discuss with your co-workers and not with contributors in general on the mailing list. - Otto
![](https://secure.gravatar.com/avatar/81476f70a6281904d909dabab08d081a.jpg?s=120&d=mm&r=g)
Hello!
No decision about this has yet been made. I reviewed the thread and
Discourse seems to have most support.
2015-10-21 8:48 GMT+03:00 Kristian Nielsen
The most important is that people can subscribe to the list without having to create an account. This is the problem with Launchpad.
I checked that it is possible to subscribe and unsubscribe to Google Groups with an email address only - no Google account is required. At the moment I still think that a Google groups is the way to go as that places least maintenance burden on us. I would however also be willing to try self-hosted Discourse if somebody here would volunteer to help maintain a new server, say discourse.mariadb.org. Setup using the Docker images as explained at https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md is fairly simple and we can "outsource" the e-mail server nightmares to Mandrill that is free up to 12000 messages per month. There should however be somebody who can commit some time to maintain the server at regular times for years to come, for example install security bugs and take care of backups, distro upgrades etc. Is here 1 or even better 2 persons who would like to volunteer?
However, the problem with the mailing list is not where it is hosted. It is that the majority of development happens off-list!
Related to this, there is now also a #maria-dev channel. This way the #maria channel does not get cluttered with development talk. A lot of talk is also in the Jira and Github issues, and thus there is less mailing list traffic. - Otto
![](https://secure.gravatar.com/avatar/a2be5e3cc035a1320b5870360a7338f7.jpg?s=120&d=mm&r=g)
On 25/11/2015 15:59, Otto Kekäläinen wrote:
Hello!
No decision about this has yet been made. I reviewed the thread and Discourse seems to have most support. Is here 1 or even better 2 persons who would like to volunteer? Discourse looks good, but wouldn't it make more sense if self-hosting to use something that runs on MariaDB? Discourse requires PostgreSQL, and has no plans to support MariaDB. Finding volunteers to support PostgreSQL on the MariaDB mailing list might not be so easy :)
Mailman released a new version last week, their second 3.x release.
![](https://secure.gravatar.com/avatar/01d86d32e4a72ce9ecd34dba70b74cc4.jpg?s=120&d=mm&r=g)
Many people at MariaDB Corp are familiar with Postgres, so that wouldn't be
a problem.
But of course, eat your own dog food, etc.
Le mer. 25 nov. 2015 à 15:59, Ian Gilfillan
On 25/11/2015 15:59, Otto Kekäläinen wrote:
Hello!
No decision about this has yet been made. I reviewed the thread and Discourse seems to have most support. Is here 1 or even better 2 persons who would like to volunteer? Discourse looks good, but wouldn't it make more sense if self-hosting to use something that runs on MariaDB? Discourse requires PostgreSQL, and has no plans to support MariaDB. Finding volunteers to support PostgreSQL on the MariaDB mailing list might not be so easy :)
Mailman released a new version last week, their second 3.x release.
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
participants (6)
-
Colin Charles
-
Federico Razzoli
-
Guillaume Lefranc
-
Ian Gilfillan
-
Kristian Nielsen
-
Otto Kekäläinen