No, I’ve fixed the particular issue indicated by “… also a problem … but fixed”. This doesn’t concern the postfix mailman configuration.
But allow me to propose something else, again anticipating a future state of our architectorial combinations:
In a sense, this is hypothesis-driven development (made up today), which should be very close to test-driven development, as formulating a hypothesis is actually giving shape to a test (if a certain assertion is whether true or not).
If we assume, that …
- we are confident of our assumtion to be able to
- the recent merge of Ecobytes and allmende.io regarding thin infrastructure layers being available for the Commons, as in bare metal colocation (with warranty) and Software as a Service (SaaS, without warranty), eventually evolving into a Federated Commons Cloud, and
- separation and sharing of smaller responsabilities feels good and strengthens trust relationships,
I hereby propose to use our CHEST resources to get
ulists.orgfrom @Simon_Sarazin running and rather build on their (to be fixed) top-notch Mailman 3 infrastructure, thus donating Service as a Commons, for the Commons, by joining efforts not only on the mapping, but also on the infrastructural level.
As structural demands and communicative needs in working with communities often coincidate.
We could then include this into the upcoming and neccessary Sunday InfraHack and already publish listnames like:
additionally to IRC rooms on Freenode, available also with low-entry barrier interface Scrollback.io.
Which is just the bare available communication stack in regular FLOSS communities and could help us solve some headaches around noise in the journal.
The ⟪ noise in the journal ⟫ pattern
(Blog) redaction crew?
investing in Mailman 3 - instance ulists.org ||
Continuing the discussion from Mailing lists:
@gandhiano is that somehow accorded with you?
- In general I would agree, that it makes more sense to invest in broader community infrastructure than simply migrate our mailing list
- The question is, how extensive/intensive is that “simply migrate” in relation to “build on their (to be fixed) top-notch Mailman 3 infrastructure”
- How well crafted, reviewed and tested is Mailman 3 (out in beta since 2015)
- How is the experience of @Simon_Sarazin, did it ever run, and or how well?
- How much is this going to keep us (respective @almereyda) occupied in the further development of the SSEDAS and CHEST, which both have time-constrains attached)
- a lot of infrastructure decisions and developments are dependent on you @almereyda. E.g. Michael is waiting for database specifications or better to say well crafted proposals to develop from. As well as you mentioned to have worked out some architectural concepts for SSEDAS and CHEST last friday, but did not share yet.
My final consent would be based on time and complexity estimations, as well as clear description of the possible impact beyond TransforMap.
If it is easy, manageable in scope, stable and useful (just remeber your first groupserver experience), go for it. If it is not, let´s focus.
Mailman 3 is a pretty complex beast, actually a bundle made up of 4 components. I would strongly suggest NOT to go that way to fix the issue. Installing/setting up/testing AND documenting is a whole story with quite some effort. And we have a whole lot of other stories in the current sprint pending, where effort would be better invested (from a team perspective).
The current Mailman2 lists can very simply just be exported/migrated to the current Mailman2 infrastructure on Ecobytes, if solution at the current Transformap server seems difficult.
This should work sufficiently until Ecobytes or whoever in the federation implements a working Mailman 3. Mailman 3.1 will also offer migration/upgrade possibilty from Mailman 2, so no dependency with legacy software will be built here.
That’s a good note.
Can find about that. But then I still strongly propose to create a concise naming scheme for different lists regarding to usual FLOSS patterns.
Do you have a concrete example of such a pattern in TransforMap?
It would probably be interesting to replicate either the circles structure, or the categories of Discourse into mailing lists and use them more specifically for announcements we want to make sure get to all. So, for example:
But in any case the first step is just bringing the global and maps list back online, as general purpose lists and non-articulated complement to Discourse. I still don’t grasp the distinction of both and at the current phase would even suggest merging everything into one list.
honestly; on the “maps” list, we could use German language and for dealing with conflicts this would be highly recommendable;
If we now start discussing these conflicts on the fragile global list, we’ll probably loose early adopters.
So, I’d suggest:
for the moment.
I was not aware of the language distinction. Your proposal makes all the sense.
@gandhiano is there any reason not to do that, as in the long run, I think we want to have the infrastructure running with Ecobytes anyway?
Yes, there are two reasons:
- The domain transformap.co is not under our management, whoever owns/manages the DNS (I suppose @almereyda?) needs to point lists.transformap.co to mail.ecobytes.net
- Our (still) very old mail infrastructure is vulnerable to backscatter spam from time to time and right now this is leading to a partial block of mail delivery to hotmail and gmail. I will address this issues tonight, but it might take several days until mail delivery is back to normal.
- Did you just buy a new domain called
- How do you mitigate the truck factor with this service; where is it hosted, netcup? They are also know for being generous with free infrastructure for social initiatives.
- Could you fork the Dockerfile to https://github.com/TransforMap?
- Could you create a Let’s Encrypt certificate for the SMTP service? https://ssl-tools.net/mailservers/lists.transformap.co shows self-signed.
3 posts were merged into an existing topic: Add a certificate to lists.transformap.co
2 posts were merged into an existing topic: Use something different as mailman for lists.transformap.co
So, to summarize and make clear and understandable what everyone is/will be doing. Please correct if something is wrong:
- DONE: A mailman (2.x) instance is deployed for lists.transformap.co > @toka
- Lists for each circle, plus the global and German will be setup as announcement only lists > @toka
- The list reply-to email will be setup to a specific e-mail address connected to a POP3/IMAP mailbox
- POP3/IMAP mailboxes related to each list/circle will be setup > @almereyda
- A mailhandler, or a specific function within discourse, will handle the incoming e-mails and post them as comments on the respective threads. > @almereyda
To think is, how will the mailhandler know where to post the issues. This is sometimes quite complex and requires the use of VERP or other mechanisms (e.g. tokens) for concatenating the e-mail address (at the moment we are even using a gmail address for discourse, which is of course far from ideal). Discourse does offer this, so it might be simply a matter of making any announcements to lists go through a special thread on discourse.
I would in any case not make the global and German lists as announcement only, not for now. We need first to stabilize/restore the communication before going for the next step. These should be brought up, with the existing contacts, ASAP. Please deal with this before starting anything else.
I do not understand the first part of @gandhiano but want to second the 2nd part “setup the global and german lists”
its up and running, but not very well tested
before announcing it to the world, we should do some more testing first
4 posts were merged into an existing topic: Sprint retrospective #2 and sprint planning #3 online meetings