Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Engaging the Xen Developer Comminity

3 674 vues

Publié le

The Xen community can be a great resource for people wishing both to use and to improve Xen, and contributing to it can be rewarding both to individuals and to corporations. But they have a culture all their own, and like any foreign culture, it's a minefiled of potential misunderstandings and miscommunications. This talk will talk about the cultural values and norms of the Xen community, and how you can most effectively interact with them.

Publié dans : Technologie
  • Soyez le premier à commenter

Engaging the Xen Developer Comminity

  1. 1. Engaging the Xen Developer Community George Dunlap [email_address] Citrix Systems UK
  2. 2. Introduction <ul><li>Hardware Vendors </li></ul><ul><li>Software vendors </li></ul><ul><li>Academic </li></ul><ul><li>Public cloud providers </li></ul><ul><li>Private cloud providers </li></ul>
  3. 3. Why might people not be involved? <ul><li>Don’t know what there is to do </li></ul><ul><li>Don’t know the benefits of engaging the community </li></ul><ul><li>Don’t know how to engage community effectively </li></ul>
  4. 4. Goal: Enable you to engage developer community
  5. 5. Outline <ul><li>Ways that you can contribute to Xen development </li></ul><ul><li>Benefits and costs </li></ul><ul><li>Practical steps </li></ul><ul><li>Good bug reports </li></ul><ul><li>Good questions </li></ul><ul><li>Good patches </li></ul><ul><li>Running an open development project </li></ul>
  6. 6. How can you contribute?
  7. 7. How you can contribute <ul><li>Testing on your hardware / software </li></ul><ul><li>Submitting bug fixes </li></ul><ul><li>Suggesting interfaces / features </li></ul><ul><li>Submitting patches for interface changes </li></ul><ul><li>Development </li></ul><ul><li>Running an out-of-tree incubator project </li></ul>
  8. 8. Testing <ul><li>Need testing on a wide array of hardware / software </li></ul><ul><li>Test the functionality you use </li></ul><ul><li>Performance testing as well </li></ul><ul><li>What to test </li></ul><ul><li>Xen release candidates </li></ul><ul><li>Linux pvops release candidates </li></ul><ul><li>xen-unstable (occasionally) </li></ul>
  9. 9. Reporting <ul><li>Good bug report is good </li></ul><ul><li>Better yet: Patches! </li></ul>
  10. 10. Features <ul><li>Developers don’t see the learning curve </li></ul><ul><li>Suggest changes / clarifications to interface </li></ul><ul><li>Suggest new features which might be useful to you </li></ul><ul><li>Better yet: Patches! </li></ul>
  11. 11. Upstreaming your changes <ul><li>Standard practice: Freeze and fork </li></ul><ul><li>Main xen branch moves forward </li></ul><ul><li>What to do with a fork? </li></ul><ul><li>Stay forked </li></ul><ul><li>Forward-port patches </li></ul><ul><li>Back-port new features / fixes </li></ul><ul><li>Submit upstream </li></ul>
  12. 12. Why not upstream? <ul><li>A lot of extra work </li></ul><ul><li>Time constraints </li></ul><ul><li>Product deadlines </li></ul><ul><li>Academic deadlines </li></ul><ul><li>Required changes not acceptable upstream </li></ul>
  13. 13. Good bug reports <ul><li>What to include </li></ul><ul><li>Detailed hardware, software, steps to reproduce </li></ul><ul><li>As much error as you can </li></ul><ul><li>Serial console </li></ul><ul><li>Wiki page: ReportingBugs </li></ul>
  14. 14. Asking a question is asking someone else to work for you
  15. 15. Asking good questions <ul><li>Do as much work as you can yourself first </li></ul><ul><li>Search Google </li></ul><ul><li>Read the code </li></ul><ul><li>Context </li></ul><ul><li>Who are you? </li></ul><ul><li>What are you trying to accomplish </li></ul><ul><li>Make it specific </li></ul><ul><li>Show how you’ve tried to solve it yourself </li></ul><ul><li>Wiki page: AskingXenDevelQuestions </li></ul>
  16. 16. Sending code upstream Wiki page: SubmittingXenPatches
  17. 17. Three people to think about <ul><li>Person reviewing the patch </li></ul><ul><li>Does it do the right thing? </li></ul><ul><li>Are there any mistakes? </li></ul><ul><li>Person scanning through changesets </li></ul><ul><li>Do I need to look at this patch? </li></ul><ul><li>Archaeologist </li></ul><ul><li>6 months, 1 year, 2 years, 5 years </li></ul><ul><li>Why is the code the way it is now? </li></ul>
  18. 18. Guidelines <ul><li>Break your change into a series of patches </li></ul><ul><li>One logical change per patch </li></ul><ul><li>No regressions </li></ul><ul><li>Don’t fix a bug in one patch in a later patch! </li></ul><ul><li>Separate clean-up from functional changes </li></ul><ul><li>Even if it’s just a one-line change </li></ul><ul><li>One-line summary easy to scan </li></ul><ul><li>Description says what the patch does and why </li></ul>
  19. 19. Requirements <ul><li>Patch must apply </li></ul><ul><li>Beware of mailer mangling </li></ul><ul><li>Mercurial PatchBomb extension </li></ul><ul><li>Signed-off-by </li></ul><ul><li>Coding style </li></ul>
  20. 20. Interpreting responses <ul><li>American Culture: “Praise sandwich” </li></ul><ul><li>Hacker culture: Direct and to the point </li></ul><ul><li>“ I don’t think this is the right way to do this” </li></ul><ul><li>“ This is ugly” </li></ul><ul><li>“ This is unmaintainable” </li></ul><ul><li>Detailed criticism means “I want this patch accepted” </li></ul><ul><li>Ignoring is much worse than criticism </li></ul>
  21. 21. Open development
  22. 22. Project lifecycle <ul><li>Initial code dump </li></ul><ul><li>Basic functionality and framework </li></ul><ul><li>Incubation </li></ul><ul><li>Active development towards maturity </li></ul><ul><li>Growing community development </li></ul><ul><li>Project maturity </li></ul><ul><li>Ready to be used by others </li></ul><ul><li>Actively maintained </li></ul><ul><li>Retired / Archived </li></ul>
  23. 23. Types of projects <ul><li>In-tree </li></ul><ul><li>“ Tech preview” </li></ul><ul><li>Fairly self-contained </li></ul><ul><li>Example: Paging, page sharing, Remus </li></ul><ul><li>Out-of-tree </li></ul><ul><li>Major changes </li></ul><ul><li>Example: xen-arm </li></ul>
  24. 24. Open development: Theory <ul><li>Criteria </li></ul><ul><li>Movement towards upstreaming </li></ul><ul><li>Encouragement of a development community </li></ul><ul><li>Principles </li></ul><ul><li>Anyone should be able to influence </li></ul><ul><li>Influence should correlate to contribution </li></ul>
  25. 25. Open development: Practice <ul><li>One public shared repository </li></ul><ul><li>Handful of committers </li></ul><ul><li>One to begin with </li></ul><ul><li>Committers added based on contribution </li></ul><ul><li>All patches posted and discussed publicly </li></ul><ul><li>Technical decisions made in public </li></ul><ul><li>Private discussions must end with public proposal </li></ul>
  26. 26. Outline <ul><li>Ways that you can contribute to Xen development </li></ul><ul><li>Benefits and costs </li></ul><ul><li>Practical steps </li></ul><ul><li>Good bug reports </li></ul><ul><li>Good questions </li></ul><ul><li>Good patches </li></ul><ul><li>Running an open development project </li></ul>
  27. 27. Goal: Enable you to engage developer community
  28. 28. Questions?