Updating Cyrus Bylaws

Dilyan Palauzov Dilyan.Palauzov at aegee.org
Sun Aug 26 19:49:16 EDT 2018


isn't it time to update the Cyrus Bylaws  
https://www.cyrusimap.org/overview/cyrus_bylaws.html ?

Here my wishes:

The process of doing trivial changes must be trivial.  A hint shall be  
sufficient for this change in  
docsrc/imap/reference/manpages/systemcommands/rehash.rst :
-    **rehash** [**-v**] [**-n**] [**-f**|**-F**] [**-i**|**-I**] imapd.conf
+    **rehash** [**-v**] [**-n**] [**-f**\|\ **-F**] [**-i**\|\  
**-I**] imapd.conf

Write down, that doing changes on master that fix bugs on the stable  
branch shall be applied on the latter without having explicit  
inviation.  In fact I do not think this belongs to the bylaws, but as  
the approach is not applied, it shall be stated somewhere.

It must be foreseenable when one writes a ticket, whether the case  
will be handled within reasonable time.  What means reasonable time,  
is subject to discussion but one year is more than reasonable time.  I  
wrote once upon a time a ticket that cyrus-sasl/configure --help  
prints twice --with-pam and then cyrus-sasl/configure.ac was fixed to  
emit --with-pam only once, then this fix disappeared, I wrote on this  
at github; nothing happened, and I don't understand why this happened,  
why is it necessary to escalate on this here and so on.

The process how it is to distinguish between trusted and untrusted  
contributors needs to be defined clearer.  While a trusted person can  
directly do the changes s/he wants, an untrusted person has not much  
motivation to work on things, where s/he is mistrusted.  In any case,  
untrusted persons shall not have it harder to contribute than trusted  

I understand that for some of you JMAP support is very interesting,  
for others having IMAP/WebDAV/CalDAV/CardDAV where known problems are  
fixed on master, but are not on the stable branch is suboptimal.  My  
preference is to have soon stable release with any fixes for  
IMAP/WebDAV/Sieve that were not backported and have later a release  
with JMAP/multi-master/better backup when these are ready.  And from  
that moment on take care that any fixes relevant for  
IMAP/WebDAV/Sieve/something else are backported to the stable branch,  
while development for JMAP or (new RFCs) goes on master.

Are the concerns raised recently by Quanah the only blockers for cyrus  
sasl 2.1.27 and what reasons prevent releasing cyrus sasl 2.1.27  
within two months?


More information about the Cyrus-devel mailing list