Hi List :-) TL;DR We should move to another mailing list implementation and host. The current list will remain as a read-only archive. I propose to move to Savannah. I expect this move to be painless.
--- I have already talked to the people at Savannah. They are willing to create a list for Magit even though Magit development happens on Github. They are also very responsive, so unless we get unlucky and hit a lazy day we might be able to complete the move in a single day. I think Mailman on http://savannah.nongnu.org would be a good match for this project. But feel free to suggest alternatives. Gmane and other third-party archives would then replace the current web interface. Are there other problems that could arise? --- But why? In the past I haven't paid much attention to the mailing list. The web interface is a pain to use and so is reading html mail in Emacs. Also I was under the impression that not much interesting was going on here. Maybe that impression was wrong. Regardless it is getting interesting now. It certainly is a problem if the primary maintainer avoids the mailing list for whatever reasons. oO It has also become apparent that some people thought following this list is enough to stay up-to-date with current development. Despite some false statements (which I have now removed/corrected) hinting into that direction that is not the case, development does happens on Github. Simply switching to another mailing list won't change that. But moving to something that does not actively encourage users to post html mails is a perquisite to read the list in Emacs (at least for me) and one cannot apply patches from the web interface. I am writing this message in the *scratch* buffer and will later post kill-yank it into Google's web interface, which will then turn it into html. Yes, I could probably configure mu4e to better deal with html mail but *everyone* who wants to use the list properly (including patch review) would have to do the same. This is not acceptable if an alternative, which makes html mail much less likely, is available. Doing most of the reading using the web interface (which sucks even for just this) and doing the patch work inside Emacs is also out of question. --- If/since the above is unclear/to opinionated there might be objects. If you agree with me, please help me out by providing a more coherent argument. --- To avoid disappointment later, I have to emphasize the following: After moving to a better list we will not instantly accept patches posted on the new mailing list, and to be up-to-date you will still have to follow development on Github. Supporting both pull requests and patches on the list comes with an overhead which I am currently not able and willing to handle. Discussing on both Github and the mailing list also leads to duplication but I am willing to make that sacrifice. The goal is to support both. But we should first extend Magit to better support a git/list based workflow - a first patch into that direction has already arrived, thanks. We should also extend Magit to support Github pull requests better - there are several 90% solutions out there attempting this. Or in other words and in good old Emacs spirit: while working on Magit we should focus on those features that make working on Magit more pleasant. :-) Jonas -- --- You received this message because you are subscribed to the Google Groups "magit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
