On Mar 16, 2009, at 8:59 AM, C. Titus Brown wrote:
> I'm hoping that you did this in my seqdb review branch -- you know, > the > one with all the whitespace changes and documentation additions and > tests...? > > <sigh> OK, I'll integrate those changes into my seqdb review branch. > But please, if we are to have any hope of integrating MY refactorings > don't change seqdb in master! ;) Sorry, Titus, I didn't mean to create extra work for you. I was at a conference from Thursday night to Sunday night, without a usable internet connection. I made these changes in a separate branch "filedb_init" during one of the sessions. After running all the tests and reviewing these changes, I decided to merge them into master right away because I thought we had a consensus (i.e. you initially requested these changes, and I came around to agree with you). Needless to say, I didn't see your Saturday email about your seqdb review branch until today. Little slip-ups like this can't be completely avoided, but we could do some simple things to reduce them. Specifically, if someone plans on making sweeping changes to a module (i.e. anything git would have trouble merging with other changes), we should announce the *start* of that prominently with a Big Red Warning Label saying "please hold off making changes to this module until I'm done". It's critical to announce the start of that fork, because by the time you announce your git branch, someone may already have made some changes to that module (even if they made their changes in their own experimental branch, that doesn't help; the pain of merging will be the same). I know you said on Thursday you'd be working on the code review, but I guess I failed to translate that into a "module lockdown command" or to think about when the effective "lockdown" period would begin. Let's agree on such lockdowns explicitly (e.g. in the developer phone conference) in the future. -- Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. 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/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
