[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>
  • From: Lars Kurth <lars.kurth@xxxxxxxxxx>
  • Date: Fri, 2 Aug 2019 11:14:57 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=lars.kurth@xxxxxxxxxx; spf=Pass smtp.mailfrom=lars.kurth@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Viktor Mitin <viktor.mitin.19@xxxxxxxxx>
  • Delivery-date: Fri, 02 Aug 2019 11:15:10 +0000
  • Ironport-sdr: YBPCAHPS5o1Wmy2df/gmn8Rtb8sx/k1Pdxp1DFeSufCo8pAfK2SitBDuPdnb2l6np5ns5Bq8PT jOT/j9rg3HoFY47ONbQb4Z/IHkr/kMWdsfVI6dtmWGTQ/4IdM1ModlfMzuYZN+BPc88QL8iNlD 3khPDqEnPwLCNXu9O7CVGp14g8F8zueYVWrhiSs8FE7dVjztl3jpm0Kp5eAB1BZYk96Y0CGP3Q vGPzdTLrhEraqwMeCdDoQqcUcJ8RiFU3+gPR7+Iq3gi7XHlRb78uv5JRN49l5CO+iClnFDBuIY jvY=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVSSOEZYGRU/jgzkCxBUMn3iC9Og==
  • Thread-topic: [RFC] Re-working the patch submission guide

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.