Re: ✗ patchtest: failure for "liberation-fonts: update to 2...." and 4 more

[Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>]

On Thu, 2017-05-04 at 22:07 +1200, Paul Eggleton wrote:
> Hi Alex,
> 
> On Thursday, 4 May 2017 9:33:02 PM NZST Alexander Kanavin wrote:
> > On 05/04/2017 12:43 AM, Paul Eggleton wrote:
> > > On Thursday, 4 May 2017 1:31:52 AM NZST Patchwork wrote:
> > >> * Issue             Series sent to the wrong mailing list
> > > [test_target_mailing_list]
> > >>   Suggested fix    Send the series again to the correct mailing list (ML)
> > >>   Suggested ML     poky@yoctoproject.org [http://git.yoctoproject.org/
> cgit/
> > > cgit.cgi/poky/]
> > >
> > > Leo - looks like this is another false positive.
> > 
> > Actually, no - one of the patches accidentally included a file from 
> > meta-poky. Still, could be reported better:
> > 
> > 1) Should refer to a specific patch where the issue is
> > 2) Should, if possible, refer to specific files in the patch that are 
> > causing the problem.
> 

yes, I realized that and try to make it better with:

http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/commit/?id=d1841aa2d19c6576d84c461656043d0b49ee689e

Due to the nature of the objects being used, the easiest is to provide
the patch's path, so point 2 is covered, not 1.


> Right, agreed on both counts. I guess we were trying to catch the more common 
> case of people sending entire patchsets to the wrong list.


> 
> > 3) The problem is not the wrong mailing list, the problem is that the 
> > patch should be splitted up and sent to several lists :)
> 
> The question is can an automated tool tell the difference? I guess even if it 
> can't though we can be honest about that in the message i.e. "Wrong mailing 
> list, or incorrectly split patch" or something like that.

agree on the proposed message. I change it.

> 
> > In general, why run these checks after the patches have been already 
> > posted for review? That is adding unnecessary friction. Why not have 
> > them as a git hook, that is run locally when making the commit?
> 
> The original idea was that the tests could also be run from your local machine 
> (could easily be as a git hook), and whilst it's not as easy as I might have 
> liked it is doable - however even if it were much easier, we have to be 
> realistic and acknowledge that most people still won't do it.
> 

I proposed the following script:

http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132592.html

which basically takes patches from master to current branch HEAD and
iterates on each one (not yet merged on master). Once script is run,
results are in console then developer can iterate on the series in case
of failures.


> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre