On Tue, 28 Nov 2006, Jeffrey Harris wrote:
Hi Folks, 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.
I was going to suggest the same thing. +1
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.
If you merge the trunk into the branch daily, it shouldn't be that bad. Andi.. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
