How to sponsor
This page describes the sponsoring part of the sponsored contribution process for the JDK 8 and JDK 7 Update Projects. Other Projects may follow these conventions or may establish their own; please consult the Project's pages for details.
This process is intended for developers who have Committer rights to the JDK 8 an JDK 7 Update Projects. It provides a guideline for Committers to help developers who don't yet have `push' rights (i.e. Contributors or Authors ) become familiar with the expectations, standards, and mechanics of the development process. A Sponsor's role is to offer constructive advice and eventually push the sponsored contribution into the corresponding Mercurial repository.
As this document focuses on the sponsoring part, in order to get the full picture, please take a look at the 'How to contribute' document.
0. Subscribe to OpenJDK mailing lists
It should go without saying that as a Committer for a Project, you should be subscribed to and actively participating in all appropriate mailing lists. This includes both Project mailing lists and any Group mailing lists where technical decisions may be made for the area.
As a Sponsor, Contributors will look up to you for guidance to get their contributions into the Project - your actions will determine whether Contributors will feel welcome and want to engage further with the Project beyond their initial attempt, or not. Let's not lose enthusiastic, engaged and technically competent Contributors due to a lack of communication. If there is a request in your area of expertise and you can't address it, at least acknowledge receipt of the request and provide an estimate for when you'll be able to give it your attention. A frank explanation of your time constraints or commitments will be appreciated and respected.
1. Volunteer to sponsor a contribution
Opportunities to sponsor contributions occur in the OpenJDK mail lists. Since Contributors are encouraged to discuss their intended changes before they submit a patch, the ideal time to declare your sponsorship is during that initial conversation. As a Sponsor you should offer advice and collaborate with the contributor as necessary to produce a high-quality patch. In addition to sponsoring changes to code you regularly maintain, there may be other areas where you can serve as a Sponsor.
After publicly committing to sponsoring a contribution, you need to "claim the sponsorship request" in the bug database. To do that you need to perform three steps:
first assign the bug to yourself,
then add a comment providing the name of the Contributor and a summary of the approach to solving the problem,
and finally set the bug's status to "In Progress".
If the contribution doesn't already have an associated Oracle bug then create one in the bug database.
2. Review the contribution
You're now ready to review the proposed changes. Some changes may be trivial, like spelling fixes. Others may require a more intensive review - including, for example, a review by the CCC.
As a Sponsor, you may need to work with the Contributor to make any necessary changes, until you and the Contributor are satisfied with the result, and you are satisfied that the proposed contribution will pass any relevant review processes and build-and-test processes. That may take more then one iteration in the worst case.
As part of your review, you must verify that the changes are covered by an Oracle Contributor Agreement (OCA) or equivalent corporate agreement. The OCA Signatories List is the complete set of individuals or entities who may contribute code to any OpenJDK Project.
Once the contribution passes the review and build-and-test processes, you're ready to move on to the next step.
3. Push the contribution into a forest
Push the change into your favorite team Mercurial forest. You should always make sure that changesets are credited appropriately. There are two alternatives:
Authors have the option of creating changesets directly. Their OpenJDK username will be recorded as the author of the Mercurial changeset.
Contributed-by: Ben Bitdiddle <email@example.com>
Ben Bitdiddlereplaced by the actual name of the Contributor, and
firstname.lastname@example.org by their e-mail address.
Regardless of who created the changeset, make sure that the comment follows the standard format which includes a to reference the bug id.
Once you've done the push, set the bug's status/resolution to "Resolved/Fixed" and the "Resolved in Build" field to "team".
4. Integration in a build
If all goes well, the sponsored contribution will gradually make its way from the initial forest into which it was pushed up to the master area of the Project, and appear in a build. When the contribution reaches the master area, the bug's "Resolve in Build" field will be changed to "master" by your local integrator.
5. Celebrate your contributions
Sponsoring new contributions is an important activity - it's how the engineering culture of a Project gets passed on from the core group to new Contributors, from one generation to the next. It should be fun, so please celebrate the contributions you've sponsored by mentioning them on your blog. Congratulate other Sponsors on their work. Take pride in the value you provide to Contributors. Their success reflects well on you.