[Insight-developers] ITK / Gerrit question

[Bill Lorensen]

No hurry. There is a lot going on.

Here is how I operate:
First, I am usually a reviewer on several topics (9 at this moment).
Second, I am easily interrupted by outside actives (remember I'm retired)
I create a new branch for every topic I review. This keeps me
organized since I may be working on a few topics at a time. I always
build and test the topic (if appropriate). For my linux build, I use
flags that do rigorous stl container checking.
Finally, sometimes if a topic (that is not mine) has enough positive
reviews, I stage push and merge it.

I think others may operate this way. Hans? Luis? Kent/ Gaetan?

Bill

On Sat, Nov 6, 2010 at 12:45 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Hi Bill,
>
> I agree that we should have it, but have not had sufficient time to
> get Gerrit master built, and make/test the change. I am also working
> on something else that Luis wanted for the upcoming meeting that would
> make checking out the changes locally much less of a requirement.
>
> This is using a combination of the CDash at Home work with Gerrit. So
> instead of listing who has what compilers/OSes you could simply
> volunteer a machine for CDash at Home ITK testing, when someone submits a
> patch to Gerrit a request for a Windows, Linux and Mac build is added
> to the queue and a hyperlink inserted into the Gerrit commit page.
>
> I would like to take a step back and examine why you tend to have so
> many topics checked out? Is it because you want to build them/run the
> tests, run KWStyle or something else? I had been concentrating on
> increased automation as I think this is the way to go.
>
> In answer to your other question - yes Gerrit uses Gerrit to
> review/accept patches. I have not submitted a patch there yet, but
> once I have this change I would submit it there. Quite limited time at
> the moment, and so I have not been able to get to this.
>
> Marcus
>
> On Thu, Nov 4, 2010 at 4:42 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Marcus,
>>
>> Do we have a resolution on this? I sometimes have several gerrit
>> requests.  I currently do the manual cut and paste. Have you checked
>> with the gerrit folks?
>>
>> Bill
>>
>> On Tue, Oct 26, 2010 at 6:46 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> I see your point, and realize we all work differently - let me look into this.
>>>
>>> Marcus
>>>
>>> On Tue, Oct 26, 2010 at 6:36 PM, Hans Johnson <hans-johnson at uiowa.edu> wrote:
>>>> I agree.  I do this all the time too.  When I am not on the "no branch"
>>>> branch, I don't know what I'm working on, and that seems dangerous to me.
>>>>
>>>> On 10/26/10 2:43 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>>>>
>>>>> Some of us are doing multiple reviews at the same time. And some of us
>>>>> always make a branch when we are reviewing.
>>>>>
>>>>> Also, a branch is useful if you are going to push another user's
>>>>> gerrit patch to the stage.
>>>>>
>>>>> Right now, I manually do a git checkout -b topic_name and I cut the
>>>>> topic name from the gerrit page so that I don't misspell it.
>>>>>
>>>>> I would find this very useful.
>>>>>
>>>>> On Tue, Oct 26, 2010 at 1:21 PM, Marcus D. Hanwell
>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>> On Tue, Oct 26, 2010 at 11:40 AM, Luis Ibanez <luis.ibanez at kitware.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Marcus,
>>>>>>>
>>>>>>> At the ITK tcon we were wondering if we could modify our installation of
>>>>>>> Gerrit
>>>>>>> to have the git command line create a branch with the topic that is just
>>>>>>> checked out.
>>>>>>>
>>>>>>> so, to change:
>>>>>>>
>>>>>>> git fetch ssh://ibanez@review.source.kitware.com:29418/ITK
>>>>>>> refs/changes/34/234/1
>>>>>>> && git checkout FETCH_HEAD
>>>>>>>
>>>>>>> into
>>>>>>>
>>>>>>>
>>>>>>> git fetch ssh://ibanez@review.source.kitware.com:29418/ITK
>>>>>>> refs/changes/34/234/1
>>>>>>> && git checkout FETCH_HEAD -b topic-name
>>>>>>>
>>>>>>>
>>>>>>> Do you think this could be done ?
>>>>>>>
>>>>>> I think it could be done, but the majority of the time when reviewing
>>>>>> a topic branch there is no need to make it into a named topic branch.
>>>>>> You only really need to assign it a name if you are going to stage it,
>>>>>> and merge it. Then a,
>>>>>>
>>>>>> git checkout -b topic-name
>>>>>>
>>>>>> Would give you that from the detached head. You still need to ensure
>>>>>> you are at the tip of the topic, and most of the time I would rather
>>>>>> have the current behavior. I can take a look and see where the change
>>>>>> would be required, and how likely it is that it would be accepted
>>>>>> upstream (as we would rather not maintain a patched version of Gerrit
>>>>>> long term).
>>>>>>
>>>
>>
>