Updating Cyrus Bylaws

[Bron Gondwana]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20180827/ca43126f/attachment-0001.html>