Meeting not happening this week

[Bron Gondwana]

The Cyrus meeting time runs pretty much into the start of the JMAP session at 
IETF, so you should all show up there instead (in person or virtually)
https://datatracker.ietf.org/wg/jmap/meetings/

We're also considering whether to run a second meeting every week at a time 
more suitable to US West Coast people - it would be Australian morning and US 
afternoon/evening, and probably not suitable for Europeans.  Let me know if 
this is something you're interested in.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com

Re: Future of Cyrus-SASL

[Ken Murchison]

On 07/12/2017 09:10 PM, Quanah Gibson-Mount wrote:

Hi Bron, Ken, Jan,

That's excellent news!  I look forward to the RC and putting it 
through its paces. ;)  Are there additional resources beyond Ken that 
will be working on the SASL project?


Alexey Melnikov still has commit access, but I'm not sure how much 
development time he has at the moment given that he is once again an 
Area Director at IETF.






--Quanah

--On Thursday, July 13, 2017 11:19 AM +1000 Bron Gondwana 
 wrote:




Thanks Jan,



I wonder if we want to set up a second meeting time, either fortnightly
or weekly, that does the other cross over and allows us to more easily
include middle and west America.  Our current meeting time is 10pm for
Australia, so something that was during the Australian day and
afternoon/evening across the USA would work fine for everybody except
Europeans.



As Ken has already noted - we still want to support SASL.  Now that we
have him full time, he's going to release a new version, and at our
scheduling meeting on Monday, Nicola bumped up the priority of updating
the SASL documentation and converting it to the sphinx-based build 
system.




Regardless of whether Cyrus-* leaves CMU (which is still being discussed
with both CMU and potential new homes), the project intends to keep
supporting SASL.



Bron.





On Thu, 13 Jul 2017, at 09:40, jan parcel wrote:


On problem I have is that people in imap development seem to say 
(and, on
the web, too) that cyrus-sasl means imap, leaving cyrus-? to mean 
libsasl?




Other than that



I cannot volunteer as a regular contributor because my  regular job uses
up all my time.  However, company policy requires us to send "upstream"
all relevant bug fixes we create, and to file bugs we find to upstream
regardless of whether or not we need to fix them -- for instance,  I
might never fix the bug with  failing to exclude ldapdb when so
configured,  unless a customer demands that plugin, which I suspect will
not happen.We are also required to SECRETLY and SECURELY report
security bugs upstream.



Company policy definitely encourages us to have a relationship with
upstream developers.



But I'm also in the U.S. west coast timezone (Pacific Time) and 4am is
not doable for me except in extreme emergencies (such as a high-scoring
CVE that needs immediate attention, for instance.)



So,  I don't quite know what you will find acceptable in the way of
participation from me, but I want to be cooperative to a libsasl
community and contribute where I can, and participate if there are
meetings that I can reasonably attend.  I'd say times between 6:00 AM -
1AM would be doable.



And if the libsasl project were to lose all upstream support, I would be
required to report that to my management, and abide by any decisions 
they

make wrt whether to look for a supported alternative.



sendmail can also profitably use libsasl2.



So, thanks for including me in this thread.



Jan Parcel

Software Developer

Oracle Systems Server & Cloud Engineering











--

  Bron Gondwana, CEO, FastMail Pty Ltd

  br...@fastmailteam.com








--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:




--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd