Updating Cyrus Bylaws

[Dilyan Palauzov]

Thanks Bron,

for your extensive answer.

For me it is still unclear, providing that PRs are good idea, why  
trusted developers don't have to create them.  There are also some PRs  
older than a year, so it is just not foreseenable if a patch will be  
integrated in reasonable time, and in turn, if it makes any sense to  
share a particular patch.

9937c5f4cb37ac2d52600f0ae77488dc0f54e80c (imap/tls.c) and  
0a60b82f0cd3e706f628a6900a675f4326296683 are two examples, which were  
fixed on master, but were not backported.  I suspect there are more  
such commits.  I can say that something was not backported, only after  
I rediscover the problem myself on cyrus-imapd-3.0, find how to  
correct it and check if it was fixed on the master branch.

Is it feasible to prepare 3.2 soon without JMAP, but with all the DAV  
and IMAP improvements and release later stable with JMAP, when it is  
ready?

Greetings
   Дилян

----- Message from Bron Gondwana <brong at fastmailteam.com> ---------
    Date: Mon, 27 Aug 2018 09:40:37 -0400
    From: Bron Gondwana <brong at fastmailteam.com>
Subject: Re: Updating Cyrus Bylaws
      To: Cyrus Devel <cyrus-devel at lists.andrew.cmu.edu>


> On Mon, Aug 27, 2018, at 09:49, Dilyan Palauzov wrote:
>> Hello,
>>
>> isn't it time to update the Cyrus Bylaws  
>> https://www.cyrusimap.org/overview/cyrus_bylaws.html ?
>
> Perhaps.  This is the first time it's been raised in my memory, at  
> least since we last updated them.  We do have a plan to update code  
> licensing and possibly rehome the websites and copyrights, since CMU  
> no longer have a strong interest in maintaining the project.
>
>> 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
>
> Now that we're using Github for everything, the trivial process is  
> the normal trivial process for making changes in most Github  
> projects - create a branch in your own copy of the repo and open a  
> pull request.  And maybe a pull request against Cassandane as well  
> if it is something which needs tests or updates tests.
>
> I'd love to see pull requests for trivial fixes, so we can just  
> click a button to accept them rather than having to transcribe them  
> into code ourselves.
>
>> 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.
>
> "fix bugs" is very subjective.  Sometimes even something that looks  
> like a trivial bugfix is actually wrong, and sometimes it's a pain  
> to backport because internals have changed sufficiently.  We try to  
> backport important bugfixes, but bugfixes to new functionality or to  
> subsystems which have changed significantly are harder to backport.   
> This is particularly true for oldstable of course. 3.0 and 3.1  
> aren't so much diverged yet.
>
> Particularly with C, what looks like a little fix can introduce an  
> ugly memory leak or use-after-free.  We've had plenty of them when  
> ostensibly "cleaning up" code or indeed, fixing compiler complaints.
>
>> 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.
>
> I have found with my interactions with open source projects that  
> this is a two-way street.   You might be lucky and get someone at a  
> good time and they help you a lot.  Other times, you got them at a  
> bad time and need to remind them.  Our bugtracker is full of a ton  
> of issues of various sizes, some old, some new.  Many are real bugs,  
> but nobody really cares about them (I suspect many of the NNTP  
> issues fall under that heading).  Other issues are really important,  
> but a ton of work and nobody has got to them yet.
>
>  We instituted a "diceroll" process a while back, to go through some  
> of those old issues and close them out.  Sometimes that led to good  
> things, sometimes it led to a "fix" that actually made things worse  
> and had to be repaired again.
>
> Overall, we try to handle things within a reasonable time, but  
> please do remind us occasionally if we've missed something that you  
> think is important.  Humans are forgetful, and once things become  
> old enough, they're hard to distinguish from the rest of the  
> detritus in the bugtracker.
>
>> 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  
>> persons.
>
> I think there's some misunderstanding of "trusted" vs "untrusted"  
> here.  We have a big problem at the moment that most of the  
> contributors are FastMail employees so it's easy for FastMail  
> employees to get trusted - not so much for other people.
>
> But the general meaning of "trusted" is more "understands the  
> architecture well enough that changes will be congruent, and  
> understands the testing frameworks well enough that commits will  
> mostly be well tested".  There's also a big side order of "has  
> committed to hang around and be available to fix their commits if  
> they break".
>
> Again, that's easier from FastMail staff because I'll stop paying  
> them if they don't fix their mistakes!  It's harder when we take  
> something large and not well architected (the mboxevents module is  
> probably the most notorious  case in the past decade) and it causes  
> ongoing maintenance headaches.  So we do have to evaluate committers.
>
> I'd be happy to accept additional contributors who are showing up to  
> the public meetings we hold once per week and collaborating with the  
> team.  I'm loathe to add people with commit rights  who only  
> communicate by dropping large chunks of code that haven't been had  
> the design socialised with the rest of the group first, because that  
> leads to a fragmented codebase.
>
>> 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. 
>
> I agree.  Please do tell us when you hit such issues.  We're not  
> doing much on those subsystems on master, and we do try to backport  
> them where they seem to be independent issues and not side effects  
> of the JMAP subsystem changes.  But I'm sure we miss them sometimes.
>
> Since JMAP is a key project for FastMail, and the people doing the  
> bulk of the work right now are being paid by FastMail, clearly JMAP  
> is getting the bulk of development.  Once JMAP is final, we expect  
> to cut another stable release, and then focus on cleanups and  
> optimisations.
>
>>  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.
>
> We always go through phases of this.  We were backporting everything  
> to 3.0 for a while, but then master diverged sufficiently.  There  
> are now new features in 3.1 (e.g. SAVEDATE and STATUS=SIZE) which  
> depend on index format changes which will never be backported to  
> 3.0.  It was also unfortunate that there was an upgrade bug that  
> hurt the 3.0 series for a while.
>
> But I expect that once 3.2 comes out, again there will be a flurry  
> of backported fixes to the 3.2 stable series, followed by a while  
> where there's high churn on the master branch, and only key bugfixes  
> backported.  That's a normal open-source project lifecycle.  Right  
> now we're in the unstable, high churn section where there's no much  
> that's both important enough and unentangled enough to justify  
> backporting.
>
>> 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?
>
> I will leave this for Ken to answer, as SASL is more his  
> department.  I believe the blockers were waiting on testing to  
> ensure there wasn't any regression - the cyrus-sasl code doesn't  
> have a comprehensive test suite.
>
> Regards,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   brong at fastmailteam.com


----- End message from Bron Gondwana <brong at fastmailteam.com> -----