[OE-core] [PATCH] oe-selftest: runqemu: add tests for qemu boot and shutdown

Yeoh, Ee Peng ee.peng.yeoh at intel.com
Tue Apr 10 07:39:44 UTC 2018


Noted, I understood it now. Let me enhance the comment in the source code itself. 
It make sense. Thank you for your inputs! 

-----Original Message-----
From: Alexander Kanavin [mailto:alexander.kanavin at linux.intel.com] 
Sent: Tuesday, April 10, 2018 3:30 PM
To: Yeoh, Ee Peng <ee.peng.yeoh at intel.com>; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH] oe-selftest: runqemu: add tests for qemu boot and shutdown

On 04/09/2018 08:43 PM, Yeoh Ee Peng wrote:
> QA team were testing qemu boot image and shutdown on each qemu 
> architecture manually. Add automated test to test qemu boot on
> ext4 and nfs, finally check that it can shutdown properly.
> 
> Original runqemu tests was dedicated for MACHINE=qemux86-64 and it was 
> testing various live image (iso and hddimg) will be able to boot while 
> live image was not supported on all qemu architecture.
> 
> The new tests were designed as a separate class as this tests focus on 
> testing qemu boot and shutdown on each qemu architecture.
> Furthermore, this tests focus on testing qemu could shutdown as 
> expected.

1. I believe the clock on the machine that you use to send the patches isn't set correctly, it seems to be several hours in the past.

2. What I meant is that you comment the source code itself, not write a longer commit message. So that anyone reading the actual file can quickly figure out why there are two classes and what they test. 
Basically take the above, and write it down as comments in the actual file; take your time to write a nice, clear explanation (similar to what we discussed). Then the commit message can be more brief, basically the first paragraph above is enough.

The reason for this is that commit history is less obvious or convenient to use when you want to find explanations. You can certainly use 'git log <filename>', but it comes with lots of irrelevant commits, and if the code was restructured in the past, then the history of changes stops there.

Alex


More information about the Openembedded-core mailing list