Contributing to BDE¶
BDE welcomes contributions from other developers! We have some experience integrating work from other teams into BDE libraries and hope to incorporate more contributions in the future.
Where is the BDE Source Code?¶
Repository |
Description |
|---|---|
Main repository |
|
BDE Cmake-based build system and tools |
Basic Requirements for a Contribution¶
For any change incorporated into BDE we require:
The change must make sense within the BDE framework
The change must meet the BDE C++ Coding Standards
The change must be thoroughly documented (where appropriate). See the coding standards.
The change must be thoroughly tested (where appropriate). See below.
The BDE coding standards contain additional information about documentation and testing.
All contributions must conform to the BDE C++ Coding Standards for design, coding, documentation, and testing - they are rigorous and they are many. See BDE C++ Coding Standards to start; other requirements are less well documented and will have to be discussed. The BDE team will gladly help you learn the BDE methodology (whether or not you are making a contribution); however, ultimately, you will be doing the work.
BDE Development Workflow¶
BDE follows the standard github workflow: Features are developed from a fork of an existing repository and, when completed, the developer issues a request to pull the new code into the official repository.
Testing¶
There is not a canonical source of information on testing. A good example of the C++ rendering for a BDE test-driver is: bdlb_tokenizer.t.cpp
How Do I Build and Test a Fix?¶
How Do I Contribute a Simple Bug Fix or Documentation Change?¶
Simple! Create an enhancement request describing the issue, and add a link to the pull request. See the Road Map below, starting at development.
How Do I Contribute a New Feature, Component, or Package?¶
For larger changes, we recommend first reviewing the ideas with us before spending too much time to implementing them. We want your contribution to fit within the BDE framework. For example, it must be finely factored and have the potential for wide reuse. Let’s resolve such questions before you have invested much development effort. See the Road Map below.
Road Map¶
Proposal¶
Create an issue proposing the type or feature you want to add. Note there that you intend to contribute the changes yourself.
Discuss, in the ticket, basic issues surrounding the changes:
the appropriateness of the feature for BDE
the library/package/component in which the changes would be located
high-level design and component factoring
When we reach an agreement on the proposal, the next stage is the development of your ideas in your fork of BDE.
For larger changes, a member of the BDE team may advise you during the development of your code.
Development¶
First, you will need fork the appropriate BDE repository for your contribution. The repository choice is generally determined during the proposal stage.
TBD: At some point in your development, you will integrate your code into BDE’s nightly build branch. Code in that branch is compiled and tested (i.e., test drivers are run) extensively. The nightly builds cover many different combinations of platforms, compilers, and build options. Breakages are reported daily and must be fixed as soon as possible.
Before integrating your code into the nightly build branch, you should personally check that it compiles and tests successfully at least on all of the Unix-platforms widely used at Bloomberg (i.e., Linux, Sun, AIX), and, if possible, on Windows, too.
At this point, developers submit their code for review.
Review¶
Code changes will be reviewed ether on github or in Phabricator.
Integrate the feedback from each cycle of review. Multiple review cycles are typical for BDE code before it is released.
Release¶
You may have to contribute a feature description and tutorial material for BDE release NLRTs and Release Notes.