On Sun, May 24, 2020, at 7:27 AM, Stephen J. Turnbull wrote:
Brian Carpenter writes:
Can I add this through a mailman core update via pip?
Eventually .... This depends on when Abhilash gets enough content and a little bit of time to do a new release.
FWIW, you can also install from Gitlab directly simply using pip:
$ pip install git+https://gitlab.com/mailman/mailman@masterYou can use @ to specify a git reference, like a branch name or tag name or a commit hash would also work.
Getting meta: You've been asking for very recent features fairly frequently. I understand that everybody feels better with released code, but to be honest, we do not have a deep quality assurance process. The test suite is voluminous and quite comprehensive, but that's not the same as having a proper beta process, mandatory reviewing, etc etc. It's not obvious to me that we can do a better QA for you than you can do for yourself.
Our QA process is basically mail.python.org (m.p.o) and lists.mailman3.org and couple of other server Mark runs for his personal stuff. We get notified about the major breaking changes pretty fast (m.p.o is pretty important to keep up) but some small changes do get piled up until I get to them.
I have a decent number of errors from Sentry that I should look at, many of which are triggered by weird inputs. It needs a bit more work and balance between bugfixing and new features, which I haven't been very good at :(
I can however do more rc and beta releases if there are people out there willing to get/test out new features faster. With the current releases, I am first time releasing some rc versions, but I think I might keep up the 1-2 week rc period for upcoming releases.
With that in mind, have you considered building your own from source, on a branch from a moderately recent tag, and cherry-picking only commits for features you really want right now?
I admit I don't know how appropriate that is in our tree (I just build from master all the time), but I think that Abhilash is probably pretty careful to pull complete branches so that this should work. If it looks to you like the patches are a little "ragged around the edges", we can work on the process and try to make it more amenable to such cherry-picking for people like you who need some of the most recent commits ASAP, but don't want to accept the whole "bleeding edge".
The one huge issue with "clean" cherry-picking is NEWS.rst in each repo. There is a little bit of manual intervention involved always to update the changelog. We could adopt a different more specialized tool like Blurb1 that CPython uses, but I find it a little too cumbersome for a small project like us. It might just end up making contributing to Mailman a bit harder too (extra tool to install and create NEWS files vs adding a new line in NEWS.rst, pretty small change but things add up!).
This also would be useful for your Affinity etc development, I think. (Of course maybe that's what you're talking about, but "emergency moderation" is a pretty common need in production.)
I am "trying" to do more frequent releases. There are a lot of bugfixes and REST API enhancements coming up in the next version of Core, including like Mark said, emergency flag being exposed.
I **think** emergency was the last one pending to be exposed via API, I did a whole bunch of them in previous version but missed out on emergency. There are a bunch of un-used attributes of MailingList (like topics, expire_subscriptions_after etc) which don't *need* to be exposed and they get mixed with some other useful ones.
If anyone finds something useful that isn't exposed, please open a ticket or even better submit a MR (it is really quite easy).
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)