On Thu, May 7, 2015 at 2:52 PM, Alan Conway <acon...@redhat.com> wrote:
> > ----- 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. > I think I pretty much said go ahead on master, so apologies for singling you out. It's awesome that lots of new binding work is happening and I think it's just a natural part of any project's growing pains to introduce a bit more process when dealing with a code base that has both stable/mature parts and newly expanding parts. --Rafael
