[Insight-developers] Fwd: fix backport into 3.20, 3.21?

Bill Lorensen bill.lorensen at gmail.com
Thu Sep 23 10:15:16 EDT 2010


I believe we still have a gatekeeper for 3.20.x.

This section from ITK's Policies and Procedures
http://vtk.org/Wiki/ITK_Rules_for_CVS_Contributors#Release_Branches
should be updated to reflect the new git based process.

We should also look at other sections of Policies and Procedures
http://vtk.org/Wiki/ITK_Policies_and_Procedures

and update them.

Bill
On Thu, Sep 23, 2010 at 8:35 AM, Brad King <brad.king at kitware.com> wrote:
> On 09/23/2010 07:45 AM, Alexandre GOUAILLARD wrote:
>> just a few questions regarding the releases.
>
> I've been meaning to update the Wiki for this but haven't found time yet.
>
>> My understanding is that the Release branch right now correspond to
>> itk 3.21 and is where we should commit (critical) bug fixes for 3.20.
>> Is it correct? Then those bugs are merged into master.
>
> The 'release' branch is for 3.20 and will be used to produce 3.20.1,
> 3.20.2, etc. as necessary.  When 4.0 comes out the release branch will
> fast forward to it and be used for 4.0.0, 4.0.1, etc.
>
>> Everybody with write access to the repository would have write access
>> to release branch as well.
>
> Not quite.
>
> Git allows everyone to start work from any commit in history.  Anyone
> with write access or not can checkout the release tag and commit locally.
> You can merge the fix to master (using the topic stage), and then ask
> the gatekeeper (me) to merge it to the 'release' branch:
>
> Starting point:
>
>             o  release
>            /
>  v3.20.0-> o
>          /
>  ...o----o----o  master
>
> You create bug fix from 3.20.0 (commit A):
>
>             o  release
>            /
>  v3.20.0-> o-----A  my-bug-fix
>          /
>  ...o----o----o  master
>
> You merge bug fix into master (commit B):
>
>             o  release
>            /
>  v3.20.0-> o-----A
>          /       \
>  ...o----o----o----B master
>
> I merge bug fix into release (commit C):
>
>             o-----C  release
>            /     /
>  v3.20.0-> o-----A
>          /       \
>  ...o----o----o----B master
>
>
>> what happen if a fix was commited first to master (like
>> fd39d4138c579a3526511f21a12d3b03a611fa41)
>> and then we realized it should also apply to another branch?
>
>  $ git checkout -b my-bug-fix v3.20.0
>  $ git cherry-pick fd39d41
>  $ git push stage HEAD
>  $ ssh git at itk.org stage ITK merge my-bug-fix
>
> Then email me and ask for the topic to be merged to 'release' too.
>
> -Brad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list