[Cosmo-dev] Problems subscribing to the Office Calendar

[Jared Rhine]

>> 1. Is iCal4J really the problem?  If so, what is the right fix (asking 
>> for a fix upstream, patching ourselves, patching Cosmo code)?

So, a short workaround in Cosmo sounds great.  Super-glad that's 
possible, according to Randy's analysis.

Would the workaround be removed after an ical4j fix makes it into 
upstream (and we migrate to that new upstream)?  Is migration to an 
unforked ical4j a 0.7 target?

Do you already have a patch produced, Randy?  I assume it's a wrapper 
around one place where Calendar.equals is used?  Is there only one place 
Calendar.equals is called throughout the code?

>> 2. Is the problem severe enough to warrant a Cosmo 0.6.0.1 release and 
>> accompanying osaf.us upgrade?
> 
> I think so.

It's certainly worthy of a fix.  It's not obvious-obvious from 
discussion here that a release is needed; I'm not opposed to "provide 
Jared the patch" approach (where I could provide the instance used by QA 
for validation).

But a Cosmo-team-produced 0.6.0.1 is super-fine with me, too, as long as 
only this single patch is included; no other sneak-ins.  Other people 
trying out Cosmo will get hit by this bug too, of course, so a full 
release is a healthy thing to do.

In an upcoming debrief, I'd like to discuss what sort of process would 
be needed to produce and rollout a "same day" fix for Chandler Hub for 
some hypothetical future critical data corruption bug.  One can't 
generalize for all bugs, but the process we're outlining is a prototype 
minimum for a 1-line change.

> Also, I think the same issue is manifesting in other 
> personal calendars shared on osaf.us which we are using for our tests.

Randy, can we detect events that didn't get their stamp updated?  I'm 
not sure if we can notify users or autofix any broken collections. 
There's both the issues of fixing Cosmo (per this thread), and 
mitigating the existing state of the service.

> 2. run full automated regression and functional test suite (this is half 
> days work since some of the tests will have to be reworked to make them 
> compatible with the old UUIDs which were changed in 0.7)

Could you elaborate?

Is this suggesting backporting Windmill tests from trunk to 0.6 tag? 
I'm not opposed, though it doesn't seem like a great use of time, since 
the original 0.6.0 release wasn't made with those tests, and the 
backporting won't apply to 0.6.1, right?  It'd make more sense to me to 
simply add a Java unit-test (or 2, one for timezones, one for alarms) 
to whatever's in the 0.6.0 branch's Java test suite and leave it at that.

I'm not opposed to Aparna's task #2, as long as it is strictly 
time-limited.  It'd be great to implement a production fix tomorrow, if 
a patch is available today.

> 3. test chandler+cosmo interoperability (mostly manual)

Ok.  But the manual procedure won't be a documented test plan until 
0.6.1, right?  I'd be willing to take some portion of the interop 
testing, if it's physically possible to split up the manual regression 
testing work.

> Plus whatever time Jared takes to setup staging and running the upgrade 
> tests against that.

No data migration procedure will be used (since no schema changes will 
hit 0.6.0.1).  I might even use the same Tomcat install and simply 
update the Cosmo WAR (in-place/directory).

Most important to me, in the whole process, in that additional unit 
tests are written and included in the tree to test the timezone and 
alert changing cases.  If those are included in Windmill and manual test 
plans, great, but always-improving unit tests are critical to supporting 
fast turnarounds for future production problems.

-- Jared