Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Zero to Open Source Hero: Contributing to Spring projects

From Zero to Open Source Hero: Contributing to Spring projects

Vedran Pavić

May 19, 2017
Tweet

More Decks by Vedran Pavić

Other Decks in Technology

Transcript

  1. @spring_io #springio17 Agenda About me What it means to contribute?

    Why contribute? Where to start? Managing your forks Anatomy of a good Pull Request Lifecycle of a Pull Request Conclusion Q&A
  2. @spring_io #springio17 Vedran Pavić • Software Development Engineer at Kapsch

    CarrierCom d.o.o. • Open Source Software enthusiast – Java, Spring, Linux • Active contributor to multiple Spring projects • Spring Session committer
  3. @spring_io #springio17 There’s more to contributing than just code •

    Helping other users matters – Issue tracker, Gitter, Stack Overflow • Reporting issues matters – stackoverflow.com/help/mcve • Documentation matters - a LOT
  4. @spring_io #springio17 What are the prerequisites? • Knowledge of Git,

    related workflows and GitHub • Willingness to discuss, elaborate and rework your proposals • Contributor License Agreement (CLA) – cla.pivotal.io • Patience :)
  5. @spring_io #springio17 Spring embraces contributions • Move to GitHub made

    contributing easy • Projects are well managed with contributors in mind – Easy to build & import in IDE • Contributions are properly attributed – Commits, @author tags
  6. @spring_io #springio17 What do you get out of it? •

    Learn new skills, improve existing ones – Apply the ideas from Spring projects to your own projects • Meet the people behind Spring and collaborate with them • Grow your reputation • Contributing is an empowering experience
  7. @spring_io #springio17 spring.io as service discovery • spring.io/projects contains pointers

    to all relevant project’s resources – issue tracker, source repository, CI server, Stack Overflow tag
  8. @spring_io #springio17 Get familiar with the project • Source repositories

    contain resources for contributors – README, CONTRIBUTING, CODE_OF_CONDUCT • Note the project’s active branches • Check out the issues marked for contribution – JIRA roadmap, GitHub labels
  9. @spring_io #springio17 Get familiar with the project • Project build:

    Gradle or Maven • Single-click builds that are easy on the newcomers – ./gradlew build or ./mvnw clean install • Check out resources for contributors for more details – Some projects have special build profiles, for example documentation builds
  10. @spring_io #springio17 Get familiar with the project • Note the

    preferred Git workflows – Merge vs rebase • Note the preferred code style – Check source repository for IDE config files • Use other contributions as a reference • Reach out to the project maintainers or community – Gitter or Stack Overflow
  11. @spring_io #springio17 Creating a fork • A fork is a

    copy of a repository • Serves as a base for contributing activities
  12. @spring_io #springio17 Keep your forks lean • Forking creates a

    copy with all branches of the original repository – Some of them are not active, or not needed • Deleting needless branches makes your fork easier to maintain
  13. @spring_io #springio17 Keep your forks up to date • Configure

    a remote that points to original repository $ git remote add upstream [email protected]:spring-projects/spring-session.git $ git remote -v origin [email protected]:vpavic/spring-session.git (fetch) origin [email protected]:vpavic/spring-session.git (push) [email protected]:spring-projects/spring-session.git (fetch) [email protected]:spring-projects/spring-session.git (push)
  14. @spring_io #springio17 Keep your forks up to date • Fetch

    and merge the changes from the upstream repository $ git fetch upstream ... From github.com:spring-projects/spring-boot 216506d20f..e236b71615 1.5.x -> upstream/1.5.x 3abd8d3adf..269cea291c master -> upstream/master $ git checkout 1.5.x && git merge upstream/1.5.x && git push $ git checkout master && git merge upstream/master && git push
  15. @spring_io #springio17 Keep your forks up to date • Tags

    need to be handled separately $ git fetch upstream --tags ... From github.com:spring-projects/spring-boot * [new tag] v1.5.3.RELEASE -> v1.5.3.RELEASE $ git push --tags
  16. @spring_io #springio17 Clean up your local branches • Clean up

    after deleting branches on GitHub $ git remote prune origin Pruning origin URL: [email protected]:spring-projects/spring-integration * [pruned] origin/INT-4248 $ git branch -vv | grep gone INT-4248 a2458f78f [origin/INT-4248: gone] Use StringRedisTemplate $ git branch -d INT-4248
  17. @spring_io #springio17 Add new upstream branches • As development of

    the upstream goes on, new branches $ git checkout --track upstream/4.2.x $ git branch -vv | grep upstream * 4.2.x f166bd1bd [upstream/4.2.x] Groovy test: Fix format for `MM` instead of `mm` $ git push --set-upstream origin/4.2.x
  18. @spring_io #springio17 Before you start • If the issue ticket

    exists, drop a note you’re working on it – To help prevent duplicating efforts • Otherwise new issue might be needed • Pick the appropriate target branch – Semantic versioning matters - semver.org • If in doubt about target branch consult the maintainers
  19. @spring_io #springio17 Working on your changes • Configure your IDE

    to use appropriate code style – look for Eclipse formatter configuration files – IntelliJ IDEA: Eclipse Code Formatter plugin • Create a dedicated feature branch for your changes - use target branch as base • Initially make your changes a single commit unless there’s a good reason to do otherwise
  20. @spring_io #springio17 Tests or it didn’t happen • Unit tests

    are a must if you touch the code – JUnit, AssertJ, Mockito, Spring Test support • Bug: add a test that reproduces the issue – Check out the contributors resources • New feature: a substantial set of tests is expected – Check the existing unit tests for similar/related functionalities
  21. @spring_io #springio17 Write good commit messages • There are some

    excellent resources on writing good commit messages – Check out the contributors resources – chris.beams.io/posts/git-commit • Good commit message does you a favor when opening the PR – Commit message is automatically used for PR description on GitHub
  22. @spring_io #springio17 Build project before opening PR • Builds are

    single-click and easy to run – Check contributor resources for info on additional build profiles, like documentation • Contains additional checks, such as Checkstyle – import the IDE code style config – Use Checkstyle plugin for your IDE • Tests the impact of your changes on entire project
  23. @spring_io #springio17 Build project before opening PR • sometime build

    fails for reasons unrelated to your changes – check the project’s source repository and/or CI server for info
  24. @spring_io #springio17 Pull Request checks • Submitting a PR will

    usually trigger some actions – Contributor License Agreement (CLA) check – PR branch build on Travis CI
  25. @spring_io #springio17 Pull Request checks • first time contributors need

    to sign CLA – cla.pivotal.io has all the details – The process in nearly automatic these days • Minor changes can skip some checks – CLA not required - add “Obvious Fix” to the PR description – Skip the Travis CI build - include “[ci skip]” in commit message
  26. @spring_io #springio17 Pull Request checks • Travis CI builds can

    sometime get stuck or fail for transient reasons – You can trigger the build again by closing and reopening the PR – Or more elegantly using Git $ git commit --amend --no-edit && git push --force
  27. @spring_io #springio17 Discussion and reviews • Expect discussion on your

    proposals, especially if PR is about new features • Often times you’ll be asked to rework your proposal • Don’t open a PR and walk away – If unsure how to rework your proposal ask for help – If you have no time to rework let the maintainers know
  28. @spring_io #springio17 Updating your Pull Request • requested changes are

    done on the existing PR - no need to close existing and open new one • you can simply push more commits to your PR branch • you can update the existing commit (force push is needed) $ git add . && git commit --amend --no-edit && git push --force
  29. @spring_io #springio17 Updating your Pull Request • rebase reworked changes

    on the current state of base branch – remember the tips for managing forks – your PR has been on the shelf for some time
  30. @spring_io #springio17 In the end • You didn’t receive response

    - be patient – It might get some time for maintainers to get to your PR • Your contribution was not accepted - don’t get discouraged – If you’re active in the open source this will happen sooner or later :) • Your contribution was accepted - welcome to the club!
  31. @spring_io #springio17 Spring contributions • Spring and entire ecosystem around

    it wouldn’t be what it is today without contributors • Significant efforts have been made to make Spring projects contributor friendly
  32. @spring_io #springio17 The time is right to start contributing •

    With Spring 5 around the corner there’s a lot of movement across the Spring ecosystem – Move to Java 8 as baseline, introduction of reactive programming model • Most Spring projects are moving to new major release as a consequence – Chance to make significant changes