Let's map tickets to milestones
murch at andrew.cmu.edu
Sun Apr 15 16:25:10 EDT 2012
The CalDAV code is almost entirely orthogonal to the base Cyrus code so
I don't see it effecting the stability of the other services. Those
changes that were made to the base code are running at CMU so they
should be fine. That being said, if httpd is complete crap, then it
could effect the stability of the server as a whole.
I already have compile-time options in place so that httpd is only built
if --enable-caldav and/or
--enable-rss are specified.
We already have CalDAV and RSS components in bugzilla which I have been
using to remind myself of things that need to be fixed/completed.
Rebasing CalDAV on master won't be trivial, but I also don't think it
will be overly difficult. It only took me about a day to go from master
to 2.4, so I don't think the reverse will take much longer. Its mostly
just catching up with the API changes that Bron/Greg have made.
Its hard to gauge the support effort at this point until we get more
people using it. Its mostly understanding how to configure the clients,
since each one that I have used has different requirements. iCal is the
best since it has the most advanced auto-configure detection. Evolution
is pretty good at finding calendars, Lightning needs to be spoon fed.
Outlook doesn't have any native CalDAV support that I'm aware of.
On 4/15/12 2:47 PM, Jeroen van Meeuwen wrote:
> 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.
> 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
> - 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. 126.96.36.199, 188.8.131.52 releases.
> Kind regards,
> Jeroen van Meeuwen
Principal Systems Software Engineer
Carnegie Mellon University
More information about the Cyrus-devel