From Thanh Ha <thanh.ha@...>:

Thanh Ha has posted comments on this change.

Change subject: Manually merge changes from stable/beryllium to master Including commits from 792bc87f7c0b to b5dd44d93 And fixing remained old version tags which caused last failure
......................................................................


Patch Set 2:

Sorry for modifying .gitreview file unexpectedly.

>
> But I have to explain that I did cherry-pick commits from
> stable/beryllium one by one by one.. After fixing all the conflicts
> and cherry-picking all the commits, I just squashed them into one
> commit. And pushing 12 commits to remote is really unnecessary as
> we discussed in the laboratory. And every fixes and edition is made
> after careful comparation. Thanks for reminding

It is better to cherry-pick and push each patch (actually when you reviewed and merged the patches into stable/beryllium they should have been cherry-picked to all relevant branches). If you squash commits like these you're affecting the statistics of your project. These 12 commits represent 12 contributions to the project and potentially multiple contributors.

When you squash commits like these you are hiding the history of the contributions from your contributor base. All contributions will now appear as if you were the one who contributed the work. While I do see that you kept the commit messages aggregated in your message, tools like spectrometer, github, openhub, etc... do not take this into account and will show that the alto project is less diverse a community than it really is. One of the greatest things about open source development for a contributor is that they can refer back to code that they contributed to a project, squashed commits make this significantly harder.

Thanks Kai,

In case it helps the workflow most OpenDaylight projects use is, when a committer accepts and merges a patch, they make a decision if the patch needs to be cherry-picked to other branches as well. For example if you a merging a patch that was submitted to master you should decide if that patch needs to be backported to stable/beryllium and/or stable/lithium as well at that time, typically this decision is done by the committer who reviews and merges the patch. The best way to do this is to use the Cherry-pick button right inside Gerrit. Choose cherry-pick and enter the branch you'd like to carry the patch over to, most of the time this should work trivially. If you get an error then you'll need to do it manually via git commandline as there is likely some merge conflicts you need to take care of.

If you cherry-pick at time of merge it will save you a lot of effort of porting patches to new branches as your code is kept in sync. Typically you should cherry-pick bug fixes backwards to stable branches and only pull in new features to master branch but that is up to your project.

Another thing I highly recommend all committers review and understand is this blog post regarding how to write well formed commit messages.

http://chris.beams.io/posts/git-commit/

This is an excellently written blog post about the importance of writing commit messages that are meaningful and useful. If you've never had to troubleshoot and debug code you may not realize the usefulness but commit messages are immensely useful when you are troubleshooting and trying to find which patch introduced a regression in your code. If you need examples of really well written commit message, the Linux Kernel project is one of the best source of commit messages since they are extremely strict on only accepting patches that have well formed commit messages.

https://github.com/torvalds/linux/commits/master

Hope this helps,

Thanh

On 23 March 2016 at 22:04, Gao Kai <gaok12@...> wrote:

Thanh Ha,

Thanks for the help and I apologize for not responding earlier.  I take
major responsibility here since I myself have submitted squashed commits
as well. (Shame on me.)  I'll make sure other members in the team can
learn something from this and avoid similar circumstances.


Jinmin,

Thanks for your work and the efforts are highly appreciated.  Since ALTO
is part of the OpenDaylight, could you please try to follow Thanh's
suggestions on how the community works? Also, merging patches from
stable/beryllium to master is not a task you must accomplish all on your
own.  If you cherry-pick the patches one by one, others such as Thanh,
who has helped us a lot with the development, can also help resolve the
conflicts.  Jensen and I are also watching the commits so we can provide
some help too.


To the rest of the ALTO development team,

This can be a good chance to learn from our mistakes and to get a better
understanding of how open source communities work.  It can take a while
for all of us to fit in the culture but I think it's something we should
always do.

Thanks!

Kai


On 24/03/16 00:28, Gerrit Code Review wrote:
> From Thanh Ha <thanh.ha@...>:
>
> Thanh Ha has posted comments on this change.
>
> Change subject: Manually merge changes from stable/beryllium to master Including commits from 792bc87f7c0b to b5dd44d93 And fixing remained old version tags which caused last failure
> ......................................................................
>
>
> Patch Set 2:
>
>> Sorry for modifying .gitreview file unexpectedly.
>  >
>  > But I have to explain that I did cherry-pick commits from
>  > stable/beryllium one by one by one.. After fixing all the conflicts
>  > and cherry-picking all the commits, I just squashed them into one
>  > commit. And pushing 12 commits to remote is really unnecessary as
>  > we discussed in the laboratory. And every fixes and edition is made
>  > after careful comparation. Thanks for reminding
>
> It is better to cherry-pick and push each patch (actually when you reviewed and merged the patches into stable/beryllium they should have been cherry-picked to all relevant branches). If you squash commits like these you're affecting the statistics of your project. These 12 commits represent 12 contributions to the project and potentially multiple contributors.
>
> When you squash commits like these you are hiding the history of the contributions from your contributor base. All contributions will now appear as if you were the one who contributed the work. While I do see that you kept the commit messages aggregated in your message, tools like spectrometer, github, openhub, etc... do not take this into account and will show that the alto project is less diverse a community than it really is. One of the greatest things about open source development for a contributor is that they can refer back to code that they contributed to a project, squashed commits make this significantly harder.
>

_______________________________________________
alto-dev mailing list
alto-dev@...
https://lists.opendaylight.org/mailman/listinfo/alto-dev