On Fri, Sep 23, 2022 at 11:15 AM Kellen Renshaw
<email address hidden> wrote:
>
> I have put up a draft SRU exception page at
> https://wiki.ubuntu.com/MakedumpfileUpdates. Comments/edits are welcome.
> I am working on finding an appropriate place for test vmcores to be
> stored.
Awesome! Thanks for starting this. I made some edits already, but
here's some other things I'd recommend:
- Provide links under resources (it's a web page!)
- be more precise about what will be tested, ideally in a checklist
form. Make it clear enough that you could give the list to another
developer and they would run the same tests and get the same results.
- Testing other architectures should not be optional IMO. makedumpfile
has architecture specific knowledge. You could easily break one w/o
noticing on another.
- Mention the plan to filter a pool of saved dump files as a
regression test. That is key IMO.
- If you have the regression testing pool, I don't see any reason to
have to do the full kdump process everywhere. Just do that once (one
kernel, one arch) to make sure the kdump-tools<->makedumpfile
interface has been preserved. Testing the full crash dump process is
painful, but makedumpfile really is just used as a filter, and we can
test that easily.
On Fri, Sep 23, 2022 at 11:15 AM Kellen Renshaw /wiki.ubuntu. com/Makedumpfil eUpdates. Comments/edits are welcome.
<email address hidden> wrote:
>
> I have put up a draft SRU exception page at
> https:/
> I am working on finding an appropriate place for test vmcores to be
> stored.
Awesome! Thanks for starting this. I made some edits already, but ->makedumpfile
here's some other things I'd recommend:
- Provide links under resources (it's a web page!)
- be more precise about what will be tested, ideally in a checklist
form. Make it clear enough that you could give the list to another
developer and they would run the same tests and get the same results.
- Testing other architectures should not be optional IMO. makedumpfile
has architecture specific knowledge. You could easily break one w/o
noticing on another.
- Mention the plan to filter a pool of saved dump files as a
regression test. That is key IMO.
- If you have the regression testing pool, I don't see any reason to
have to do the full kdump process everywhere. Just do that once (one
kernel, one arch) to make sure the kdump-tools<
interface has been preserved. Testing the full crash dump process is
painful, but makedumpfile really is just used as a filter, and we can
test that easily.
-dann