[Engine-devel] Proposal for new commit msg design for engine commits

[Alon Bar-Lev]

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Eyal Edri" <eedri at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Tuesday, July 9, 2013 3:42:24 PM
> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine	commits
> 
> 
> 
> ----- 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.

I don't care how this is to be called.
However, I do not think that commit message is the place for instructing CI to do anything.
Commit message stays for good, it should contain information that is required a year from now.
It has nothing to do with tests and such.

> > 
> > 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?

Drop the maintainer, it is a suggestion of extra metadata we can add to automatically CC relevant people.
Add more metadata, so that every change in that file will trigger specific tests.

> 
> > 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
> > 
>