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

[Bastian Germann]

Am 16.09.22 um 16:14 schrieb 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.

The other series that touched the README is long accepted, so please edit this
patch to move the duplicated text instead of copying it.

>>> +- 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.

The problem is that submitting-patches.html has the basic rules but it
also says a lot which is only applicable to the kernel.

coding-style.html does not have any usable info for Elbe.

> Or, please suggest any other alternate tool that can be used here.

I have already: pylint.

>>> +[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.

The problem with that is that root is not allowed password login by default.
To use SSH for file copying you would have to describe how to get the initvm
to accept your login. Please do not do this for now and instead just say how
to attach to the initvm and how to use the --devel mode, which uses the local
git copy and can synchronize the files in a different way.

>>> +- 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.

That is not a "tool from elbe" but the generic Python logging framework.
I do not think we need to say that for someone who is able to contribute
to a Python project. It is just noise.