[elbe-devel] [PATCH v1] CONTRIBUTE: Add documentation

[Bastian Germann]

Am 11.08.22 um 18:13 schrieb Viraj Shah:
> * Add initial documentation for contribution guideline.
> 
> Signed-off-by: Viraj Shah <viraj.shah at linutronix.de>

Please move README's  Contributing section over with this patch and do not duplicate info.

> ---
>   CONTRIBUTE | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 72 insertions(+)
>   create mode 100644 CONTRIBUTE
> 
> diff --git a/CONTRIBUTE b/CONTRIBUTE
> new file mode 100644
> index 000000000..0a8168f54
> --- /dev/null
> +++ b/CONTRIBUTE
> @@ -0,0 +1,72 @@
> +CONTRIBUTING
> +============
> +Contributions from everyone are welcome. Please follow the guidelines when
> +filing a Github issue or sending the development patches.
> +
> +Filing Issues
> +-------------
> +- So far, Github issues are used to track bugs and feature requests.
> +- Bugs are tracked from the latest version of released Elbe. It is still
> +  recommended to test the master branch of github-elbe(elbe-mainline)
> +  if the bug still persists there. So, please validate the issue with
> +  master branch of elbe or atleast the latest version of elbe release.
> +- When filing a feature request, please check in the master branch if
> +  a similar feature is already available.
> +- Give reproducing steps in detail for the issues. In the best case, having
> +  an xml file would be good.
> +- For a fail build, please give the exact error message.
> +  In the best case, having a log file would be good.
> +
> +Submitting Patches
> +------------------
> +
> +Before:
> +~~~~~~~
> +
> +- We tend to follow the linux-kernel standards while accepting the patches.
> +  So, please go through [1] before sending the patches.
> +
> +- Please describe the changes in the commit message. If it is a series of
> +  patches, please consider explaining the change in the cover letter of the patch
> +
> +- One of the standard methods for generating a series of patches with a cover-letter
> +  is using "git format-patch" tool. Also, "git send-email" tool can be used to send
> +  a patch.
> +
> +- We tend to use the kernel coding style as much as possible for this project.
> +  So, please go through [2] before sending the patches.

This is still a Python project and the C codestyle does not apply.
Please mention pylint instead, for which Elbe has a configuration file.

> +- Please check your patches using checkpatch.pl tool from the linux scripts
> +  repo. This will help both developer and reviewer in knowing the obvious style
> +  errors. And consider having the patches checked using codespell linux package
> +  to see the obvious typos.

I do not think that these tools will be very helpful for Elbe patches.
Please try and report.

> +[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> +[2] https://www.kernel.org/doc/html/latest/process/coding-style.html
> +
> +After:
> +~~~~~~
> +
> +- Please be patient after submitting patches. Sometimes, maintainers are
> +  working on multiple projects, so they might not find time to reply immediately.
> +  Please give them a gracious time of 2 weeks before pinging the mailing list
> +  about the status of the patch.

Please extend this to one month.

> +Developer's guide
> +-----------------
> +- To retrieve the failed build artifacts after a failed build, please use
> +  "elbe control get_file" tool. If that doesn't work for some reason, user

..., a user

> +  can dive into initvm using "elbe initvm attach", user id and password are

the default user id and password ...

> +  "root". Change directory to the project and scp the files to host. Please
> +  note that port no. 5022 needs to be used for the ssh pipe.

Please replace the last two sentences with a hint where the project files are located on an initvm.

> +- Because we are developing the python code here, whitespace and tabs are
> +  sensitive topics. Especially when it is difficult to detect because program

They are not sensitive in Python. Only use spaces. In Elbe, tabs should only be used in Makefiles.

> +  runs in initvm and development is done in host computer. Before testing the
> +  program in initvm and a sending patch, run the program using python3 simply on

typo: a sending

> +  host to check for the indentation errors. That would save time for further
> +  debugging.

Please explain how to use --devel mode in initvm.

Please describe editing the XML schema, which is

> +- To print the debugs, feel free to use "logging.info" tool from elbe.
> +

  What do you mean with this?