On Sat, May 10, 2008 at 10:00 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > I'm trying to gather some additions to the contributors page of the shindig > site. I'd like to address a few issues that have come up with patches from > non-committers. Here's what I have so far: > > - Patches should be attached to the JIRA issue tracker. Patches sent via > email will likely just be forgotten. > > - Patch must conform to style guides as specified by > http://cwiki.apache.org/confluence/display/SHINDIGxSITE/Java+Style, > http://cwiki.apache.org/confluence/display/SHINDIGxSITE/Javascript+Style, > http://cwiki.apache.org/confluence/display/SHINDIGxSITE/PHP+Style, etc. > Minor deviations are acceptable, at the discretion of the committer (who > must resolve the deviations herself). If a commiter judges that a patch is > too far off of the style guide, she may reject it. > > - Any new code paths should include corresponding unit tests. New classes > with any non-trivial public methods (i.e. anything that actually does work) > must provide a matching test case. No patch will be accepted without > corresponding test coverage. There is currently an exception to this for > javascript, pending a solid solution for running jsunit or similar tests.
we should remove this exception. we do have a perfectly fine set of running jsunit tests. all jsunit tests should be called "<classname>test.js" and placed in the same directory as the javascript file that it is testing. you may argue that the way we run the jsunit tests in sub par - but it doesn't matter. they are indeed running and should be added to when new functionality is introduced. > > > - All existing tests must pass after the patch is applied. If any tests > fail, you must also patch the code that is now failing (either by updating > the test, or modifying the code path as appropriate). If you need to make > any major changes to other code that is not directly related to your change, > please include notes to that effect in the JIRA ticket. If you're unsure of > what to do, email shindig-dev@, or the component lead for the code you're > patching. > > - Patches should be as small and focused as possible. The smaller they are, > the easier it is to avoid conflicts and for committers to review them. > > - Patch should be against a relatively recent version of Shindig so as to > avoid merge conflicts; ideally, the patch should be against HEAD at the time > of creation. Committers will do our best to resolve any minor merge issues > that occur between patch submission and commit time, though we may not be > able to do this in the event of major conflicts. > > - Any changes in javascript with implications for server side functionality > must be approved by all server-side language implementors. Committers are > responsible for ensuring that appropriate language components are assigned > to the issue so that they are properly tracked. > > - Committers must reference the issue when committing the patch. The ideal > format is something like "Applying SHINDIG-XXX, submitted by <name of user > that submitted it". This will allow automatic status updates for the > associated JIRA tickets.
