• Save
Contributing to Upstream Open Source Projects
Upcoming SlideShare
Loading in...5
×
 

Contributing to Upstream Open Source Projects

on

  • 3,597 views

A presentation I gave to members of the Yocto Project team on how to most effectively get some of the work we're doing into upstream projects.

A presentation I gave to members of the Yocto Project team on how to most effectively get some of the work we're doing into upstream projects.

Statistics

Views

Total Views
3,597
Views on SlideShare
2,976
Embed Views
621

Actions

Likes
0
Downloads
0
Comments
0

5 Embeds 621

http://blog.zenlinux.com 610
http://feeds.feedburner.com 5
http://www.linkedin.com 3
https://www.linkedin.com 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Contributing to Upstream Open Source Projects Contributing to Upstream Open Source Projects Presentation Transcript

    • Contributing to Upstream Open Source Projects Best Practices for the Yocto Project Team Scott Garman <scott.a.garman@intel.com> http://yoctoproject.org February 15, 2011
    • Getting to the Point When submitting patches to upstream projects, the name of the game is making it as convenient as possible for the maintainers to accept and integrate your patch.
    • Do Your Homework
      • How is this patch relevant to the upstream project?
      • Does it:
        • Fix a bug?
        • Add a feature (that the maintainer wants)?
        • Add a new test case to their test suite?
      The benefit of the patch should be articulated clearly and concisely.
    • Research How Upstream Projects Accept Patches
      • Search for documented processes on the project's web site (search for “get[ting] involved”, “submit patch”, “developer guide”)
      • Look for HACKING or README files in the source tree
      • Review project mailing list archives to find previous examples of patch submissions
    • Examples of Well-Organized Project Participation Guidelines OpenEmbedded: http://openembedded.org/index.php/How_to_submit_a_patch_to_OpenEmbedded GCC: http://gcc.gnu.org/contribute.html Mozilla: https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch GNOME: http://live.gnome.org/GnomeLove/SubmittingPatches
    • What NOT To Do
      • Submit the patch privately directly to the maintainer *
      • Submit a compressed patch using gzip or similar tools
      • Submit a patch without a clear explanation of what it does and why
      • Use language that could be interpreted as being critical of the project, its code, or its members
      * Possible exceptions may include critical security bugs or if the project's contribution instructions explicitly ask you to submit patches to individuals
    • Making Your Patch a Slam-dunk: Follow the project's coding style
      • Use the same whitespace style (tabs vs. spaces) that the surrounding code uses
      • Avoid trailing whitespace
      • Use the same format for commit logs (git-based projects tend to be especially strict about this)
      • Keep your commits atomic and logically separated
    • Making Your Patch a Slam-dunk: Tie it to a bug number
      • Find the project's bugtracker
        • Search for the bug
        • If it doesn't exist, file a new bug
      • Some projects, e.g. Mozilla, do not accept any code unless it is associated with a bug filed in Bugzilla
    • Making Your Patch a Slam-dunk: Mention how it has been tested
      • From the maintainer's perspective, it is natural to be cautious when accepting patches from new contributors who may not know the codebase well.
      • Testing your code shows not only that your patch doesn't break anything, but that you're disciplined enough to test your code as a matter of routine.
      • “ This patch has been tested on the Yocto Project's autobuilder and works for all of our architectures: x86/x86-64/arm/mips/ppc”
    • Making Your Patch a Slam-dunk: Include documentation patches
      • This is more true for feature additions than bugfixes
      • Keeping documentation up to date is one of the more challenging and thankless jobs a maintainer has to do
      • By including documentation patches, you will stand out above most other contributors as being detail-oriented and helpful
    • Dealing with Rejection Sometimes your patch will be rejected. It is important to make sure you understand whether the rejection is due to fundamental differences in philosophy, or whether the patch might be accepted if it were re-worked according to the preferences of the maintainer. If it's the former case, remain polite and accept it. Explain that we will continue to maintain the patch and are open to future collaboration.
    • The maintainer may want the patch re-worked to meet project requirements. This is acceptable, and the work should be done and the patch re-submitted. Remember, every patch we get upstream means we no longer have to maintain it . This saves us more work in the long run. It's also part of being a good citizen in open source communities! Dealing with Rejection
    • Common Patch Submission Workflow with Git
      • Clone the upstream git repo, make changes in your own branch and commit them
      • git format-patch -N (where N is the number of commits to include in the patchset)
      • Patch file(s) will be generated in the current directory. Use them as input to git send-email :
      • git send-email --to=upstream@devel-list <patchfile1> <patchfile2> …
      • man git-send-email for more details
    • GitHub Workflow
      • GitHub is a popular host for some upstream projects
      • You can create an account and use it when working on open source projects for free
      • GitHub allows you to clone repositories and submit pull requests via its web interface
      • Screencast tutorial here: http://teachmetocode.com/screencasts/getting-started-with-github/
    • Q&A I will also post this information on the Yocto Project wiki: http://wiki.yoctoproject.org