Call for your input on questions you ask yourselves during merge

> Hi,
>
> Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example:
> - I would like to be able to group them by author, or
> - I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time).
>
> Cheers,
> Doru
>
>
> On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> We are writing some articles on the work of veronica to support merging activities.  We need your input great smalltalk community :)
>> What are the questions that you ask yourselves when you are/want to merge some code in your project?
>> We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them.
>>
>> Here are some typical questions we asked ourselves.
>> - What other changes did this change require?
>> - Can I integrate this change right now?
>> - How large it is?
>> - Who made it?
>> - Is it still valid (when I'm working on an old change)?
>> - Is this change impacted by a change that happened in another branch of my software?
>>
>> Stef D., Andy K. and Veronica U.
>>
>>
>> _______________________________________________
>> Esug-list mailing list
>> [hidden email]
>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
> --
> www.tudorgirba.com
>
> "Don't give to get. Just give."
>
>
>
>
>
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

> Hi all,
>
> A little late, but I still wanted to react to these questions.
>
> Besides the obvious question on 'what functionality does the change fix/add/remove?', I often find myself navigating and browsing code to answer the following questions:
>
> - Does the change remain confined to a module (this can be a package, class, …) or is it crosscutting ?
> - What parts of the system are directly using the changed behavior? Is it a central part of the system with many dependents?
> - Who was the owner of the code that was changed? Should another developer review these changes (i.e. the original author whose code was adapted) ?
> - If the change is a refactoring, were all appropriate parts refactored and no inappropriate ones included? Are there other packages that would need to change as well to incorporate this change?
> - Does the code (partially) reinvent the wheel? In essence: does it introduce code duplication or does it implement parts that are reimplementations of existing parts in the code base or existing libraries?
> - How about the unit tests? Was there a new test? Were they adapted? Is the code in this change covered adequately ?
>
> I assume the verification of coding conventions, unit testing, etc… as a step of the integration process as well.
>
> I should also note that, in our case, every developer needs to integrate his work in the trunk himself. A first check is therefore done by the developer who is merging his changes in the trunk. This change in the trunk is afterwards verified with the questions above. This means that, at that time, problems related to parallel changes are practically non-existant (i.e. the developer who integrates needs to deal with those directly). Daily coordination amongst developers also reduces the possibility on conflicting parallel changes. Such a single branch development is feasible for us because we work with a single software version and excluding changes from the trunk is a very uncommon decision (bad changes need to be corrected appropriately instead of simply left out).
>
> best regards,
> Johan
>
> On 27 Nov 2011, at 20:45, Tudor Girba wrote:
>
>> Hi,
>>
>> Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example:
>> - I would like to be able to group them by author, or
>> - I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time).
>>
>> Cheers,
>> Doru
>>
>>
>> On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote:
>>
>>> Hi guys
>>>
>>> We are writing some articles on the work of veronica to support merging activities.  We need your input great smalltalk community :)
>>> What are the questions that you ask yourselves when you are/want to merge some code in your project?
>>> We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them.
>>>
>>> Here are some typical questions we asked ourselves.
>>> - What other changes did this change require?
>>> - Can I integrate this change right now?
>>> - How large it is?
>>> - Who made it?
>>> - Is it still valid (when I'm working on an old change)?
>>> - Is this change impacted by a change that happened in another branch of my software?
>>>
>>> Stef D., Andy K. and Veronica U.
>>>
>>>
>>> _______________________________________________
>>> Esug-list mailing list
>>> [hidden email]
>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>>
>> --
>> www.tudorgirba.com
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Esug-list mailing list
>> [hidden email]
>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org