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