Wiki code for Sponsor Tasks

Hide Line numbers
1: **Sponsor Tasks** The following outlines the process involved in being a sponsor. Note that we hope that many of these tasks will diminish over time, especially those “proxy” operations which currently require SWAN access. Note that, like much of our process, this is shrink-to-fit: many of these tasks are not needed for smaller changes.   
2: 
3: = Starting out
4: 
5: * First sign up to [[become a sponsor>>Community Group on.becoming-a-sponsor]].
6: * [[Subscribe>>mailto:request-sponsor-subscribe@opensolaris.org]] to the request-sponsor@opensolaris.org mailing list. This is the list used by sponsors to pick up a request and announce any changes in the state of the request.
7: * Check out the [[full list of requests>>Main.request_sponsor]] first to see if there are any requests awaiting a sponsor that fit your interest and experience. If nothing is pending or fits your experience, watch for new requests on the mailing list.
8: * When a request for sponsorship comes by which matches your interest, experience and availability, reply-all that you are volunteering to be the sponsor for that request, then take further discussion off-line with the contributor. Keep the contributor copied on just about all subsequent discussion in the steps below.
9: * Become familiar with the steps the [[contributor should perform and their instructions>>Main.participate]], so you can best gauge how to guide them.
10: * Triage: bug/RFE/project?
11: * Filing/updating bugs
12: ** Add “oss-sponsor” to the keyword list.
13: ** If you are filing a new bug or the existing bug does not have the "oss-request" keyword, add that keyword to the keyword list.
14: ** Put your e-mail address in Hook 5.
15: ** Put the contributor’s e-mail address in Hook 6. If there is an address already in Hook 6 field, replace it with the contributor’s email address.
16: ** The name of the contributor should be listed somewhere in the bug report, preferably in the Evaluation and/or Suggested Fix text as appropriate.
17: ** Mark yourself as the Responsible Engineer. Note that if this field is already filled in, then you should contact the RE and decide whether s/he should take over sponsorship instead, or if the RE should pass the bug on to you, or perhaps some other arrangement.
18: ** Notify the contributor of changes in the bug report as needed. Refer the contributor to the public bug report on [[bugs.opensolaris.org>>http://bugs.opensolaris.org/]]. Do not forward any e-mail updates from Bugster, as they may contain Sun confidential information. It is now possible to add the contributor to the Interest List for the bug, and Bugster will send sanitized externally safe versions of the bug report to the contributor whenever an update is made. Please be aware that this sanitized email strips out all email addresses, including RE and the sender, so external folks may have a difficult time finding the correct address to reply-to if you haven’t already established direct contact.
19: * Sponsors are responsible for updating the status of their work on contributions on an [[ internal wiki>>http://wikihome.sfbay.sun.com/swrm/Wiki.jsp?page=InProgresslist]] once a month. A reminder e-mail message with specific instructions will be sent out on the first of each month. Please follow the directions in those messages. DO NOT use the internal wiki to announce that you have picked up a request to sponsor or to announce changes to the state of a request in progress. As noted in the first bullet above, e-mail MUST be sent to the request-sponsor@opensolaris.org mailing list for those purposes.
20: 
21: = Develop, Test, Repeat
22: 
23: * Coordinate with technology owner(s).
24: * Help determine ideal design reviewers (if needed).
25: * ARC review (if needed):
26: ** The contributor should write the case, but may need help if s/he is inexperienced with the ARC (which nearly all contributors will be at the beginning).
27: ** Find a sponsor.
28: ** Note: if you are an ON CRT advocate, but not a SAC licensee, why not? Inquire about becoming one.
29: ** Copy the contributor when submitting case(s), and make sure s/he is involved in any ensuing discussion.
30: * Provide old SCCS delta comments when requested.
31: ** Check before providing actual old SCCS deltas, as old deltas may be encumbered.
32: * Assist the contributor with running nightly builds, if needed. Also, note that you will be doing the integration yourself, so you should apply the patch to a workspace of your own and run nightly on it.
33: * Assist the contributor in determining what test suites should be run, running them if needed (not all are available externally), etc. And again, since you will be doing the integration, test this as thoroughly as you would test a wad of your own.
34: * Note that the contributor can use the [[available self-service testing facility or the test farm>>Community Group testing.WebHome]] for testing.
35: 
36: = Getting ready to integrate
37: 
38: * Help determine ideal code reviewers.
39: * Per the CDDL block text, the contributor **may** add a comment
40: 
41: {{{
42: /* Portions Copyright YYYY Firstname Lastname */
43: }}}
44: 
45:  in the copyright section following the CDDL block at the top of the file. And regardless of whether such a comment is added or not, the Sun copyright should be updated appropriately.
46: * Ensure the contributor has a valid SCA on file (Sun internal listing). You can check [[ the request-sponsor table>>Main.request_sponsor]] to see if the SCA number is listed for the contributor. If not, check with the contributor to sure s/he filed the form and find out the number. There is also an internal table available that can be checked. If you don’t know where this table is located, check with oso-admin@opensolaris.org.
47: * Filing [[RTIs>>Community Group on.rti-nits]]
48: ** Select a good RTI advocate.
49: ** List the contributor in the Cc: field.
50: ** The //Third Party Source// question on the WebRTI form must be answered with the name of the contributor and the associated SCA#. With this information cited, no further diligence related to the contribution will be required. === Acknowledging the contributor There are two main ways the contributor can be credited at integration time. Either is acceptable, but at least one must be done. In both cases, the change-set comment should be the usual bug-ID and synopsis, plus any ARC cases.
51: *1. The contributed changeset(s) can be committed by the Contributor, instead of the Sponsor. This can be done using either {{code}}"login "{{/code}} or {{code}}"full name "{{/code}} format for hg user. If the Contributor does a commit and supplies the Mercurial bundle of the changeset(s), this will be correctly done. If the Contributor supplies a patch, and the Sponsor then applies the patch and commits the changes, they will need to use {{code}}hg commit -u {{/code}} or {{code}}hg recommit -u{{/code}} to set this correctly. If you have cause to merge and thus recommit, you should use the -u option to recommit to preserve the author: field. When the Sponsor pushes the changes to the gate, the From: field of the notification email will identify the Sponsor, not the Contributor. Both Sponsor and Contributor can be identified through either the bug report(s) or the RTI
52: *1. Or, this second approach can be used where the contributor is acknowledged with the changeset(s) comment. There are some minor variants on the format, in that there are two different beginning forms of such lines and two different end forms. The beginning forms are:
53: 
54: {{{
55: Contributed by
56: }}}
57: 
58:  and
59: 
60: {{{
61: Portions contributed by
62: }}}
63: 
64:  The end forms are:
65: 
66: {{{
67: Firstname Lastname.
68: }}}
69: 
70:  and
71: 
72: {{{
73: Firstname Lastname <something@example.com>.
74: }}}
75: 
76:  In case it is not obvious, the overall line should have one of the two beginning forms, then a space, then one of the two end forms.
77: 
78: = Integration
79: 
80: * Forward the push message to the contributor.
81: * Coordinate any ongoing issues with gate-keepers.
82: 
83: = When to Suspend a Request
84: 
85:  There has been some confusion about what do to when a contribution, or a contributor, goes ’stale’ for some reason. Following are some guidelines that explain the ’suspended’ list: what it is, how it works and when and how to use it.
86: 
87: * The ’suspended’ list is used for requests that are no longer being worked by contributors for any reason: they no longer have time, are no longer available, have retracted a request, etc.
88: * The ’suspended’ list is kept on the overall request-sponsor table because metrics are generated on a regular basis about the program (so requests can’t just disappear).
89: * Anything put on the ’suspended’ list is available for work by other Contributors or Sun engineers.
90: 
91: === Reasons to suspend a request and Actions to take
92: 
93: * Contributor is no longer available to work on the bug:
94: ** Sponsor sends email to request-sponsor saying the request should be moved to the ’suspended’ list and why.
95: ** Sponsor removes the oss-sponsor and oss-request keywords from the CR in bugster.
96: ** Sponsor removes the contributor’s email address from the Hook 6 field.
97: * Contributor is no longer responding to email from the Sponsor:
98: ** Sponsor sends a last email warning to the Contributor indicating that if a response is not received by a certain date, the request will be moved to the ’suspended’ list;
99: ** If agreement is reached, Sponsor sends email to request-sponsor saying the request should be moved to the ’suspended’ list and why;
100: ** If no response by the specified date, Sponsor sends email to request-sponsor saying the request should be moved to the ’suspended’ list and why.
101: ** Sponsor removes the oss-sponsor and oss-request keywords from the CR in bugster.
102: ** Sponsor removes the contributor’s email address from the Hook 6 field.
103: * Contributor does not want or is unable to fulfill his/her responsibilities with regard to building, testing, code review feedback, etc:
104: ** Sponsor sends email to the Contributor re-iterating responsibilities of a Contributor and explaining that if Contributor is unwilling/unable to fulfill his/her responsibilities, the Sponsor will not be able to continue as Sponsor and the request will be moved to the ’suspended’ list;
105: ** If the determination is to move the request to the ’suspended’ list, Sponsor sends email to request-sponsor saying the request should be moved to the ’suspended’ list and why.
106: ** Sponsor removes the oss-sponsor and oss-request keywords from the CR in bugster.
107: ** Sponsor removes the contributor’s email address from the Hook 6 field.
108: 
109: === When You Cannot Complete a Sponsor Commitment
110: 
111:  If you cannot finish sponsoring a request you picked up:
112: 
113: * It is your responsibility to try to find another sponsor.
114: * If you are unable to find another sponsor, you must communicate the situation to the contributor and use the mailing list to explain the change in state and to put the request back on the ’awaiting sponsor’ list.
115: 
116: = When to Reject a Request
117: 
118:  Offers of a code contribution can be rejected:
119: 
120: * For legitimate architectural reasons
121: ** Contribution violates existing architectural rules
122: ** Contribution works against the architecture
123: ** Contribution would interfere architecturally with planned future enhancements
124: * For legitimate business reasons
125: ** Contribution would interfere functionally with planned future enhancements.
126: ** (used in VERY limited cases only) The resource investment is not worth the return. Example: fix for one typo in a comment.  Note that requests can not be rejected because engineering teams don’t want to spend the time on them. Nor can requests for bugs marked ’oss-bite-size’ be rejected since engineering teams marked bugs with that keyword to tell new contributors where to start working on code.
OpenSolaris

Top Menu

Wiki code for Sponsor Tasks

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group on Pages
