Approval status - the Approval field in a JIRA issue.
Clojure/core member - Contributor who has the approval to vet tickets in JIRA.
Contributor - Person who has signed the Clojure Contributor Agreement.
Defect - A bug in the code base.
Enhancement - A new feature in the code base.
Issue - A ticket in JIRA.
Screener - Contributor who is approved to screen tickets.
Task - Work that must be done outside the code base.
Submitting patches to Clojure and Clojure Contrib
If you've got a bug fix or feature you'd like to submit to the Clojure, Clojure Contrib or Clojure CLR projects, first - thanks! Before you get too deep into the code, please make sure you review the contributing guidelines -- it's important to submit a Contributor's agreement as detailed on that page. Once it's been received (your name will appear on the contributor's list on that page), you can join the clojure-dev Google group. Anyone with a CA can become a member of our Confluence and JIRA. Just sign up (please use a recognizable name), then ask on the clojure-dev group and I'll bump up your membership level to make edits.
So You Have an Idea...
In order to make sure you are not duplicating effort, fixing a feature, or planning an unwelcome change, please coordinate with the community, by first examining existing issues (clojure's , contrib's ), and discussing your patch plan on the clojure-dev Google group.
Track it in JIRA
If you've got the go-ahead and there isn't already a ticket for your issue/feature, please create one. Make sure the ticket includes a link to the discussion in the Google Group or IRC, so someone reviewing your ticket can quickly get up to speed. Assign yourself to the ticket so people know you are working on it. Please don't assign things to others without their consent.
Prioritization and Milestones (Committers)
Committers use the prioritization and milestone fields. If you are a the committer for a lib, please don't change the priority or the default milestone assignment.
Once you're ready to craft your code, the first thing you'll need is a clone of the Clojure or Contrib repository. The examples below are for the contrib project -- for submissions to Clojure itself, remove "-contrib" from the examples:
$ git clone git://github.com/clojure/clojure-contrib.git
$ cd clojure-contrib
Next, create a new branch for yourself:
$ git checkout -b fixbug42
Switched to a new branch "fixbug42"
Now you're ready to get hacking. Make sure relevant doc strings are up to date and that all existing regression tests still pass e.g. for clojure core run:
$ ant test
If you want to add new tests, that would be great too. Once you've finished making your changes you need to commit them.
$ git commit -a -m "fixed annoying bug, refs #42"
Created commit 8f7c712: fixed annoying bug, refs #42
1 files changed, 0 insertions , 1 deletions(-)
Now that you've made your changes it's time to get them into a patch. You need to update the repo and fix any conflicts you had.
$ git checkout master
Switched to branch "master"
$ git pull
$ git checkout fixbug42
Switched to branch "fixbug42"
$ git rebase master
Once you've fixed any conflicts, you're ready to create a patch:
$ git format-patch master --stdout > your-patch-file.diff
Now you can attach that patch file to the JIRA ticket and please add the 'patch' tag. Please mark the ticket 'ready to test' by checking that option under Choose an action...
Help the core team by vetting tickets, getting them into a state where they can be tested, and screened. Steps are:
- Take ownership of a ticket that is status "New" and not currently owned by someone else.
- Verify that the issue is reproducible, adding a test case if necessary.
- Set the approval to "Vetted."
- If the ticket has (or you write) a patch that applies, test it. If it seems to work, set the status to "Test."
- If there isn't a unit test and you feel like writing one, please do so.
- Release ownership of the ticket.
Screening Tickets (Screeners)
Periodically, screeners will review tickets whose approval is marked 'Test'.
- Take ownership of the ticket so that others know you are working on it.
- Make sure to work on defects first. Enhancements are much lower priority, and should typically begin with a design conversation under Clojure Design
To apply someone's changes you need to first create a branch:
- make sure you have a clean local checkout
- no need to check on multiple OSes (unless the ticket is specific to this)
- Please note the -s above, it is important, as it indicates that you are the one accepting this patch.
Once you have a working copy, you should take note of the following kinds of things:
- Review the code in a diff tool to make sure that nothing extraneous snuck in
- Make sure compile and tests pass
- Test the functionality from the REPL
- Does the patch accomplish the goals stated in the ticket (and any accompanying discuss in Confluence/email/IRC)
- If questions were raised in the discussion, are they answered in the ticket?
- Are you happy with the tests, can you follow what they're testing, is there anything missing?
- Are the tests excessive (introducing dependency on implementation detail)?
- Does the documentation still seem right to you?
- Is the implementation idiomatic (if not, explain why, link to examples...)
- Is the patch performance-sensitive? If so, is the approach appropriate?
After review, if you are happy, you should
- Set the approval of the ticket to screened
- If you own the lib in question, you can set approval to accepted, and deploy the change
If you are not happy
- Add a comment to the ticket, explaining what the issues are
- Set the approval of the ticket to 'Incomplete'
- Set the waiting-on of the ticket to the person who created the patch
If you aren't sure
- Get a second opinion, and note this in the comments
- Set the waiting-on to Rich or Stu, if appropriate
Closing Tickets (Committers)
If you are a committer on a lib, you can screen tickets and close them all in one step. Alternately, you can review tickets screened by others, and then either close them or bounce them back (as in the Screening step above).
While you have the ability to just push your stuff into the repo, please use the tickets systems too. It makes a fine todo system, helps organize bigger milestones, lets others hop in and help or provide input, and provides a place to hang discussions about your changes.
If you have questions or concerns, please ask a question on the clojure-dev Google group.
Clojure is Stricter than Contrib
The expectation of stability and performance is much higher for Clojure than for Clojure Contrib. Rich personally reviews every change to Clojure. To save Rich's time, other committers may do the work in git. When this happens, you can see Rich's review process in JIRA, both in the comments and in tickets being moved from 'Screened' to 'Ok' by Rich.
If you want to share work-in-progress on some feature you are not yet ready to propose with a ticket, you can post a patch made as above, or a pointer to your repo, to the clojure-dev group.
Thanks for contributing to Clojure!
Screening Process Described
An issue is created in JIRA that expresses some unit of work that is desired. This could be a defect, an enhancement or a task.
Clojure/core team vets the ticket, and changes the approval status to Vetted, indicating this is a problem that we want to solve.
Next a contributor writes a patch to address a defect or enhancement, and attaches the patch to the issue. The contributor should also indicate what kind of patch this is in the ticket. The approval status is then set to test, indicating it is dev complete.
A screener will review the issue and marks the approval status as Screened. This will set the issue to waiting on Rich.
Rich comes along and blesses the issue by setting it the approval status to OK, meaning the code is ready to build & push to git.
When the code has been pushed, the issue is marked as Resolved.
At any point along this path a Screener can mark the issue as Declined, meaning it is not something we are going to address.
Also, at any point a Clojure/core member can mark the approval status as Incomplete. This indicates more information is needed to continue work on the issue. There is also an optional Waiting On? field that should be set to indicate who is expected to provide the additional information
Some useful filters
Incomplete Issues: http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10011
See Also http://clojure.org/patches