[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Re-working the patch submission guide
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |