[Chandler-dev] Branching for recurrence/table view interactions?
jeffrey at osafoundation.org
Tue Nov 28 11:05:17 PST 2006
I'm not crystal clear on whether this requires any group process, but I
figure it's better to discuss branching, at least briefly, so people
don't get surprised by it.
I knew my table/recurrence work was going to slow things down, but
apparently it also caused a few test failures that weren't just timeout
related, so I backed out my changes. Since it seems like the impact of
those changes is likely to be mitigated by work Grant's doing, Grant and
I have been discussing working together on a recurrence branch.
Grant would put his per-attribute-modifications work (which is mostly
working except for indexes) onto the branch, and I'd put in my
modifications-in-the-dashboard work. This would give me a chance to
A) consolidate triageStatus modifications, which should limit the
performance hit from my work, and
B) change the export/share code to ignore triageStatus-only
modifications, avoiding sharing pollution my change was likely to cause
Anyone have objections or concerns with this plan? Historically it
seems like merging branches back in has been fairly difficult, so I
think it would be naive to assume this time around we won't have
problems. Still, I think this would be the right move.
More information about the chandler-dev