Let's map tickets to milestones

[Jeroen van Meeuwen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120415/4f956fe3/attachment.bin