Re: [Xen-devel] [RFC] Re-working the patch submission guide

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 07/08/2019, 19:40, "Viktor Mitin" <viktor.mitin.19@xxxxxxxxx> wrote:

    On Wed, Aug 7, 2019 at 9:04 PM Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:
    >
    >
    > On 05/08/2019, 18:49, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote:
    >
    >     On 02/08/2019, 14:36, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote:
    >
    >         On 02/08/2019, 14:03, "Julien Grall" <julien.grall@xxxxxxx> wrote:
    >
    >
    >
    >             On 02/08/2019 14:02, Julien Grall wrote:
    >             > Hi Jan,
    >             >
    >             > On 02/08/2019 13:52, Jan Beulich wrote:
    >             >> On 02.08.2019 13:14, Lars Kurth wrote:
    >             >>>> 1.5.4 Sending Patches Manually
    >             >>> This should be removed or state NOT TO DO this
    >             >>
    >             >> Please don't. I'm not meaning to start using git for patch 
submission
    >             >> any time soon (if ever), and I don't see why this should 
be a
    >             >> requirement.
    >             > Well, someone using this is likely to mess it up. So I 
agree with Lars and this
    >             > should at least disagree and discourage to use it.
    >
    >             s/disagree/be removed/
    >
    >         OK. That seems to be agreed. The intention of removing it is to 
encourage newcomers to use the tools we have and which we know work.
    >
    >         Any other general feedback on how I am planning to approach this?
    >
    >         In essence, we will end up with
    >         * What's in a patch series/patch  - terminology and our 
expectations
    >            - Possibly with a link to some best practices and tools for 
planning for multiple versions (but should not be part of the doc itself)
    >            - Longer term it would be nice to get to something like: 
https://www.kernel.org/doc/html/v4.17/process/development-process.html - TBH I 
don't like the doc otself very much, but it has some good topics in it which we 
should cover
    >         * The tooling mechanics for a single patch: set-up and steps 
using get_maintainers.pl
    >         * Follow-up: multiple versions, checking when stuff has gone in, 
...
    >         * Specifics for QEMU, ...
    >
    >     Hi all, I put together a draft in 
https://docs.google.com/document/d/1jMsS_t4zoFSsIwZjImwIAxVCpbNohQbgu8X1S4QEIq8/edit?usp=sharing
 (also attached as PDF) which shows the changes to the original wiki page at 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
    >
    >     There are some problems in the "Break down your patches 
appropriately" section and maintainer input/guidance would be good. I also 
added some notes on what should be in a cover letter, but again this is just a 
starting point and again maintainer input/guidance would be good.
    >
    >     The Google docs URL allows commenting.  If you comment, please log in 
with an ID and/or state a name, such that I can follow up in case of questions.
    >
    >     I will wait until next week before encoding this on the wiki and as a 
second step, I will submit patches to the sphinx docs.
    >
    >     Regards
    >     Lars
    >
    > Hi all,
    >
    > I gave this a major re-work based on your feedback
    >
    > The output can be found at 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches and 
https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git
    >
    > The only areas which I think need improvements are
    > * Maybe a good example of a cover letter  - suggestions welcome
    > * A section under Code review around when you know you are getting close 
to the end: aka tracking ACKs
    > * How to know when a patch has been committed - should refer to 
patchwork, patchew, ...
    >
    > Feedback or edits are welcome
    >
    > Best Regards
    > Lars
    >
    
    Hi Lars,
    
    Thank you very much for the document work you are doing.
    
    It is probably worst adding one more note or section describing an
    automatic testing mechanism details and how to use it, and/or
    mentioning that the patches could be tested with Qemu (additionally to
    hw) manually as well. Not sure if it should be added to this document
    or another one. 

It should be added to another one  and referred to from here   

    On the one hand, the testing relates to patches
    submission (mean patches should be tested before submission anyway),
    but on the other hand, testing details are not about the patches
    submission process. In any case, we do not have any explicit
    documentation about patches testing for now. Is it correct?

No, not really. 
OSSTEST can be run locally but is hard to do
XTF would be a good option, but does not work on Arm
    
    Thank you again for improving Xen documentation.
    
You are welcome

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel