[elbe-devel] [PATCH v2 1/1] CONTRIBUTE: Add documentation

[Bastian Germann]

Am 20.10.22 um 13:04 schrieb Viraj Shah:
> * Add initial documentation for contribution guideline.

Thanks Viraj.
I will work from here.

> Signed-off-by: Viraj Shah <viraj.shah at linutronix.de>
> ---
>   CONTRIBUTE | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 61 insertions(+)
>   create mode 100644 CONTRIBUTE
> 
> diff --git a/CONTRIBUTE b/CONTRIBUTE
> new file mode 100644
> index 000000000..9b4218d6b
> --- /dev/null
> +++ b/CONTRIBUTE
> @@ -0,0 +1,61 @@
> +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 pylint code analyzer 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.
> +
> +[1] https://pylint.pycqa.org/en/latest/
> +
> +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 1 month before pinging the mailing list
> +  about the status of the patch.
> +
> +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, a user
> +  can dive into initvm using "elbe initvm attach", the default user id and
> +  password are  "root". The project files would be located in
> +  /var/cache/elbe/{PROJECTID}
> +
> +- Because we are developing the python code here, whitespace and tabs are
> +  sensitive topics. Especially when it is difficult to detect because program
> +  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
> +  host to check for the indentation errors. That would save time for further
> +  debugging.
> +
> +- Use spaces always in the python program. And restrict Makefile for tabs.