If you are new to the Xen community and want to know how the development process works -- and in particular, if you want to know how you can get your changes in -- this talk is for you. My goal is that by the end you will have a framework for how the process works, and a good set of pointers and principles for being ready to dive in and submit your first patch -- or your first series. Topics will include: What's a maintainer? How does the development window and feature freeze work? How do I make a good patch series? What if I'm not sure if my code is a good idea or not? What if I need to make a big change and I'm not sure the correct approach?

1. Contributing to Xen
An Introduction

2. We want your patches!

3. Why we want your patches
• Personally: Gratification of knowing it’s useful
• Corporate: Mindshare and “Brand"
• Corporate: Our employers may want to use your code someday

4. But…

5. Free as in “puppies”

6. How does any patch get in?

7. Maintainers
• Nobody has a full understanding of the entire codebase
• The “One Little Change” problem
• Role: Long-term investment in keeping the code “clean”
• xen.git/MAINTAINERS
• xen.git/scripts/get_maintainer.pl
• Nested maintainership
• THE REST

8. Checking in a patch: When
• Approval from all maintainers whose code the patch touches
• Approval or acquiescence from everyone who has raised issues

9. Committers
• “Secretarial” role: Determine proper acks and apply patch
• “Final authority” / “Elder Council” role

10. Conflict resolution
• Try to achieve consensus
• Maintainers can overrule non-maintainers
• “Nested” maintainers can overrule (or stand-in for) lower-level maintainers
• Majority vote of committers can overrule a maintainer

11. Expect Iteration

12. Timing

13. Development cycle
• Development window
• “Last posting date” (+2 weeks)
• Feature freeze (~6 weeks)
• Release (June and December)

14. Writing a good patch (series)

15. A thousand unwritten rules
(You’re not going to get it right)

16. Audience
• Reviewer
• People looking for patches of interest

18. Audience
• Reviewer
• People looking for patches of interest
• “Archaeologist”
• “Chesterton’s Fence”

19. Coding Style
• Follow the coding style
• xen.git/CODING_STYLE
• xen.git/tools/libxl/CODING_STYLE

20. Make the patch an “argument"
• Persuade the reviewer…
• This patch / series is necessary
• This patch / series is the right way to solve the problem
• This patch / series is correct (no bugs)

21. Template for a changelog
• Current situation
• Why that’s a problem
• How this patch fixes it
• Any other changes the patch is making

23. Bisectibility
• Want every changset to build, and all existing functionality to work
• Break down into logical chunks, but:
• Don’t break existing functionality
• Don’t introduce bugs in one patch and fix them in another
• Can introduce code that isn’t used
• Don’t introduce code that doesn’t build

24. Mechanics
• git send-email
• --- line
• CC:

26. What [not] to put in a changelog
• References to already-public commits
• Short hash + short title
• 5d3214c (“xen/ept: Rename ept_invalidate_emt*”)
• References to previous discussions
• Summarize in changelog
• Include ref to longer discussion below --- line
• Referencing manuals
• Intel / AMD manuals ‘references’ don’t change
• e.g., Volume 3, 4.4.1

27. Reposting
• Version number (“v2”)
• --version=2
• List the changes

28. All-purpose pass: RFC
• Means “Request For Comments”
• Makes it clear you don’t expect this to be checked in as-is

29. Design Documents

30. Dealing with maintainers
• Communication style
• Unusual but OK: Short and direct
• Not OK: Demeaning
• Judgement call: Being unreasonable
• If you have a problem, contact the community manager
• ‘Pinging’
• If you haven’t heard anything in 2 weeks, reply to your own patch

31. Questions?