On Thu, Jun 29, 2017 at 6:16 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
Do we have or follow a standard on patch granularity?

I don't think we have or should have any strict standard about this. Every reviewer is different and prefers different kind of patch granularity.

For example I really dislike if someone break one logical work (like implement one small feature) into 10 smaller patches (all in the same area) to easy review. To me reviewing 10 smaller patches is much more work than review one bigger because I keep loosing the context and the bigger picture. In such cases I typically end up downloading the series locally and review in IDE. But than I loose the gerrit features like compare patchsets.

Others, on the other hand, prefer to see tiny patches and that helps them to review.

Ultimately, if you want to get a patch in, you need to know the culture and the people to know how to shape it.
A rule of thumb: in VDSM break up the patches to as small as possible, in engine, break up into logical areas of expertise (e.g. DB, core, frontend).
 
When I started, I picked up on the culture that we do small, logical commits -- as much as possible, each commit should be focused on a specific purpose. I've perceived some reviewers prefer to have all orthogonal changes (fix a random spelling error, remove a duplicate semicolon) extracted to other patches for clarity.

>From my perspective this is a complete waste of time. It does not bring any more clarity to the review nor to the git log. It may be aesthetically more appealing but brings much more work while babysitting the patches and does not bring anything of value. Also I feel it discourages people to fix issues like typo in comment when crossing it because they will have to create a separate patch, than either depend on it or have conflicts with it.

I personally prefer to follow the boy scout rule. On the other hand, some find it disturbing. That is fine, we are all humans, there is no one good option and this is not a technical question...
 
Others don't seem to mind. I feel like I always want to ask, but I feel bad because it's a hassle.


Contributing code is a way of communication with people. I don't think asking anything is a problem...
 

Also, when you are asked to extract something, do you have a trick to make it as easy as possible?

Best wishes,
Greg

--
Greg Sheremeta, MBA
Sr. Software Engineer
Red Hat, Inc.
gshereme@redhat.com

_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel