Release Management + Release Manager

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Release Management + Release Manager

Carsten Block
Administrator
Hi!

It seems like we never finally agreed on (i) who is responsible for actually making releases and (ii) how we make releases. The first few releases I did more or less on the fly but we agreed on a (much preferable) fix timeboxed (bi-weekly) release cyle and we are now one week overdue with the announced 0.9 server (+ plugins) release. With my  leaving of KIT and corresponding step-down from all official functions in PowerTAC I no longer qualify as release manager. So who is willing to take over the role of the release manager for the powertac-server? And how is a release actually made?

Concerning the latter question I suggest the following:

On the release day there is an all-hands meeting (maybe using the rzbreeze server) moderated by the release manager. Each feature or bug fix that was scheduled for the release and that is marked as completed should be demonstrated. Demonstration means that (whenever possible) the functionality should be shown in a running live system. Additionally, demonstration might also comprise a short statement by the team member who reviewed (and accepted) the corresponding code upon it's completion (the pull-request mechanism is quite convenient to accomodate such a review process).  Note that the review might also lead to a reject of the code fragment. In this case the task / bug fix is simply not completed and cannot be rolled out as part of the release (in the beginning this might happen quite a few times as we all have to learn how to deal with this process).

Is that desirable? ...and is that realistic? Please comment!

Thanks,
Carsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Management + Release Manager

grampajohn
Administrator
On 02/07/2011 05:26 AM, Carsten Block [via Power TAC Developers] wrote:

> Hi!
>
> It seems like we never finally agreed on (i) who is responsible for
> actually making releases and (ii) how we make releases. The first few
> releases I did more or less on the fly but we agreed on a (much
> preferable) fix timeboxed (bi-weekly) release cyle and we are now one
> week overdue with the announced 0.9 server (+ plugins) release. With my
> leaving of KIT and corresponding step-down from all official functions
> in PowerTAC I no longer qualify as release manager. So who is willing to
> take over the role of the release manager for the powertac-server? And
> how is a release actually made?

I am willing to take over as release manager, but I do not have access
to the repository at KIT, so someone there would have to be responsible
for packaging and distribution.

I have not suggested that we release an 0.9 version, because it does not
seem to be complete, more than a week late, and we do not have an agreed
test suite (that I know of) beyond the individual component tests. I
have yet to get the whole server to do anything interesting.

>
> Concerning the latter question I suggest the following:
>
> On the release day there is an all-hands meeting (maybe using the
> rzbreeze server) moderated by the release manager. Each feature or bug
> fix that was scheduled for the release and that is marked as completed
> should be demonstrated. Demonstration means that (whenever possible) the
> functionality should be shown in a running live system. Additionally,
> demonstration might also comprise a short statement by the team member
> who reviewed (and accepted) the corresponding code upon it's completion
> (the pull-request mechanism is quite convenient to accomodate such a
> review process). Note that the review might also lead to a reject of the
> code fragment. In this case the task / bug fix is simply not completed
> and cannot be rolled out as part of the release (in the beginning this
> might happen quite a few times as we all have to learn how to deal with
> this process).
>
> Is that desirable? ...and is that realistic? Please comment!

Desirable, yes. Feasible, maybe. This kind of process works well with a
team of full-time professional developers who are co-located. That is
not the case with Power TAC. None of our developers are full-time, and
we are scattered across Europe and North America. I would be able to do
a meeting on release days (Mondays) at 9:00 or later my time, which is
16:00 CET.

I think the key in your suggestion is that there be an agreed
demonstration that can serve as an acceptance test for each release. We
have not tried to write that down. Perhaps we can get it done for 0.10?

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Management + Release Manager

grampajohn
Administrator
In reply to this post by Carsten Block
On 02/07/2011 05:26 AM, Carsten Block [via Power TAC Developers] wrote:
>...
>
> Concerning the latter question I suggest the following:
>
> ... Each feature or bug
> fix that was scheduled for the release and that is marked as completed
> should be demonstrated. Demonstration means that (whenever possible) the
> functionality should be shown in a running live system....

To accomplish this, we will need a reconfiguration of the dependencies
so that the entire system works with locally-installed components. The
configuration that uses downloaded components should be for users and
developers of isolated components.

One way to accomplish this would be to decide that the 'master' branch
is a development branch, and reconfigure all plugin dependencies as
local dependencies. Then we can create a "release" branch on the server
(and any plugins that have dependencies) that use repository
dependencies. Otherwise everyone will need to keep private, hand-edited
configurations around to do development, and if they are different we
have a big mess.

Does this make sense?

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Management + Release Manager

Carsten Block
Administrator
In reply to this post by grampajohn
> I think the key in your suggestion is that there be an agreed
> demonstration that can serve as an acceptance test for each release.

Agreed! Probably 0.10 is realistic for that.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Management + Release Manager

Carsten Block
Administrator
In reply to this post by grampajohn
> One way to accomplish this would be to decide that the 'master' branch
> is a development branch, and reconfigure all plugin dependencies as
> local dependencies. Then we can create a "release" branch on the server
> (and any plugins that have dependencies) that use repository
> dependencies. Otherwise everyone will need to keep private, hand-edited
> configurations around to do development, and if they are different we
> have a big mess.

Not sure how to define local plugin dependencies. Once we have powertac-common stable enough to not introduce breaking changes with every release this problem should fade away. Until then, admittedly, it can be quite painful.  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Management + Release Manager

grampajohn
Administrator
This post was updated on .
On 02/08/2011 03:31 AM, Carsten Block [via Power TAC Developers] wrote:
>  > One way to accomplish this would be to decide that the 'master' branch
>  > is a development branch, and reconfigure all plugin dependencies as
>  > local dependencies. Then we can create a "release" branch on the server
>  > (and any plugins that have dependencies) that use repository
>  > dependencies. Otherwise everyone will need to keep private, hand-edited
>  > configurations around to do development, and if they are different we
>  > have a big mess.
>
> Not sure how to define local plugin dependencies. Once we have
> powertac-common stable enough to not introduce breaking changes with
> every release this problem should fade away. Until then, admittedly, it
> can be quite painful.

Now that I've done it successfully a couple of times, it turns out to be
very easy to do:

1. install the sources from the package for which you want the current
version (assume for the moment it's powertac-common) in a sibling
directory to the plugin you are working on (assume it's my-customer).

2. in my-customer/application.properties, remove (or comment out) the
dependency on powertac-common. Now it will no longer look for and
download a version-specific package.

3. in grails-app/conf/BuildConfig.groovy, add the line:
   grails.plugin.location.PowertacCommon = "../powertac-common"
near the top, above the grails.project.dependency.resolution clause.
Note the transformation of the name from powertac-common to PowertacCommon.

4. In toplevel MyCustomerGrailsPlugin.groovy, add a line like
  def dependsOn = ['powertacCommon':'0.9 > *']

Then run grails clean in my-customer, and it should find your new
dependencies.

Cheers -

John
Loading...