Call for your input on questions you ask yourselves during merge
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.
On Wednesday, November 23, 2011 at 10:57 AM, 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?
Number 1 question I always ask but is sort of implicit in the other questions is, why was this change made? which impacts on, is it still valid and is this change impacted by a change that happened in another brach of software.
At my job we have several programming rules hat we check on pieces of code before integrating. Some of these checks could be automated,
like what? I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves.
some cannot.
Besides, there is a more subtle analysis about two things: the alignment of the changes with the software design and politics; and a little cost-benefit considering added complexity as a cost (could yield negative when it is a refactoring, for instance) and additional functionality or enhancements or clarity or performance as benefits. I don't think this could be automated, but it could be supported to some extent (we could measure the added complexity and raise hints about some design invariants).
I think this goes to the line that Sean T Allen pointed: why do we want to integrate these changes.
Regards -- carlos e. ferro | senior developer| caesar systems | see clearly. decide smarter.
ceferro@caesarsystems.com | t: +1.281.598.8790 | t: +54.11.4389.0126 | blog.caesarsystems.com | www.caesarsystems.com
This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On 23.11.11 22:30, stephane ducasse wrote:
At my job we have several programming rules hat we check on pieces of code before integrating. Some of these checks could be automated,
like what?
I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves.
I've always considered it important to have a set of code quality tests which would run before code was checked in and accepted into a common baseline. Tests that were more than SUnit or functional acceptance tests, but which then took a bit longer to run. I'd like to have these tests automated and run when merging. SmallLint provides a number of these, and there are surely some other quality and metric tools around. This may go a bit far, but since merging is part of a build process, I'd also like to see whatever you do fit into a CRISP build: *Complete, i.e. scorched-earth build *Repeatable, i.e. consistent and reproducable *Informative *Schedulable *Portable FWIW -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine@metaprog.com Web: http://www.metaprog.com As soon as you introduce people, things become complex.
Hi, in a previous company I worked we had something very similar to what Carlos described. We used SmallLint to verify that no errors where in the code (we extended SmallLint to be able to document false positives), we had what we called programming rules that were run as SUnit tests before integration and after integration, and we also had something we called architecture tests. The programming rules included simple rules like checking the numbers of parameters, doing spell checking, that the initialize message is not send for other object but the class, etc. up to complex validations for patterns like the visitor, state, etc. The architecture rules were oriented towards dependencies between modules (applications in Envy), dependencies between systems, etc. We had a process that defined when to run each type of test (tests were categorized like functional, programming rules, architecture rules, etc using different suites). For example if you changed something, first you had to run the tests related to the changed module, then the functional tests of all the system (around 23.000 test, ran in 7 minutes) then the programming rules. After that the change was sent to the integrator who used an automatic integration tool and also the architecture tests where runned. Before closing the new release the version was uploaded to a fresh GemStone image, and all the functional tests where ran in GemStone. If everything ran correctly, the new version was released. The last steps (uploading code to gemstone, running the tests, etc) are currently done automatically in a build server using Jenkins. This process allowed us to be very confident in the code we produced. Of course that it took some time to do the whole integration cycle, that is why sometimes when the release was an internal one, we could avoid running the tests in gemstone, etc. Anyway, it feels really good to have a process like that and it is still in use. The programmers add new rules when they find mistakes they do, sometimes to prevent errors in the evolution of the code (that is very nice too... design decisions are made explicit through these tests), etc. So, at the same time is a very "reflective" process... Bye, Hernan. On Thu, Nov 24, 2011 at 5:49 AM, Joseph Pelrine <jplists@metaprog.com>wrote:
On 23.11.11 22:30, stephane ducasse wrote:
At my job we have several programming rules hat we check on pieces of code before integrating. Some of these checks could be automated,
like what?
I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves.
I've always considered it important to have a set of code quality tests which would run before code was checked in and accepted into a common baseline. Tests that were more than SUnit or functional acceptance tests, but which then took a bit longer to run. I'd like to have these tests automated and run when merging. SmallLint provides a number of these, and there are surely some other quality and metric tools around.
This may go a bit far, but since merging is part of a build process, I'd also like to see whatever you do fit into a CRISP build:
*Complete, i.e. scorched-earth build *Repeatable, i.e. consistent and reproducable *Informative *Schedulable *Portable
FWIW -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine@metaprog.com Web: http://www.metaprog.com
As soon as you introduce people, things become complex.
______________________________**_________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/**listinfo/esug-list_lists.esug.**org<http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org>
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
Thanks alan! We want more. Please log them next time you integrate something. I really a bunch of them. But I want to hear you guys! Stef
On 23/11/2011 12: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.
At my job we have several programming rules hat we check on pieces of code before integrating. Some of these checks could be automated, some cannot.
Besides, there is a more subtle analysis about two things: the alignment of the changes with the software design and politics; and a little cost-benefit considering added complexity as a cost (could yield negative when it is a refactoring, for instance) and additional functionality or enhancements or clarity or performance as benefits. I don't think this could be automated, but it could be supported to some extent (we could measure the added complexity and raise hints about some design invariants).
I think this goes to the line that Sean T Allen pointed: why do we want to integrate these changes.
Regards -- carlos e. ferro | senior developer| caesar systems | see clearly. decide smarter.
ceferro@caesarsystems.com | t: +1.281.598.8790 | t: +54.11.4389.0126 | blog.caesarsystems.com | www.caesarsystems.com
This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
I find the question *How Large is it* interesting because it can be easily enhanced to complexity metrics. Two simple ones are #loc and #sends (you don't need to compile a method to count the number of message sends it contains). If the change represents a Class definition you could measure the number of instance variables. Changes that remove classes or methods would subtract their complexity from the total. There are more metrics easy to calculate. The point is that with these considerations you could ask how much complexity the change set adds to/removes from the system. leandro caniglia ph.d. | chief technologist | *caesar** systems *| *see clearly. decide smarter**.* lcaniglia@caesarsystems.com | t: +1.281.598.8810 +1.281.617.2972 +54.11.4389.0126 | petrovr.blogspot.com | www.caesarsystems.com This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. On Wed, Nov 23, 2011 at 12:57 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
What does this relate to in the bug-tracking system? Did the tests pass before? Do the tests pass now? Which parts of this are real changes and which are just because somebody felt it was important to reformat everything? :-) What were those changes I just accepted/deleted because the cat was stepping on my keyboard?
------------------------------------------------------------------------
Stéphane Ducasse <mailto:stephane.ducasse@inria.fr> 23 November, 2011 10:57 AM
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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi,
What are the questions that you ask yourselves when you are/want to merge some code in your project?
1. Are there any changes conflicting with my own? 2. If there are no direct conflicts (i.e. a merge worked), will the "baseline" changes combined with my own conflict? (i.e. are there implicit conflicts?) 3. Do all the tests pass after the merge? 4. How quickly can I get my changes published before someone else publishes and I have to merge again :-) To track / understand other people's changes, mostly for the purpose of resolving conflicts, I need information on the version that I'm merging with including all the versions in between. So, something like a summary of all the version comments (collected) and a summary of all the changes (that I can drill into if I need to). I suppose the kind of questions depend a lot on the way we work? My 2 cents Otto
- When the version to be merged into the trunk is on a branch which I already did merge a couple of versions earlier I want to have to see/think about only those changes that are new (i.e. the changes between the version last merged and the current version to be merged and not all changes between the current version to be merged and the trunk version to be merged into) e.g. 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk \ / / ?? questions asked here \ / / -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch The branch version 2.2 has already been merged into trunk version 5.0 some time earlier. Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. I don't know what Pharo does but VisualWorksdisplays all changes between 2.4 and 7.0 while giving additional information about the last common version which is determined to be 2.0 because previous merges are not considered. This forces me to think about how to merge all changes up to version 2.2 once again. We fixed that in our tools, of course (in VW 7.6), offering an additional merge option which only merges the changes since a user selected common version. Regards Thorsten Am 23.11.2011 um 16:57 schrieb Stéphane Ducasse:
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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- www.tudorgirba.com "Don't give to get. Just give."
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 Esug-list@lists.esug.org 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
tx :) On Dec 3, 2011, at 11:23 AM, Johan Brichau wrote:
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 Esug-list@lists.esug.org 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Is this a fix to production? If so, has it also been backfilled to the development branch? ...Stan -- View this message in context: http://forum.world.st/Call-for-your-input-on-questions-you-ask-yourselves-du... Sent from the ESUG mailing list archive at Nabble.com.
participants (13)
-
Alan Knight -
Carlos E. Ferro -
Hernan Wilkinson -
Johan Brichau -
Joseph Pelrine -
Leandro Caniglia -
Otto Behrens -
Sean T Allen -
Stan Shepherd -
stephane ducasse -
Stéphane Ducasse -
Thorsten Seitz -
Tudor Girba