On Sunday, April 15, 2012 01:18:55 PM Dave McMurtrie wrote: > Maybe we can all get together on IRC and talk about CalDAV and 2.5. >
Yes, CalDAV is one of those enhancements I don't believe currently has a ticket + blocking dependency yet, right? > Ken is very close to having the initial CalDAV implementation done. We are > attending the CalConnect InterOP session near the end of May. We were > thinking that by some time in June he will be ready for an alpha quality > release that will include all the initial features including server-side > scheduling support. > > Currently his code only works for 2.4. We obviously don't want to do an > alpha release of a major new feature as part of a minor version 2.4.x > release. Ken and I discussed the possibility of doing an initial alpha > release of his code as a separate download, so you could either download > the usual cyrus-imap-2.4.14.tar.gz or > cyrus-imap-caldav-2.4.14-alpha.tar.gz. The idea would be that we would > release this alongside each minor 2.4.x release as an alpha, then > incorporate it into either 2.5 or 2.6. > > Thoughts? > Plenty of thoughts, of course ;-) Let me try and put them in writing. I'm thinking out loud with the following assumptions: - CalDAV is here to stay -thus ends up in mainstream at some point. Perhaps a d'oh. - CalDAV can be enabled / disabled during compile time, in a fashion that does not impact runtime (or runtime's stability, if you will). - Rebasing CalDAV on top of master is major effort, and thus time, and - Waiting longer is only going to increase that effort. That said, I'm thinking of the following conditionals: - Depending on how much we want in 2.5 (as opposed to postponing some of it to 2.6?), there may not be enough time for CalDAV in 2.5 - other people are better capable of saying that's true or false, than I am. - If CalDAV can be made to, ./configure --enable-caldav style, not impact runtime's stability for non-CalDAV builds, merging into master before 2.5 is the way to go. I'm fairly certain we only have to be reasonably confident here. I'm also fairly certain that given enough pre-releases (development snapshot releases), we can get away with unstable software fairly reasonable - perhaps, arguably, changing the Cyrus IMAP mantra from stable-stable-stable to release-early-release-often and maybe even "step up, or shut up". - Once CalDAV is out there, with up to 7 billion users using it, what do we estimate the support effort is going to be? The point being; If we can say now, that it is going to be "too much", I suspect that also answers the question of whether CalDAV is supposed to be in 2.5. If it's more like "difficult to catch up with", we have a reasonable road to salvation. I welcome the initial alpha release idea. In fact, I'd like to explore doing such releases (as with enhancement tickets for 2.5 being released in development snapshots) *regardless* of whether the code is based on 2.4 or 2.5. Such releases, after all, are for the sole purpose of testing and ironing out the kinks. I suppose there's going to need to be some time for a test suite like Cassandane to catch up with CalDAV development as well. A final thought is that, if we do cyrus-caldav releases, we can also create a Cyrus CalDAV product in Bugzilla, for beyond-mainstream -those too can be merged back. CalDAV releases could then move forward at their own pace as well, i.e. 2.4.14.1, 2.4.14.2 releases. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
signature.asc
Description: This is a digitally signed message part.
