Notes 22 Jan 2018
ellie: * will be in office tomorrow - setting up build environment on new laptop* need to discuss JMAP in 3.0 Partha: * most of last week was spent on zeroskip - have iterators for both in-memory and multiple types of on- disk format - locking in place - code is on cyrusimap github repo * last couple of weeks didn't have Bron around, but back now * this is a short week (Australia Day on Friday) and off for 3 days next week Robert: * jscalendar - RFC draft is v5 now. - confident that it's ready for acceptance - off the list discussion about tasks details - waiting for more feedback on tasks: when tasks start - at the moment we can track when a task is completed, but not when work started - next step - official call on Calsify list * Ken - giving it a slow careful read - will be done by next week (CalConnect)* Robert will update slides for Ken to use for presentation * Ken and Mike will discuss parameters on properties for tasks * JMAP in 3.0 - why remove it? - best thing to do - not only about format of JMAP request envelopes, but also data inside it. - will make people unhappy if they build applications on top of an API which has been outdated for months. - Bron approves * Have two feature branches in limbo. * smtp API rewrite - was asking about SMTP authentication on TCP-based backends. - suggest just pushing to master as is - for SMTP authentication - just put in config file - can include a file with more sensitive data* index attachments - people at FastMail have been on leave, hence lack of movement * JMAP code refactor - currently concentrating efforts on - started last week - generally looks fine - would like to show a prototype next week for at least one type of JMAP method call to decide how to go forward - would like to generalise validation code - thinking about implementing poor-man's JSON-schema validation Bron: * just got back from being away for 2 weeks. Testing append cost on large mailboxes: * test appending on mailboxes with different scale of messages (10, 100, 1000, etc...) and see how performance scales.* Robert will look at. Ken: * finally got laptop where it needs to be after replacing hard drive (Windows partition booting)* had to reinstall Linux - back to where Cyrus build works. * wasted more of the week than wanted to * working on some FastMail tickets as well * Bron - bug Apple and Google people about bugs in their products at CalConnect!* This week - preparing slides on sharing and proxying/delegation to get a discussion going - make sure VPOLL works so Mike and Ken can do a demonstration - next week? Change time of call? - make Australian early morning? - tibbs, nic maybe. NEXT WEEK: Tuesday 8am Melbourne == Monday 1pm for Ken == Monday 10pm for Robert. (UTC 2100) Nicola: * wanted to know if JMAP 3.0 was out, tibbs wanted to know. Hadn't clearly communicated to list. - Robert will mail list to explain what's happening. - or ellie, as release manager. * want to make sure west/central US aren't left out all the time, so maybe do alternating meeting times. - don't have regular contributors outside FM right now - might be more if we do more outreach - invite people to the meetings - Ken will invite people - figure out if we want to alternate times. - we also know who we've been dealing with, so individual invites can be made too - ellie from bugs/list. - be nice to get 3.0 / 3.2 into next major releases. * coverage on IRC channel - Ken needs a better client (popups, etc). Ditto Robert. - irccloud is good for phone - also has bouncer - why not use slack for Cyrus? Hard for drive-by people, non-open- source, etc. - on the flip side, lots of idle people on IRC who might not really be around. - people who want to administer Cyrus - maybe happier staying with IRC. Calconnect: * Robert - be good to talk to Peter from Ribose * Nicola - would like to write up ideas about what would be good to see in calendars* Per-user vs shared calendars, how delegation is supposed to work SASL release: * the guy who's been testing GSSAPI issue will try to get back to it this week - just moving slowly.* Ken isn't GSSAPI expert and doesn't have infrastructure any more -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
Re: Notes 22 Jan 2018
Always wanted to join in the Cyrus meetings but the time was inconvenient/awkward/when you were sleeping? Next week's meeting is at a different time! Monday 9pm UTC Monday 1pm PST Monday 4pm EST Monday 10pm Vienna Tuesday 8am Melbourne We'd love to see you there. Let's talk about packaging for your favourite operating system. Let's talk about your desire for a particular feature. Let's talk about bugs. Let's talk about how you've always wanted to contribute but aren't sure where to start. Let's talk about Cyrus around the world! On Mon, Jan 22, 2018, at 10:47 PM, Bron Gondwana wrote: > ellie: > * will be in office tomorrow - setting up build environment on new > laptop> * need to discuss JMAP in 3.0 > > Partha: > * most of last week was spent on zeroskip > - have iterators for both in-memory and multiple types of on-disk > format> - locking in place > - code is on cyrusimap github repo > * last couple of weeks didn't have Bron around, but back now > * this is a short week (Australia Day on Friday) and off for 3 days > next week> > Robert: > * jscalendar - RFC draft is v5 now. > - confident that it's ready for acceptance > - off the list discussion about tasks details > - waiting for more feedback on tasks: when tasks start > - at the moment we can track when a task is completed, but not when > work started> - next step - official call on Calsify list > * Ken - giving it a slow careful read - will be done by next week > (CalConnect)> * Robert will update slides for Ken to use for presentation > * Ken and Mike will discuss parameters on properties for tasks > * JMAP in 3.0 - why remove it? > - best thing to do - not only about format of JMAP request > envelopes, but also data inside it.> - will make people unhappy if they > build applications on top of an > API which has been outdated for months.> - Bron approves > * Have two feature branches in limbo. > * smtp API rewrite > - was asking about SMTP authentication on TCP-based backends. > - suggest just pushing to master as is > - for SMTP authentication - just put in config file - can include a > file with more sensitive data> * index attachments > - people at FastMail have been on leave, hence lack of movement > * JMAP code refactor > - currently concentrating efforts on - started last week > - generally looks fine > - would like to show a prototype next week for at least one type of > JMAP method call to decide how to go forward> - would like to > generalise validation code - thinking about > implementing poor-man's JSON-schema validation> > Bron: > * just got back from being away for 2 weeks. > > Testing append cost on large mailboxes: > * test appending on mailboxes with different scale of messages (10, > 100, 1000, etc...) and see how performance scales.> * Robert will look at. > > Ken: > * finally got laptop where it needs to be after replacing hard drive > (Windows partition booting)> * had to reinstall Linux - back to where Cyrus > build works. > * wasted more of the week than wanted to > * working on some FastMail tickets as well > * Bron - bug Apple and Google people about bugs in their products at > CalConnect!> * This week > - preparing slides on sharing and proxying/delegation to get a > discussion going> - make sure VPOLL works so Mike and Ken can do a > demonstration > - next week? Change time of call? > - make Australian early morning? > - tibbs, nic maybe. > > NEXT WEEK: Tuesday 8am Melbourne == Monday 1pm for Ken == Monday 10pm > for Robert. (UTC 2100)> > Nicola: > * wanted to know if JMAP 3.0 was out, tibbs wanted to know. Hadn't > clearly communicated to list.> - Robert will mail list to explain what's > happening. > - or ellie, as release manager. > * want to make sure west/central US aren't left out all the time, so > maybe do alternating meeting times.> - don't have regular contributors > outside FM right now > - might be more if we do more outreach > - invite people to the meetings > - Ken will invite people - figure out if we want to alternate times.> - > we also know who we've been dealing with, so individual invites > can be made too - ellie from bugs/list.> - be nice to get 3.0 / 3.2 > into next major releases. > * coverage on IRC channel > - Ken needs a better client (popups, etc). Ditto Robert. > - irccloud is good for phone - also has bouncer > - why not use slack for Cyrus? Hard for drive-by people, non-open- > source, etc.> - on the flip side, lots of idle people on IRC who might > not really > be around.> - people who want to administer Cyrus - maybe happier > staying with > IRC.> > Calconnect: > * Robert - be good to talk to Peter from Ribose > * Nicola - would like to write up ideas about what would be good to > see in calendars> * Per-user vs shared calendars, how delegation is > supposed to work > > SASL release: > * the guy who's been testing GSSAPI issue
Notice: removal of JMAP support from stable Cyrus IMAPd 3.0.x series
Hi all :) We've decided to remove the experimental JMAP support from the stable Cyrus IMAPd 3.0.x series. This is a minimally-invasive change, which won't affect other aspects of the software. The motivation for this is the rapid evolution of the JMAP specification as it moves toward formal standardisation. The changes required to keep the 3.0.x implementation current are far too invasive for a stable release, but letting it stagnate in place would only clutter up the JMAP ecosystem with incompatible implementations. So, JMAP support will no longer be available in a stable release as of 3.0.6. JMAP support will continue to exist in its rapidly-evolving fashion in the master branch and the 3.1.x development snapshots (these exist only as tags within the repository, they are not formal releases). We expect JMAP to be standardised and fully supported in the 3.2.x stable series. What you need to do: * if you're not using JMAP: nothing! But you can read about it, if you like, at: http://jmap.io :) * if you're running an experimental JMAP service: either track the master branch, or the 3.1.x development snapshots * if you're running a production JMAP service: you probably know more about it than me... * if you're developing/testing JMAP client software: track the master branch, join the JMAP mailing list * if you're a package maintainer: as above, depending on whether your package is oriented toward stable/production usage, or bleeding-edge/development usage More information about JMAP is available at: http://jmap.io And the status of the IETF Working Group is available at: https://datatracker.ietf.org/wg/jmap/about/ Cheers, ellie
Notice: removal of JMAP support from stable Cyrus IMAPd 3.0.x series
Hi all :) We've decided to remove the experimental JMAP support from the stable Cyrus IMAPd 3.0.x series. This is a minimally-invasive change, which won't affect other aspects of the software. The motivation for this is the rapid evolution of the JMAP specification as it moves toward formal standardisation. The changes required to keep the 3.0.x implementation current are far too invasive for a stable release, but letting it stagnate in place would only clutter up the JMAP ecosystem with incompatible implementations. So, JMAP support will no longer be available in a stable release as of 3.0.6. JMAP support will continue to exist in its rapidly-evolving fashion in the master branch and the 3.1.x development snapshots (these exist only as tags within the repository, they are not formal releases). We expect JMAP to be standardised and fully supported in the 3.2.x stable series. What you need to do: * if you're not using JMAP: nothing! But you can read about it, if you like, at: http://jmap.io :) * if you're running an experimental JMAP service: either track the master branch, or the 3.1.x development snapshots * if you're running a production JMAP service: you probably know more about it than me... * if you're developing/testing JMAP client software: track the master branch, join the JMAP mailing list * if you're a package maintainer: as above, depending on whether your package is oriented toward stable/production usage, or bleeding-edge/development usage More information about JMAP is available at: http://jmap.io And the status of the IETF Working Group is available at: https://datatracker.ietf.org/wg/jmap/about/ Cheers, ellie Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
