Automated test migration

Cyril Bur cyrilbur at
Wed Jan 13 10:29:54 AEDT 2016

On Tue, 12 Jan 2016 23:09:22 +0000
"Chris Austen" <austenc at> wrote:

>  I've known for a while that we would eventually move the automated test suites from to  That day came yesterday.  Manjuanth and I have adhered to code review principals making sure that we never merged without the others review.  However I will admit the commit message and the amount of commits per pull request was not my top priority.  To be honest just getting to the state where dev and test were developing code in the same sprint was good enough, all other things be damned.  Now I see there are a lot of review comments aimed at the style of committing.  

Hi Chris,

I agree with you.

> So now we are at a junction.  Should I ask Manjuanth to stop test automation development to work on squashing logical commits or should I keep him working on automating the code we are developing.  I certainly understand the need for a git history that tells the story.  It also makes sense to read commit best practices as those listed by Stewart and Patrick and become better developers for it.

Becoming better developers is always a good thing no?

> I ask is there anything that would put a hold on merging the pull request as is?  I do need a response from those with comments as you are the ones that put the time and effort in to reviewing it in the first place.  

I think it would be best not to merge the series as is. I'm willing to let a
lot slide for tests because yay tests and if Manjuanth can address the biggest
issues that would be fantastic!

Highest on my list of big problems with the series is that it appears
duplicated, I'm not even sure how that could have happened. Other issues are:
The need for squashed patches.
 - Fixes to patches in the same series
 - Having a patch to add tests and then a subsequent one to add more
 - Multiple readme patches
 - Adding and then removing files within the same series.

Even just that, running a few git commands to make the series easier to follow
would be 80% of the way to making it perfect and tests > perfection.

Other things which wouldn't be much work would be typo issues and commit

The overall content of the patches looks like something we can live with for
the sake of having tests and if making this series Linux kernel level perfect
comes at the cost of more tests then I definitely vote for doing the easy 80%.


> Chris Austen
> POWER Systems Enablement Manager 
> (512) 286-5184 (T/L: 363-5184)
> _______________________________________________
> openbmc mailing list
> openbmc at

More information about the openbmc mailing list