Open Stack

On 12/24/2013 01:47 AM, Yair Fried wrote:
> Hi,
> Suggestion: Please consider tagging your Tempest commit messages the same way you do your mails in the mailing list
> 
> Explanation: Since tempest is a single project testing multiple Openstack project we have a very diverse collection of patches as well as reviewers. Tagging our commit messages will allow us to classify patches and thus:
> 1. Allow reviewer to focus on patches related to their area of expertise
> 2. Track "trends" in patches - I think we all know that we lack in Neutron testing for example, but can we assess how many network related patches are for awaiting review
> 3. Future automation of flagging "interesting" patches
> 
> You can usually tell all of this from reviewing the patch, but by then - you've spent time on a patch you might not even be qualified to review.
> I suggest we tag our patches with, to start with, the components we are looking to test, and the type of test (sceanrio, api, ...) and that reviewers should -1 untagged patches.
> 
> I think the tagging should be the 2nd line in the message:
> 
> ======================================
> Example commit message
> 
> [Neutron][Nova][Network][Scenario]
> 
> Explanation of how this scenario tests both Neutron and Nova
> Network performance
> 
> Chang-id XXXXXXXXXXXXXXXXXXX
> =======================================
> 
> I would like this to start immediately but what do you guys think?

So I'm picking up this thread again to explain my objections further now
that it's not vacation.

The issue is making it easier for reviewers to care only about a subset
of of the tree. Which I see as being useful. The problem is, how do you
handle that.

Git commit message is something we live with forever, and is something
that requires code originators to get tagging right. We can't even get
people consistently tagging email threads, so doing this with commit
messages doesn't seem to be a winning battle. And doing it with an ever
evolving list of tags means it ends up just becoming line noise in our
change history.

So lets go after the real problem, selecting subsets of reviews, which
is really a gerrit problem (made worse because we are on an ancient
gerrit. 2.4 is really no longer suitable).

Gerrit has the ability to put watches on file regex for watched projects
(though only for email, because it's an expensive query).

Gerrit 2.5 implemented the ability to put UnifiedDiffs in the emails,
which if we did on New Change emails would let you build client side
filtering to flag for directories or files that you have.

Gerrit 2.8 implemented *secondary indexes* which means the file regex
can be made available via the web UI.

So the real solution is gerrit upgrade, which is currently held up on
the WIP patch. But I think we're getting to the point where we need to
decide if that one feature is worth holding up all the rest of the
features that we are missing that would help with our review overload
problem.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140102/188bd9bc/attachment.pgp>