I'm continuing to work on (hopefully) high-impact query improvements aimed (probably) for 1.4. These indexing-and-querying changes cut across the 3akai-ux, Nakamura, and Solr-integration repositories, and cut across functional domains. I tend to analyze, code, test, and commit changes one proven chunk at a time. But as the commits add up, it's likely that some of the same files will be touched multiple times.
Ideally, each small set of changes would be reviewed, efficiently load-tested, and merged-or-rejected as I was done with it. But we aren't quite there yet. In this non-ideal state, how does this sound as a workflow? 1. I continue to commit JIRA-linked clumps of changes, but I do so to "solrwork" branches of my repo copies. 2. I do not submit separate pull requests until the core team says they're ready to deal with them. 3. At that point, we look together at what's there & the core team decides how to package the commits for review & testing. Best, Ray _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
