> > Today, it looks like the majority of development is done directly in the > default repo. A minor modification in the workflow would I think produce > the result we are looking for without all the overhead of switching hosting > and all the associated loss of history that would occur. If *all* > developers were working from personal clones (and you really need only one > because you can branch inside it and keep your clone trunk in sync with the > default repo trunk) that had code review enabled, it would allow for all > changes to be reviewed right in Google Code *before* being pushed to the > default repo. There isn't any bandwidth hit because you don't need local > copies of all the clones. Instead, those with default repo commit access > simply point to whichever clone *on the server* that you need to pull from > when you need to update the default repo. >
A less radical modification to the current workflow would be to use named feature branches within the default repo for any major development that might require review. Then those with commit access could work the change together on the branch in the default repo and request code review before merging back to the default branch. Anyone without commit access can still pursue the personal clone approach then request review and pull by creating an Issue in the tracker. That lowers the admin overhead for the main contributors while providing a good, clean way for new contributors to provide code in a reviewable way. -- You received this message because you are subscribed to the Google Groups "spyder" group. To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/1qsHb77IFSkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
