[Engine-devel] Proposal for new commit msg design for engine commits
Yair Zaslavsky
yzaslavs at redhat.com
Tue Jul 9 12:42:24 UTC 2013
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at 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 at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "infra" <infra at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Engine-devel
mailing list