Hello Ellie, your personal problems are mentioned for quite some time now. I do not know the details, but I personally wish you to recover soon permanently. In any case, this thread is not about you.
The accent is about finding a way where contributions are considered in a timely manner. Currently it is absolutely unclear and unpredictable, whether submitted fixes, being clarifying the documentation, adding features or fixing bugs will be consideted for intergration, so that other users can benefit from them. Whatever conditions are fulfilled, it is still unpredictable. This uncertainty questions whether it makes sense to contribute upstream to make cyrus imap better. As an example, uploading a meeting with ATTENDEE;CN="A, B":mailto:b.a@examle.orggenerates an email/iMIP invitation with: To: A, B <b...@examle.org> which is converted by the MTA/MSA in To: A@thisdomain, B <b...@example.org> which is wrong. Correct is: To: "A, B" <b...@examle.org> https://github.com/cyrusimap/cyrus-imapd/pull/2693 contains a fix from April 2019. The question is not what happened with this particular example, but how to avoid such stalls in the future. Besides if a long time passes between a notice on github and a reaction, the one who wrote the notice might not remember anymore the details and this complicates the situation more. A further challenge, that needs to be approached, on which contributors have no impact, is that most users do not run the “master” version, but a stable one and in turn the provided patches are towards the stable version. In some parts, the master and stable versions have diverged significantly and continue to diverge further. Regards Дилян On Tue, 2019-07-30 at 09:28 +1000, ellie timoney wrote: > On Mon, Jul 29, 2019, at 11:10 PM, Anatoli via Cyrus-devel wrote: > > There are a lot of issues with both 3.0, 3.1 and 3.2 tags (some even have > > 2.5 tag), it's not clear which are scheduled to be closed for which release. > > > > The tags for existing versions (i.e. 2.4, 2.5, 3.0, 3.1) indicate which > versions are known (or suspected) to be affected by those issues, but they > don't indicate any particular release schedule for fixes. > > The 3.2 tag currently indicates stuff we definitely need to fix/implement on > master before forking the 3.2 stable branch, but after this occurs the 3.2 > tag will continue like the rest. > > The main person working through the github issues tracker is myself, but I've > been working reduced hours for medical reasons for quite a while so there's > some weeds growing. Sorry about that!
