----- Original Message ----- > The recent landing of the Go changes make me think that we should be more > explicit about our development process with respect to new language > bindings (or possibly in general). There are two problems I would like to > address. > > First, a bunch of code just landed on trunk without prior > communication/peer review right as we are trying to stabilize for 0.10. > With the go binding work having started/proceeded directly on trunk, I > can't tell if this is a rush commit to get stuff into 0.10, or if it's just > more ongoing development that was assumed to not impact the stated 0.10 > goals. > > Secondly, from a release management perspective it is in general awkward to > have early stage development mixed in with changes to a stable codebase. > The git history between 0.9, 0.9.1, and master is currently a mix of high > fidelity changes, e.g. discrete bug fixes/feature enhancements all > cluttered up with a bunch of more noisy checkpoint/work-in-progress style > commits for the go binding that are a normal part of early stage > development work. This makes things hard when it comes to release > management as there is a lot of noise to sort through when running git > cherry and the like. > > I'd like to propose getting a bit more formal about the following policy, > especially now that we are fully using git and branches are cheap. I think > a number of people already follow this implicitly, but as a whole we are > somewhat inconsistent about it (myself included at times): > > 1. For developing new language bindings (and really for any development > work that will involve enough new stuff to have a noisy commit history) we > use branches. This is already the case with the Ruby/C++/Python3 bindings, > as well as the SASL work. > > 2. We should discuss on the mailing list before we land major features. We > were trying to stabilize trunk for a 0.10 release, and this hasn't been in > the discussion, and a number of things have been broken in the recent > commits.
:)) I didn't follow the process 'cause there wasn't one :) This process makes perfect sense, I will move the go work to a "go" branch to comply. n fairness to me I did ask on the list whether I should do this on a branch or whether it was OK on trunk blah, blah, whine, whine, poor me etc. In fairness to the new process I did break the build with a go commit. Not because of the go binding but because of an emacs keyboard twitch leaving random characters in a python file I was "viewing". Being on a branch would have saved me that embarrassment. Cheers, Alan.
