Re: [tip:x86/cache 9/13] arch/x86/kernel/cpu/resctrl/rdtgroup.c:1456:6: warning: variable 'h' set but not used

[Borislav Petkov <bp@alien8.de>]

On Fri, Feb 10, 2023 at 11:15:00AM +0800, Philip Li wrote:
> Sorry for confusion, we do full make for the kernel to gather all issues.
> And we try to provide a quicker way for developer to reproduce the issue,
> thus the step in reproduce part shows the subdirectories that could reproduce
> the reported issue.

Aah, ok.

I guess those reproduction instructions should then say:

"... the fastest way to reproduce is ..."

Or so.

> Got it. Internally, we use the merge strategy to combine as many branches
> as we can to run build testing, and bisect the issues if found. We need
> further think of how to let high priority issues to be reported out earlier.

Hmm, I wouldn't do that.

If you test a whole bunch of patchsets, then you're not really testing
each of them but you're testing the common thing which you've created by
merging.

I think it makes most sense to test single patchsets, single tree
branches which should hopefully contain commits which belong to a single
topic - this is how we aim to do them in the tip tree, at least, but
others do different things, and so on.

And then test linux-next. But I think you do that.

> Thanks, so far, we recommend to use --base option in our report mail, like
> 
> 	[If your patch is applied to the wrong git tree, kindly drop us a note.
> 	And when submitting patch, we suggest to use '--base' as documented in
> 	https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> And we do need a place to put such information, so people can refer to. Without
> a public available site for us, we will update https://github.com/intel/lkp-tests/wiki
> firstly to host enough information.

Right, make that URL part of every report so that people can go and read
about it and know what are best practices. I'll try to remember myself
to use --base too.

> Thanks for the hint, this is doable, and we definitely need do this. I will
> plan it to have initial version ready by Q1.

You have a wiki page above already. Add a status subpage and dump into
it periodically what current trees are being tested. And this way you
have *something* to go with. You can always improve it later on.

> Thanks a lot Boris, these suggestions are very helpful to further improve the
> 0-day ci service.

You're welcome - I'm glad that can be of help.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette