Hey Ray, I think your workflow describes best what fits in at the moment. Keeping your many changes confined to a single pull request will help with avoiding merge conflicts. If there's UI and back end fixes we'll have to, like you mention, package fixes and review/test them in a coordinated way. Over the coming week I'll be able to look into your UI pull requests, the two PR's that are on my radar now are SAKIII-5322 and KERN-2805.
Thanks Ray, - Bert On 23 May 2012, at 20:01, Ray Davis wrote: > 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 _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
