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.


Reply via email to