Open Stack

On 12/24/2013 06:32 AM, Sean Dague wrote:
> 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?
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> -2
>
> I think this is just extra clutter, please don't.
>
> Also, it's Holiday season so tons of people are out, policy changes are
> completely on hold until January.
>
> The commit message should be meaningful so I can read it, a bunch of
> tags I find just ugly and don't want to go near. We already have this
> information in the directory structure for API tests. And in service
> tags for the scenario tests.
>
> 2 & 3 you can through gerrit API queries. Replicating that information
> in another place is just error prone.
>
> 	-Sean
>
>
So I agree with this in theory (now that I know about it) and gave it a 
whirl after consulting 
http://dague.net/2013/09/27/gerrit-queries-to-avoid-openstack-review-overload/.
I took the basic command and added file:^.*/network/.* but got an error. 
Looking at the docs I see the warning that you can't put this in the 
search field so I tried putting it directly in the url like the other 
parameters but it was ignored. Is there indeed a way to search for only 
patches that contain changes to files that match a regexp?

  -David