Re: [Engine-devel] Proposal for new commit msg design for engine commits
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Eyal Edri" <eedri(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "infra"
<infra(a)ovirt.org>
Sent: Tuesday, July 9, 2013 3:33:57 PM
Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits
----- Original Message -----
> From: "Eyal Edri" <eedri(a)redhat.com>
> To: "engine-devel" <engine-devel(a)ovirt.org>
> Cc: "infra" <infra(a)ovirt.org>
> Sent: Tuesday, July 9, 2013 12:38:51 PM
> Subject: Proposal for new commit msg design for engine commits
>
> Hi,
>
> You all probably know and familiar with 'ovirt-engine' git hook for commit
> msg template [1].
> this helps understand the general area of the patch in the project but it
> lacks additional info that might
> be valuable for scaling automatic tests in Jenkins CI.
>
> Let me explain:
>
> Infra team is working hard on expanding oVirt CI infrastructure and adding
> more tests in jenkins (per commit/patch).
> Adding important meta-data per patch can significatly improve the ability
> to
> run specific tests for each patch/commit,
> and not waste valuable resources on Jenkins jobs that are not relevant to
> the
> code in the patch.
>
> So the idea is to add/expand current metadata per patch, in the form of:
> (either)
> 1. expanding current header template to include more data like 'network' ,
> 'setup', 'tools', 'virt'
Please do not expand header, it is too short anyway.
> 2. adding a new label with relevant tags for the patch, called e.g
> 'METADATA: network, rest, virt'
Having:
CI-Tests: xxx
CI-Tests: yyy
CI-Tests: zzz
Is much better.
I'm not sure we should have CI-Test - as we might use this for something else besides
CI.
Region_of_Interest as Dan suggests sounds better IMHO.
However, I don't think that it is the responsibility of the committer.
I suggested some time ago to have metadata information within each source.
Each source should have metadata of:
1. Maintainer group.
Not sure if this is always relevant, what if i'm fixing some unit test that got
broken? it's enough to know I'm a maintainer, no?
2. Subsystem.
3. Any other relevant.
This way you can act automatically using this information.
Java:
/*
* $OVIRT_METADATA.COMPONENT=<string>
*/
or:
// $OVIRT_METADATA.COMPONENT=<string>
Shell/python:
# $OVIRT_METADATA.COMPONENT=<string>
Well, you get the idea...
This signature will allow:
a. find . -type f | xargs grep '\$OVIRT_METADATA.COMPONENT=mycomponent'
b. Future automation within gerrit.
Regards,
Alon
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel