Automated test migration

[Daniel Axtens]

Hi Chris,

I agree with Cyril: a couple of hours would be plenty to make huge
inroads into the things we identified. I think we've also tended to pick
on style issues because they are the first things we see.

Another reason I think it's worth pursuing at least a little bit of
cleanup is that as we do more things in the open, and as (hopefully) a
community forms around OpenBMC, people are going to care more about this
stuff being done right. Now is a good time to practise - we get better
at it and we get better at estimating how long it will take and
factoring that into our estimates.

Regards,
Daniel

Cyril Bur <cyrilbur at gmail.com> writes:

> On Tue, 12 Jan 2016 23:09:22 +0000
> "Chris Austen" <austenc at us.ibm.com> wrote:
>
>>  I've known for a while that we would eventually move the automated test suites from https://github.com/mkumatag/openbmc-automation to https://github.com/openbmc/openbmc-test-automation.  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
> messages.
>
> 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%.
>
> Regards,
>
> Cyril
>> 
>> 
>> Chris Austen
>> POWER Systems Enablement Manager 
>> (512) 286-5184 (T/L: 363-5184)
>> 
>> _______________________________________________
>> openbmc mailing list
>> openbmc at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc