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

[viraj]

On 8/30/22 03:10, Bastian Germann wrote:
> 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.
I will do this, once both the series are accepted.
>
>> ---
>>   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.
What do you want me to mention about pylint?

>
>> +- 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.
We still use linux based review process here. Even if the software is
based on python, the basic rules from the kernel standards still apply,
at least I can see that in our current review quality.

Or, please suggest any other alternate tool that can be used here.
>
>> +[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.
Noted
>
>> +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.
The document needs to be detailed for a new user. I would prefer to have
those sentences, and also give the project files location on 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.
I can make a note of it in next version, thanks.
>
>> +  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.
Interesting, I need to look into sources for that.😷
>
> 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?
logging.info can be used to printout the logs from elbe during run time.
you can check for examples simply by grepping on it.