----- 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.


Reply via email to