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

* [Xen-devel] [RFC] Re-working the patch submission guide
@ 2019-08-02 11:14 Lars Kurth
  2019-08-02 12:52 ` Jan Beulich
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Kurth @ 2019-08-02 11:14 UTC (permalink / raw)
  To: xen-devel, committers; +Cc: Viktor Mitin

Hi all,

In preparation of migrating docs to sphinx-docs, I first wanted to clean up https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches. Before I do some work on it, I wanted to outline my thoughts on the content

> 1 How To Generate and Submit Patches to the Xen Project 

> 1.1 Generating a patch 
This section seems to be fairly generic and maybe should live elsewhere and maybe should just be referred to from here

However, I think we need to explain the anatomy of a patch and patch series here. Maybe re-name this to Anatomy of a Patch and Patch Series
It should mention at least cover letters and probably also cover threading of patch series (and why it is important)
References to Hg should be deleted

> 1.2 Signing off a patch 
> 1.3 Making good patches 
> 1.3.1 Break down your patches 
> 1.3.2 Write a good description for each patch 
> 1.3.3 Cc the maintainer of the code you are modifying 
> 1.4 Providing a git branch

This entire section needs to be re-structures and organised alongside patches and patch series
- What’s in a patch: aka 1.2., 1.3.2, 1.3.3 relate to individual patches  
- What’s in a series: e.g. cover letter and what is expected – section 1.3.1 would naturally also fit into there and so would 1.4. 

> 1.5 Sending the patches to the list 
> 1.5.1 Setting up git send-email 
This should be kept

> 1.5.2 Using git send-email alone 
This should be removed from the document. I don’t mind moving it into a separate page (which can be referenced from the next section)

> 1.5.3 Simplest workflow: Git format-patch, add_maintainers.pl/get_maintainer.pl and git send-email 
This should be the main workflow and probably option 2 should be removed

> 1.5.4 Sending Patches Manually 
This should be removed or state NOT TO DO this

> 1.6 Review, Rinse & Repeat 

> 1.7 What If 
This should be moved into the new section (see above) on patch series

> 1.8 How to know when a patch has been committed 
Should probably point to our patchwork, patchew, … instances also

> 1.9 After your patch is committed 

> 2 How to Generate and Submit a Patch to Qemu-Xen 
> 3 How to Generate, and Submit a Xen Project Patch to the Linux Tree 
> 4 How to Generate and Submit a Xen related patch to FreeBSD 
> 5 How to Generate, and Submit a Xen Project Patch to MiniOS and Unikraft 

These can stay as they are

Regards
Lars

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

^ permalink raw reply	[flat|nested] 13+ messages in thread