Minutes 11 May

[Bron Gondwana]

So I haven't written up notes for a while, but we've been ticking
along doing our regular meetings every Monday (11am GMT) and Thursday
(midday GMT).

That means the next one is 2015-05-14T12:00:00Z at:
https://plus.google.com/hangouts/_/g4xnqjjb5zvomzeb4kqvja3fz4a
Freenode #cyrus

Today's meeting had: Chris, Conrad, Ellie, Ken, Nicola, Simon and Bron
(in the alphabetical order that the pictures at the bottom of Hangouts
are for me)

Congratulations Ellie for releasing 2.5.2.  Man it took a long time.
Next time is going to be heaps faster because we have a process sorted,
so get your small bugfixes in so we can knock out a whole bunch of them
and get the process really smooth.

Speaking of processes - we're still getting assert failures on shutdown
in httpd at FastMail when the kill_user_connections script sends SIGQUIT
to a user's processes (as happens on password change and for a few other
reasons).  It's caused by auth_{cal|card}davdb.  This database stays
open as an optimisation in case the process handles another request for
the same user, so we can either always close it, or just shut the
database if given a sigquit.  Bron and Ken are both going to look into
this one, because there's nothing like doubling up on work ;)

I spoke (mixing third and first persons like this email) about rewriting
the entire cyrus.index and about 5 other custom formats as a single per-
user (well, per nameroot) SQLITE database or similar.  Downside might be
worse performance, the killer win for Cyrus has been the fact that an
O(N) algorithm with a really tiny constant can be a lot faster than a
O(log N) algorithm with a heaps higher constant up to quite large N,
particularly once you take cache effects and readahead into account.  So
we're going to need to do some benchmarks here.

Sieve: Ken has reached out James Cassell to help get his pending
variables and other sieve patches committed to master.  We have been lax
in dealing with these, which is bad - because we love other people doing
good work, and we need to encourage it!  Thanks James.

Conrad - has been looking at T80 - compile errors on some Centos with a
compiler which #defines 'const' away because the compiler doesn't
support it.  We're just going to ditch that, if your compiler doesn't
support const, get a new compiler. We already agreed to require c99
(well, gnu99) support.

Also, Conrad has OpenIO running locally now, and is waiting to hear more
about how to use the C interface library to talk to it.  Hopefully soon.

Has been reading the IMAP spec some more.  Heaps of stuff in there.  We
chatted about Alexey's new IMAP4rev2 draft, which basically adds all the
extension that everyone agrees is a great idea into IMAP4rev1 and
removes a couple of things that everyone agrees are bad ideas.  A big
step back from IMAP5, but achievable and means that people claiming to
support IMAP need to be a little better before being laughed at.

Simon: not much, but suggested we put the release date on release notes.

Website - the situation with cyrusimap.org and cyrus.foundation is
awfully confusing. Somebody needs to take ownership for uncrapping this.
Nobody put their hand up yet, so we'll see if it happens by Thursday or
I might start appointing people ;)

Speaking of naming - cyrusfoundation == http://www.cyrusfoundation.org/
== not us.  We need a new name.  Cyrus IMAP Foundation -> two imappy.
Cyrus Mail Foundation -> not enough cal/carddav.  "Cyrus Connect" -
doesn't someone already own "* Connect"?  But maybe.  reCyrus /
librecyrus / "recycle".  Hmm...  Great names greatly appreciated.  Make
your mark here, but don't make it a trademark that somebody else has
already... yeah, that.  *sigh*.  All the good ones are taken or insane
(or both).

Chris - been working on trying to follow the instructions as someone who
doesn't already know how to do things, and getting appropriately
confused at the places that the docs are suboptimal.  Yet more of the
"we need to improve documentation even more than we need to improve
code".  He will continue to work on this path for the next couple of
days, with Nicola helping improve the docs.

Right now there are various README files of various quality and
usefulness, and a lot of docs in different formats scattered around the
project, with no clear idea of where to go for what problem.

And Bugs... do they go in Bugzilla, or Phabricator?  How do users know?
What do we do for existing bugs in Bugzilla?  Conclusion was to close
bugzilla for new bugs.  Maybe have to get Dave to do this.

Bron.

-- 
  Bron Gondwana
  brong at fastmail.fm