Getting Started on Development
The Derby community welcomes anyone to participate in Derby's development.
Derby's web-site has a Get Involved page that explains how all development occurs in the open on the derby-dev at db.apache.org mailing list, Apache's open source development model and some mechanics of how to contribute code changes.
This wiki contains a number of pages aimed at getting people started working on Derby, since these are wiki pages feel free to improve them based upon your experience on joining the Derby community.
A first action to consider is submitting an ICLA to the ASF, see the contributor checklist for how to and other items to be aware of.
There are more ways to get involved in Derby than submitting code, the information for new developers pages lists many and includes some of the mechanics, such as links to specification & getting the code.
Confused or intrigued as to how Derby implements something, then see if it has been written up by anyone at the how it works page, if it hasn't please add to wiki any information you discover. It could be a simple as pointers to the best source file to look at for an issue, or a complete write up of the functionality.
Eager to start coding and submit a patch to Derby, take a moment to read this advice . Heed the summary, communicate, communicate, communicate, an open source project is all about open communication, bring those half-baked, early, partially thought out, incomplete or crazy ideas to the list, others will help bake (complete) them.
Ready to code? Just one more thing, take a quick look at the complete process of how a change is made in Derby. This includes using JIRA, Derby's bug & issue tracking system, to help track the issue and the place to attach the patch file to.
Worked through all of this, made some changes, and you've submitted a patch, congratulations! While waiting for reviews, see what patches others have contributed, review one or two of them. This good karma will come back to you when someone spends the time to review your patch.
Everyone ignoring your patch? Don't take it personally, people are just busy. Read the advice again for ways to sell your patch and see if you missed any step that might stop anyone from spending time on it.
All that is covered in the getting started section continue to applies once your first patch is committed and as you hopefully become a committer. Continue to follow the patch advice, practice incremental development, remember the patch process.
Continue to watch the status of other patches and try to review and/or commit at least one other patch per week. If people submit small patches (due to incremental development) and we have all developers reviewing a patch or two a week then we could achieve very fast turn-around on patches.
Looking for items to work on? Here are some places to start, looking through Jira is a great way to see the outstanding bugs and requested features & improvements.
- DerbyTenSevenOneRelease: Plan for next feature release.
- TenThreePostMortem: Lessons from 10.3 which may help us make the next release smoother.
- Derby Jira Isssues
- CodingProjects: here are coding projects that newcomers, interns, and Google Summer of Code participants can sign up for
- DerbyDevActivities: Information about features, projects or other types of contributions to the Derby project.
- DerbyToDos: a list of possible feature requests from various community members, formerly on the website
- DerbyProposals: a list of proposals that are being discussed or reviewed on the Wiki site
- GoogleSummerOfCodeProjects: Information about approved Google Summer of code projects
Having trouble developing code, some information that might help.
- PlatformTestsDerby: Derby is tested on a variety of platform/jdk combinations. Please visit this page for the complete list.
- DerbyTesting: information about Derby testing
- DerbyDebuggingTips: Tips for developers debugging code issues in Derby
- MetadataUpgrade: Description of the mechanisms for handling metadata changes on upgrade.
- AvoidNonPortableMethods: List of encoding unsafe methods in java. Please avoid using them.
- LocalizingDerbyMessages: An overview of how Derby messages are localized to languages other than English.
- NewJdkChecklist: A list of changes that should be made when adding a new JDK version or vendor.
How Derby Works
Information about how Derby works.
Information about how to do various Derby development tasks, such as create a snapshot or a release.
Some obsolete or outdated pages that may still be of value.