Let's map tickets to milestones

[Dave McMurtrie]

Maybe we can all get together on IRC and talk about CalDAV and 2.5.

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?

Thanks!

Dave

On Apr 15, 2012, at 10:43 AM, "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com> wrote:

> A conversation has been started on when Cyrus IMAP 2.5 would be released.
> 
> So far, there's little certainty about it, but we can try and make it more 
> visible by creating tracker tickets and logging every bug, enhancement and/or 
> task into Bugzilla.
> 
> If we were to give people a week or so to do all of this, then I reckon next 
> week we could have a meeting to review everything we want to do for 2.5.
> 
> So, I've created a 2.5.0 release blocker ticket;
> 
>  https://bugzilla.cyrusimap.org/show_bug.cgi?id=3674
> 
> Its dependency tree[1] indicates what needs to actually happen. Its direct 
> dependencies are considered high-level bugs, enhancements or tasks we aim to 
> complete before we release 2.5.0.
> 
> For example, ticket #3669[2] is a high-level enhancement to convert to using 
> autofoo. While we work on this, of course we run into issues, which we log as 
> blocking #3669. Now, all tickets the depencency tree if #3669 auto-magically 
> also become visible in the dependency tree for the release blocker ticket. All 
> of the enhancement specific bugs need to be resolved in order for the feature 
> to be complete.
> 
> Another example enhancement, #3343[3] (conversations support), currently has 
> no dependencies... but I'm sure these will pop up as the work on the feature 
> moves back to origin and closer and closer to master.
> 
> If you'll allow me to wing it as we go along, please don't hesitate and make 
> your mark, as follows:
> 
> - Log your new enhancement request and set Blocks: 3674. Please use version 
> 2.5-next and milestone 2.5-next.
> 
> - Take an existing enhancement request and set Blocks: 3674 - you can leave 
> the version untouched but you are at liberty to set the milestone to 2.5-next, 
> even if it is currently set to 2.4-next.
> 
> - We would like existing bugs to mostly remain as they are, but feel free to 
> set Blocks: 3674 to existing bug reports.
> 
> - Add yourself to CC: on tracker ticket 3674 to receive a moderate amount of 
> traffic as new dependencies are added and existing dependencies are 
> removed/implemented.
> 
> I plan on releasing development snapshots as work on enhancements is 
> progressing, so that people can take an interest in a specific thing (before 
> it's merged back into master?) and find whether or not it works for them.
> 
> Ideas? Questions? Comments? Gripes?
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> 
> [1] https://bugzilla.cyrusimap.org/showdependencytree.cgi?id=3674
> [2] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3669
> [3] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3343
> 
> -- 
> Systems Architect, Kolab Systems AG
> 
> e: vanmeeuwen at kolabsys.com
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
> 
> pgp: 9342 BF08