[LTP] [PATCH v3 2/2] doc: Add ground rules page

[Li Wang]

Cyril Hrubis <chrubis@suse.cz> wrote:

> This is a continued effort to write down the unwritten rules we have in
> the project. Feel free to suggest more topics for the page.
>
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

Reviewed-by: Li Wang <liwang@redhat.com>


> +Split changed into well defined chunks
> +======================================
> +
> +When sending patches to the project make sure to split the work into small well
> +defined chunks. Patch that changes too many files and does too many different
> +things is not going to get reviewed soon or possibly may not get any reviews at
> +all. Ideally patch should do a single logical change. However at the same time
> +make sure not to break the code in the middle of patchset. Each patch in a
> +sequence has to compile and function properly after it has been applied.

How about splitting it into sub-items for better readability:

"When submitting patches, split your work into small, well-defined changes.
Patches that touch many files or mix unrelated refactors, behavior changes,
and new features are difficult to review and are likely to be delayed
or ignored.

Aim for one logical change per patch. If the work naturally spans
multiple steps,
send it as a patch series where each patch:

  - builds/compiles successfully,
  - keeps tests and tooling functional,
  - does not introduce intermediate breakage,
  - has a clear commit message to explain the change,
  - Significant changes need to be detailed in the cover letter."


> +Kernel features and RCs
> +=======================
> +
> +LTP tests or fixes for kernel changes that have not yet been released may be
> +posted to the LTP list for a review but they will not be be accepted until
> +respective kernel changes are released. Review of such changes is also
> +considered to be lower priority than rest of the changes. This is because
> +kernel changes especially in the early RC phase are volatile and could be
> +changed or reverted.

I'd add one more requirement for this rule:

"Such patches should explicitly include keywords in the theme to indicate that
the feature is in the staging phase.
Examples:
    Subject: [PATCH v1][STAGING] fanotify: add test for <feature>
(requires v6.19-rc3)"

> +In a case that a test for unrelased kernel is really needed to be merged we do
> +not add it to the list of test executed by default and keep it in
> +:master:`runtest/staging` file until the kernel code is finalized.



--
Regards,
Li Wang