Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

[Rafael Schloming <rh...@alum.mit.edu>]

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.

--Rafael

On Tue, May 5, 2015 at 7:48 PM, Alan Conway <ac...@redhat.com> wrote:

> First serious stab at a concurrent Go API for proton with working examples
> (send.go, receive.go) that inter-operate with the python examples :)
>
> Read all about it:
> https://github.com/apache/qpid-proton/tree/master/proton-c/bindings/go
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>

Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

[Alan Conway <ac...@redhat.com>]

On Wed, 2015-05-13 at 09:24 -0400, Darryl L. Pierce wrote:
> On Tue, May 12, 2015 at 07:06:19PM -0400, Alan Conway wrote:
> > On Thu, 2015-05-07 at 15:42 -0400, Rafael Schloming wrote:
> > > > > 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.
> > 
> > IMO this is a good policy. Go work is now on branch `go`. I left
> > bindings/go/README.md with a pointer to the new branch so people
> > following older discussions can find it. 

The go work is now on branch "go1" because of idiosyncrasies of the 'go
get' tool. Apologies for inconvenience.

Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

["Darryl L. Pierce" <dp...@redhat.com>]

On Tue, May 12, 2015 at 07:06:19PM -0400, Alan Conway wrote:
> On Thu, 2015-05-07 at 15:42 -0400, Rafael Schloming wrote:
> > > > 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.
> 
> IMO this is a good policy. Go work is now on branch `go`. I left
> bindings/go/README.md with a pointer to the new branch so people
> following older discussions can find it. 
> 
> > I think I pretty much said go ahead on master, so apologies for singling
> > you out. 
> "go" ahead. Hahaha. Just when I think we've done all those jokes,
> there's always another one.

I do like this. I would love to push my Reactive changes up to a
ruby-reactive branch on the core repo and let people examine it there.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

[Alan Conway <ac...@redhat.com>]

On Thu, 2015-05-07 at 15:42 -0400, Rafael Schloming wrote:
> > > 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.

IMO this is a good policy. Go work is now on branch `go`. I left
bindings/go/README.md with a pointer to the new branch so people
following older discussions can find it. 

> I think I pretty much said go ahead on master, so apologies for singling
> you out. 
"go" ahead. Hahaha. Just when I think we've done all those jokes,
there's always another one.

Cheers,
Alan.

Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

[Rafael Schloming <rh...@alum.mit.edu>]

On Thu, May 7, 2015 at 2:52 PM, Alan Conway <ac...@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

Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]

[Alan Conway <ac...@redhat.com>]

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