<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><div>Largely unedited, here are the minutes from this morning's dev call:</div><div><br></div></div><ul><li><div>murch <br></div><ul><li><div>discussion of expanded header search semantics (prefix/suffix/substr match)<br></div></li><ul><li><div>it's unclear whether we need or want this, given the yet unknown cost v. complexity v. benefit ratios<br></div></li><li>This isn't Xapian related at all, we'll be processing fields from the cyrus.cache.<br></li></ul><li><div>Discuss replication of JMAPSieve script ids <br></div><ul><li>Given our current replication protocol, SieveScript object ids will not replicate. <i>Does this matter?</i> (This is: replicas will have the same script with a different id.)<br></li><li>First: <i>does</i> it get replicated? We need to double-check that it doesn't, but consensus seems to be that it isn't replicated.<br></li><li>We should fix it, if it isn't replicated, but we don't really <i>care</i> as far as Fastmail operation is concerned. It won't affect user-visible behavior.<br></li></ul></li><li><div>Discuss expectations of cyr_ls <br></div><ul><li>always use unixhierarchysep?<br></li><li>let's use admin namespace<br></li><li>(we have other tools that use internal ns, it's been a pain, and we're fixing it as we go)<br></li></ul></li><li>fixed cross-domain searching (new term added to Xapian)<br></li><li>still waiting on CR for 8bit characters in C-D<br></li></ul></li><li><div>ellie <br></div><ul><li>PR #3166 contains code from OpenBSD, NetBSD, DragonflyBSD and FreeBSD's top(1) utilities (for turning process state flags into human-readable strings). Can we accept this? — We think so.<br></li><li>we should be expecting lots of small MRs for xsyslog conversions<br></li></ul></li><li><div>rjbs <br></div><ul><li>we're working on cyrus ML conversion; waiting on Dave<br></li></ul></li><li><div>brong <br></div><ul><li>locking! conversationsdb has locking problems, annotations are "a whole locking nightmare"<br></li><li>there's a lock inversion between JMAP and other calls in the locking of convdb vs. mailboxes<br></li><li>we can change how convdb locking works internally so you can take/release a lock without closing the entire db, add a user lock, then we're done!(?)<br></li><li>…but it's a bunch of work, and that will be Bron's next project for Cyrus<br></li><li>but this week is CalConnect week<br></li></ul></li></ul><div><br></div><div id="sig65535536"><div>-- <br></div><div>Ricardo Signes (rjbs)<br></div><div>CTO, Fastmail<br></div></div><div><br></div></body></html>