Release planning for version 2.3.1 #233
Comments
|
We have so much issues and PR's marked for 2.3.1 that I'm not sure we can wrap it all up quickly. On the other hand, if you think we've introduced enough changes to mandate a new release, I don't mind that. We can always retarget whatever doesn't make it into 2.3.1 and have another release later at some point. |
|
Good. I will try to check what I can do in the next weeks. Everything else will be moved to the next release 2.3.2. I also hope to find an afternoon for vexim3. |
|
I have reviewed a couple of PR, now I'd like to decide on those with the "to review" label: After the merges we should do some testing and then push out vexim 2.3.1. Are there other things you want to get in? |
|
We have several long-standing code-related PR's (such as #106) which require more and more polishing with each commit we make, so in general, I'm in favor of reviewing and accepting as many of them as possible. However, as usual, I don't have enough free time (and perhaps even motivation) to actually review them properly, so I guess I'll leave these decisions up to you for now. |
|
I already had a look into the LMTP transport (#150), I wanted to do it differently but it didn't work out that easily (using the same router as we do currently). It's not a huge thing to implement but it would require some changes to the interface (which we suppose would be much easier on a newer interface). Custom user names is really interesting (#106), at this point we could think about fiddling in LDAP support (or at least design it in a way that it is possible). The PR is rather small, we could give it a quick test and put it in. We risk to change it later. All these spam-reducing stuff (#153, #161), I'm not really convinced of these solutions. We could put them into our wiki for people wanting to use it. We should review the anti-spam measures at some point, e.g. implementing something like policy.d but directly within exim (should be possible with ACLs to give "points" for certain features of a mail and reject them in the end if the total score exceeds a certain value). |
|
Re #150: I'd really like to avoid additional UI and DB changes, so I'd prefer LMTP to be a server-wide option for now. Furthermore, I'm not sure this is something a virtual domain administrator or even the end user should mingle with, so I guess I would have preferred it even if we were working on Vexim3. Re #106: the use-case says it all, and assuming it's a small change as you say, I really don't think it would hurt for us to have it. Regarding the other two: I'm too lame on the spam fighting front to weigh in on that. :) Although you made me wonder why you'd want to implement something directly in Exim when it is already implemented in another package. |
|
I didn't have much time lately. I still think we should push vexim 2.3.1 a bit, some things which should go into it:
unsure (I don't use it, if someone finds the time to fix it would be great):
later (or if someone has time):
Then, we can split off a vexim2.3 branch, and on master we can continue, implement some of the outstanding pull requests with new features. We can test them. Smaller things can be back-ported until vexim2.4 is considered stable enough. @rimas-kudelis I hope you have some time to look into the mysql issues. |
|
Is vexim alive? |
|
@VVD, it's not as active as we'd want it to be, but I wouldn't consider it completely dead either. More like, it's just pretty stale. For more context, Vexim consists of three mostly independent parts, which can be stale or active mostly independently of each other:
|
|
@rimas-kudelis, thanks for information. [modified by @rimas-kudelis: report moved to #276]
|
|
@VVD cold you report bugs in an extra topic and provide a pull request please - don't hijack threads. what do you mean with It isn't ready yet, doesn't support apache and etc. :-( ? Vexim2 runs with Nginx, Apache, lighttp (I did test these) and for sure with many others. |
Ok, I'll create new bug report, but without pull request.
It was answer on this suggestion:
|
|
this adds a new feature and changes the db-structure. I´d use a new version and not only a patch version. |
sorry for the delay... Python does not need a specific webserver. The python application runs on a WSGI (uwsgi, gunicorn, ...) or ASGI (hypercorn, uvicorn, ...) engine. For several reasons it makes sense to put a webserver in front of this engine. It's similar to php using php-fpm (or uwsgi) and put a webserver in front of it. In the old times Apache would have handled php itself but that had major drawbacks. |
|
A larger zoo means more time for support and worse support. |
Python is not good alternative for project with lack of development activity like Vexim. Because, a python packages have amount of incompatible updates from version to version. |
|
Each time there's some movement in the pull requests or issues in this repository, I have this urge to rewrite Vexim using Symfony. But then I remind myself how little I use Vexim myself anymore, which translates directly into how little priority it has for me personally. So I just put it off, because meh, it's okay for me as it is. But I do think that Vexim2's codebase is a dead-end. It's ugly and should be rewritten using modern practices before introducing any new functionality. Especially when such functionality involves database schema changes, because having a yet another non-versioned schema change would only grow the "zoo" of different Vexim DB schemas in use, which I'd like to avoid. Perhaps we should adopt an official policy about this? As for the Python version, @runout-at did all the work there by himself, so I don't think any of use here is in the position to command him what technological choices to make. |
|
Thx. It was just my opinion but i think it's off topic here. If someone have the urge to discuss religious aspects of PHP vs Python - feel free to open a new Issue. |
|
I didn't like the idea of changing the language either. However, if you use mailman, then you need python anyway. |
|
I'm wondering if we should tag 2.3.1 after all. Got an email from @gldickens3 today, who upgraded a couple Debian servers and hit a bug which we fixed over three years ago, but never tagged for release (2a9479d). Anyone up for reviewing any PRs before the release? I'd specifically like to merge #264 in, but I'd say other PRs which don't change the DB schema could also be considered. |
I went over your PR quickly and it look ok so far.
I would switch my db on a working setup to utf8mb4 and then probably try a new install with this #253.
no tags at all? If we manage to test a bit, we will know at least that this version seems to work more or less and there are no conflicts or not too much inconsistencies between the merged PR. |
|
I'm fine with doing a new release. As Exim had a mayor change in the last years (since last vexim release): Did anyone check if vexim has to change something for that? At least the variables $local_part and $local_part do not work as before as I remember. It's some time since I did this on my server. |
|
yes, afaik the mailman router does not work anymore starting Exim 4.96.
You have to add this line to mailman_router after line 517 in
"vexim2/docs/configure":
local_parts = dsearch,filter=dir;MAILMAN_HOME/lists
and in line 1049 in mailman_transport you have to change $local_part to
$local_part_data
(weirdly those lines do not work in my Exim 4.92, but I did not
investigate that further)
I did not come across other issues so far, but I also made several
changes to my exim4.conf over the years. So I have some significant
differences to "vexim2/docs/configure" in my current configuration.
EDIT: To clarify, this is only applicable for Mailman2 that is currently supported by the example configuration
Am 12.01.2024 um 14:08 schrieb runout-at:
…
I'm fine with doing a new release.
As Exim had a mayor change in the last years (since last vexim
release): Did anyone check if vexim has to change something for that?
At least the variables $local_part and $local_part do not work as
before as I remember. It's some time since I did this on my server.
—
Reply to this email directly, view it on GitHub
<#233 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOF77HEC3FSHSHRZVOXAMLYOEYV7AVCNFSM4C4NTH7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYHEYTKNJUGI2Q>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
|
|
I'm going through my old PRs now. some are partly obsolete as functionality has been included into the default config (at least in Debian). So it' should be easier to include those features in Vexim. Shall we do this with this new release?
|
What do you think of releasing a version 2.3.1 soon? I think we already merged some nice fixes and with the recent problem of the removed
demimein Exim 4.88 we risk to run into many complaints in the future (e.g. new Debian this year). We won't be able to do everything scheduled for 2.3.1, but I'd like to review your Mailman-fixes and also properly integrate a LMTP transport (without integration in web interface or database).@rimas-kudelis
The text was updated successfully, but these errors were encountered: