COLLECTED BY
Collection:Save Page Now Outlinks
TIMESTAMPS
This page describes the sponsoring part of the sponsoredcontribution process for theJDK andJDK Update Projects. OtherProjects may follow these conventionsor may establish their own; please consult the Project's pages fordetails.
This process is intended for developers who haveCommitter rights to the JDK or JDK UpdatesProjects. It provides guidelines for Committers to help developerswho don't yet have `push' rights (i.e.Contributors orAuthors ) become familiar with theexpectations, standards, and mechanics of the development process.A Sponsor's role is to offer constructive advice and eventuallypush the sponsored contribution into the correspondingMercurial repository.
As this document focuses on the sponsoring part, in order to getthe full picture, please take a look at the'How to contribute' document.
It should go without saying that as a Committer for a Project,you should be subscribed to and actively participating in allappropriatemailinglists. This includes both Project mailing lists and anyGroup mailing lists where technicaldecisions may be made for the area.
As a Sponsor, Contributors will look up to you for guidance toget their contributions into the Project - your actions willdetermine whether Contributors will feel welcome and want to engagefurther with the Project beyond their initial attempt, or not.Let's not lose enthusiastic, engaged and technically competentContributors due to a lack of communication. If there is a requestin your area of expertise and you can't address it, at leastacknowledge receipt of the request and provide an estimate for whenyou'll be able to give it your attention. A frank explanation ofyour time constraints or commitments will be appreciated andrespected.
Opportunities to sponsor contributions occur in the OpenJDK maillists. Since Contributors are encouraged to discuss their intendedchanges before they submit a patch, the ideal time to declare yoursponsorship is during that initial conversation. As a Sponsor youshould offer advice and collaborate with the contributor asnecessary to produce a high-quality patch. In addition tosponsoring changes to code you regularly maintain, there may beother areas where you can serve as a Sponsor.
After publicly committing to sponsoring a contribution, you needto "claim the sponsorship request" in the bug database. To do thatyou need to perform three steps:
first assign the bug to yourself,
then add a comment providing the name of the Contributor and asummary 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 OpenJDKbug then create one in thebug database.
You're now ready to review the proposed changes. Some changesmay be trivial, like spelling fixes. Others may require a moreintensive review - including, for example, a review by theCSR.
As a Sponsor, you may need to work with theContributor to make any necessarychanges, until you and the Contributor are satisfied with theresult, and you are satisfied that the proposed contribution willpass 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 arecovered by an Oracle Contributor Agreement (OCA) or equivalentcorporate agreement. TheOCASignatories List is the complete set of individuals or entitieswho may contribute code to any OpenJDK Project.
Once the contribution passes the review and build-and-testprocesses, you're ready to move on to the next step.
Push the change into your favorite team Mercurial forest. Youshould always make sure that changesets are credited appropriately.There are two alternatives:
Authors have the option of creatingchangesets directly. Their OpenJDK username will be recorded as theauthor of the Mercurial changeset.
Contributors are credited withtheContributed-by: line in thechangesetcomment.
Contributed-by: Ben Bitdiddle <ben@bits.com>
withBen Bitdiddle replaced by the actual name ofthe Contributor, andben@bits.com replaced by theire-mail address.
Regardless of who created the changeset, make sure that thecomment follows thestandardformat which includes a to reference the bug id.
Once you've done the push, the bug's status/resolution willautomatically be set to "Resolved/Fixed" and the "Resolved inBuild" field to "team".
If all goes well, the sponsored contribution will gradually makeits way from the initial forest into which it was pushed up to themaster area of theProject, andappear in a build. When the contribution reaches the master area,the bug's "Resolve in Build" field will be automatically updated to"master".
Sponsoring new contributions is an important activity - it's howthe engineering culture of aProjectgets passed on from the core group to newContributors, from one generation to thenext. It should be fun, so please celebrate the contributionsyou've sponsored by mentioning them on your blog. Congratulateother Sponsors on their work. Take pride in the value you provideto Contributors. Their success reflects well on you.
