<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>I think it's been since July that we've not posted any minutes from the regular developer's Zoom call.  This was basically fallout from some rescheduling and tool changes, but it's still not great.  Sorry about that!  Let's get this going again.<br></div><div><br></div><div>Today (2020-05-11 đź‡şđź‡¸) in attendance:  Bron, Ellie, Ken, Rik, Robert<br></div><div><br></div><ul><li>ellie<br></li><ul><li>Travis has been testing the wrong branches â€” generally always master instead of version or feature branches<br></li><li>Also, Cassandane make failures were unreported.<br></li><li>Partha did a ton of work and this should be fixed.</li><li>Travis is mostly just failing on Sieve.snooze_tzid - might add that to the disabled tests list.<br></li><li>Getting lots of bug reports for 3.2: all the things not tested during the RC/beta period<br></li><li>Marco found that syslog interception doesn’t work on Redhat system.  Would be good to fix it for future Cassandane users.<br></li><li>Oh yeah, 3.2 is out!  Only 2 months late.  3.4 for March 2021.  Feature freeze end of 2020.<br></li></ul></ul><div><br></div><ul><li>Robert<br></li><ul><li>Big features like attachment indexing - always pushed on master.  e.g. if 3.2 users do attachment indexing then we have to tell them to reindex everything when they get to 3.4.<br></li><li>The plan going forward will be to keep big features on long-lived feature branches while they're developed, and only in master when proven out.  (This will often mean "has run on Fastmail for a long while under real user load".)<br></li><li>The new build and deploy systems will make this much easier to manage.</li><li>Basic plan is to include branches with particular labels in the final build.  This will be similar to the current Fastmail branch building stuff.  The Fastmail builder will also be able to look at our private gitlab if we want to build anything in secret.<br></li><li>Was looking into a possible split-conversations bug, has been transferred to Bron.<br></li><li>Hoping to get JSCalendar done by June, so have been spending time on that.<br></li><li>Went down a rabbit hole of looking at how languages are stored in Xapian.  Now much simpler.<br></li><li>Implemented a way to recalculate xapian language counts exactly.  Can always recalculate language counts.<br></li><li>Close to getting to code review for attachment indexing. <br></li><li>Now API can set â€śindex level” on Xapian document - can allow for partial indexing.  Bron suggests adding headers to the level data too.<br></li></ul><li>Ken<br></li><ul><li>Hopefully this week subscriptions for mailbox storage by UUID get finished<br></li><li>Added JMAP Backup tweaks that Fastmail requested - adding options to restore or not restore drafts.<br></li><li>Sieve work!</li><ul><li>Added timezone argument to Sieve snooze - not sure if it’s been tested other than in Cassandane.  [ed.: not yet!  Fastmail Sieve generator needs an update first]<br></li><li>Did more hacking around Sieve!  Rewrote bytecode parser to use a lookup table.<br></li><li>Broke and then fixed vacation fcc.<br></li><li>Started deprecating old non-standard sieve stuff. (mark/unmark, etc)<br></li><li>We’re still using legacy notify - hopefully we can switch to enotify and start deprecating it.  Rik will talk to Ken about transition plan for Fastmail.<br></li><li><div>Been working on making a sieve decompiler that can convert bytecode into scripts again.<br></div><ul><li>Might be hard to tell the difference between â€śelseif” and â€śelse { if {} }”.<br></li><li>But it doesn’t need to be exact, just readable to see what was there.<br></li></ul></li></ul></ul></ul><div><br></div><ul><li>Bron:<br></li><ul><li>Wondering if we can â€śautodetect” that a user wants header indexing by seeing the queries they run and turn it on / flag them for reindex.<br></li><li>Talking to CMU about getting DNS transferred to Fastmail server where we can do better website hosting setup.<br></li></ul></ul><div><br></div><ul><li>Rik<br></li><ul><li>ideally, this week we will finish and begin using new-style Cyrus builds, which will mean some changes to the policy about "what goes on master" â€” will email when we get there<br></li><li>other than that, all Cyrus work has just been doing routine deploys</li></ul></ul><div><br></div><div id="sig65535536"><div>-- <br></div><div>Ricardo Signes (rjbs)<br></div></div><div><br></div></body></html>