[Insight-developers] SimpleITK - now using next branch

[Gabe Hart]

On 03/17/2011 11:23 AM, Bradley Lowekamp wrote:
> I can flat out agree too  #2:
>
>> 2) Topic branches should (usually) hold a 1:1 correspondence with 
>> issues in Jira.
>
>>
>> 1) We need a place to share topic branches.  This can be on the 
>> SimpleITK/SimpleITK github account or on each of our individual 
>> accounts.  I don't think it matters which we use, but we should 
>> choose one.
>
> I have just been using my github account for my topics.
>
> https://github.com/blowekamp/SimpleITK/network
>
> I have been:
>
> push mytopic mygithub
> checkout next
> pull
> merge --no-ff --log mytopic
> push origin

This is exactly what I had in mind.

>
>>
>> 3) Topic branch names should be pre-pended with the issue number from 
>> Jira and post-pended with the initials of the primary developer.  
>> This helps to enforce point (2) and lets everyone know who the 
>> primary "owner" of that topic is.
>
> Including the JIRA ID makes since.
>
> So I guess, were we differ is using initial suffixes or pushing to 
> each one's git hub account. Both would indicate who owns the branch. 
> It's not clear to me which is better and why.

I have no real preference either way (the initials thing is just how 
I've done it before).  My only concern about pushing to each other's 
github accounts is that this would require everyone to have push access 
to everyone else's account which would require a lot more setup.  The 
plus side of this is that it would allow us to distinguish nicely 
between the "central" versions and the peripheral "working" versions.

>
> Brad
>
>
> On Mar 17, 2011, at 11:04 AM, Gabe Hart wrote:
>
>> Sounds good.  This actually relates to a long reply I was just in the 
>> middle of typing.  Here's what I was about to say:
>>
>> >>>>
>> Also, do we have a centralized location to share topic branches now 
>> that we're using the next workflow?  In my experience, it's best to 
>> try to avoid fixing messy conflicts when merging to next and instead 
>> to merge conflicting topic branches before merging to next.  This 
>> only works, of course, if you can access the head of the conflicting 
>> topic somewhere.
>>
>> For my other project that uses this workflow, we have a separate 
>> server that holds onto various topic branches.  This way multiple 
>> developers can help on the same topic and new topics which rely on 
>> changes that are in next but not master can merge the respective 
>> topic branches.
>>
>> These are all based on my other project's system so if others have 
>> different ideas please voice them, but my specific thoughts on using 
>> this workflow are:
>>
>> 1) We need a place to share topic branches.  This can be on the 
>> SimpleITK/SimpleITK github account or on each of our individual 
>> accounts.  I don't think it matters which we use, but we should 
>> choose one.
>>
>>
>> 3) Topic branch names should be pre-pended with the issue number from 
>> Jira and post-pended with the initials of the primary developer.  
>> This helps to enforce point (2) and lets everyone know who the 
>> primary "owner" of that topic is.
>>
>> e.g. 020-SupportForModularITK-BL
>> <<<<
>>
>> If we set up a system like I just described, it would be super easy 
>> for me to grab your topic branch and add my commit to the end.  I 
>> think this would be a vote for using the SimpleITK/SimpleITK account 
>> as the topic branch repository so that I would then be able to push 
>> my changes back to the server and you could reset your local branch 
>> to include my added changes.
>>
>> -Gabe
>>
>> On 03/17/2011 10:58 AM, Bradley Lowekamp wrote:
>>> Gabe,
>>>
>>> Please share that check. I only had the following:
>>>
>>> if( NOT ITK_USE_REVIEW )
>>> # TODO need to check ITK configuration to verify that it has the 
>>> needed modules
>>> # message(FATAL_ERROR "Please reconfigure ITK by turning 
>>> ITK_USE_REVIEW ON")
>>> endif()
>>>
>>> Brad
>>>
>>>
>>> On Mar 17, 2011, at 10:50 AM, Gabe Hart wrote:
>>>
>>>> Good catch.  I remember some discussion about using next, but then 
>>>> was out of the loop for a while, so I haven't been good about 
>>>> checking what is already in next.  I'll try to be better about 
>>>> checking there before I push ahead with new ideas.
>>>>
>>>> As far as this topic goes, I did manage to get things compiled and 
>>>> linked against the modularized version by just adding a check to 
>>>> see if "ITK-Review" is in the ITK_MODULES_ENABLED list after 
>>>> finding ITK, but all of the tests fail when compiled this way.  
>>>> I'll abandon this issue since it seems like it's already being 
>>>> taken care of.
>>>>
>>>> -Gabe
>>>>
>>>> On 03/17/2011 10:45 AM, Bradley Lowekamp wrote:
>>>>> Gabe,
>>>>>
>>>>> I see you added a new issue into JIRA that is basically a duplicate:
>>>>>
>>>>> https://itk.icts.uiowa.edu/jira/browse/SIMPLEITK-23
>>>>>
>>>>> I make the link and commented about the issue.
>>>>>
>>>>> As this has been already addressed and merged in the next branch, 
>>>>> I must ask if you are aware that we are trying to use the next 
>>>>> branch for integration of topics?
>>>>>
>>>>> Brad
>>>>>
>>>>> BTW: I am CC ing the developers list as Luis has suggested that 
>>>>> our off-list SimpleITK discussions should really be going to the 
>>>>> developers list. I would still like to maintain the convention of 
>>>>> including SimpleITK in the subject, so that mail filtering is easy.
>>>>>
>>>>>
>>>>> ========================================================
>>>>> Bradley Lowekamp
>>>>> Lockheed Martin Contractor for
>>>>> Office of High Performance Computing and Communications
>>>>> National Library of Medicine
>>>>> blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Gabe Hart
>>>> R&D Engineer
>>>> Kitware, Inc. - North Carolina Office
>>>> http://www.kitware.com
>>>> (919) 969-6990 x317
>>>
>>> ========================================================
>>> Bradley Lowekamp
>>> Lockheed Martin Contractor for
>>> Office of High Performance Computing and Communications
>>> National Library of Medicine
>>> blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>>
>>>
>>
>>
>> -- 
>> Gabe Hart
>> R&D Engineer
>> Kitware, Inc. - North Carolina Office
>> http://www.kitware.com
>> (919) 969-6990 x317
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>
>
>


-- 
Gabe Hart
R&D Engineer
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(919) 969-6990 x317

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110317/9126a4d2/attachment.htm>