bookkeeper-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [bookkeeper] branch master updated: ISSUE #434: Move the content from wikis to website
Date Tue, 15 Aug 2017 00:22:14 GMT
This is an automated email from the ASF dual-hosted git repository.

sijie pushed a commit to branch master
in repository

The following commit(s) were added to refs/heads/master by this push:
     new affc7b0  ISSUE #434: Move the content from wikis to website
affc7b0 is described below

commit affc7b073ff229345a5569025f4b65983358a352
Author: Sijie Guo <>
AuthorDate: Mon Aug 14 17:22:07 2017 -0700

    ISSUE #434: Move the content from wikis to website
    Descriptions of the changes in this PR:
    copied bunch of links from wiki pages and re-organized the links under `community`.
    - first section: mailing list, issue tracking, release schedule and community meetings.
    - second section: a few guides on how to contribute, how to report issue and how to release
    - last section: resources (e.g. presentations, proposals)
    Author: Sijie Guo <>
    Reviewers: Matteo Merli <>
    This closes #448 from sijie/sijie/move_contents, closes #434
 site/_includes/navbar.html      |  12 +-
 site/community/  |  84 +++++++++++++
 site/community/  | 260 +++++++++++++++++++++++++++++++++++++++-
 site/community/  |  93 ++++++++++++++
 site/community/       |  19 +++
 site/community/ |  31 +++++
 site/community/      |  33 +++++
 7 files changed, 528 insertions(+), 4 deletions(-)

diff --git a/site/_includes/navbar.html b/site/_includes/navbar.html
index bd8f408..5348da2 100644
--- a/site/_includes/navbar.html
+++ b/site/_includes/navbar.html
@@ -62,8 +62,16 @@
         <div class="navbar-dropdown is-boxed">
           <a class="navbar-item" href="{{ site.baseurl }}community/mailing-lists">Mailing
           <a class="navbar-item" href="{{ site.baseurl }}community/slack">Slack</a>
-          <a class="navbar-item" href="{{ site.baseurl }}community/contributing">Contributing</a>
-          <a class="navbar-item" href="">JIRA
Issue Tracker</a>
+          <a class="navbar-item" href="">Github
+          <a class="navbar-item" href="{{ site.baseurl }}community/releases">Release
+          <a class="navbar-item" href="{{ site.baseurl }}community/meeting">Community
+          <hr class="dropdown-divider">
+          <a class="navbar-item" href="{{ site.baseurl }}community/contributing">Contribution
+          <a class="navbar-item" href="{{ site.baseurl }}community/coding_guide">Coding
+          <a class="navbar-item" href="{{ site.baseurl }}community/issue-report">Issue
Report Guide</a>
+          <hr class="dropdown-divider">
+          <a class="navbar-item" href="{{ site.baseurl }}community/presentations">Presentations</a>
+          <a class="navbar-item" href="">BookKeeper
diff --git a/site/community/ b/site/community/
new file mode 100644
index 0000000..3033fa0
--- /dev/null
+++ b/site/community/
@@ -0,0 +1,84 @@
+title: Coding Guide
+These guidelines are meant to encourage consistency and best practices among people working
on _Apache BookKeeper_ code base.
+They should be observed unless there is compelling reason to ignore them. We are also using
checkstyle to enforce coding style.
+Please refer to our [checkstyle rules](
for all enforced checkstyle rules.
+### Java
+Apache BookKeeper code should follow the [Sun Java Coding Convention](,
with the following additions.
+* Lines can be up to 120 characters long.
+* Indentation should be **4 spaces**. Tabs should never be used.
+* Use curly braces even for single-line ifs and elses.
+* No @author tags in any javadoc
+* **TODO**s should be associated to at least one issue. E.g. `// TODO: make this parameter
configurable (`
+### Dependencies
+Apache BookKeeper uses following libraries a lot:
+* [Guava]( as a fundamental core library
+* [Netty]( for network communications and memory buffer management.
+Please use these libraries whenever possible rather than introducing more dependencies. 
+#### Future
+We prefer Java-8 Future over Guava's Listenable Future. Please use Java-8 Future whenever
+#### Memory
+We prefer using netty _ByteBuf_ over java nio _ByteBuffer_ for internal usage. As we are
using Netty Buffer for memory management.
+### Logging
+* Logging should be taken seriously. Please take the time to access the logs when making
a change to ensure that the important things are getting logged and there is no junk there.
+* Logging statements should be complete sentences with proper capitalization that are written
to be read by a person not necessarily familiar with the source code.
+* All loggings should be done with **SLF4j**, never _System.out_ or _System.err_.
+#### Logging levels
+- _INFO_ is the level you should assume the software will be run in. INFo messages are things
which are not bad but which the user will definitely want to know about every time they occur.
+- _TRACE_ and _DEBUG_ are both things you turn on when something is wrong and you want to
figure out what is going on. _DEBUG_ should not be so fine grained that it will seriously
affect performance of the program. _TRACE_ can be anything. Both _DEBUG_ and _TRACE_ statements
should be considered to be wrapped in an _if (logger.isDebugEnabled)_ or _if (logger.isTraceEnabled)_
check to avoid performance degradation.
+- _WARN_ and _ERROR_ indicate something that is **BAD**. Use _WARN_ if you aren't totally
sure it is bad, and _ERROR_ if you are.
+Please log the _stack traces_ at **ERROR** level, but never at **INFO** level or below. They
can be logged at **WARN** level when they are interesting for debugging.
+### Monitoring
+* Apache BookKeeper uses a pluggable [StatsProvider](
on exporting metrics
+* Any new features should come with appropriate metrics for monitoring the feature is working
+* Those metrics should be taken seriously and only export useful metrics that would be used
on production on monitoring/alerting healthy of the system, or troubleshooting problems.
+### Unit Tests
+* New changes should come with unit tests that verify the functionality being added
+* Unit tests should test the least amount of code possible. Don't start the whole server
unless there is no other way to test a single class or small group of classes in isolation.
+* Tests should not depend on any external resources. They need to setup and teardown their
own stuff.
+* It is okay to use the filesystem and network in tests since that's our business but you
need to clean up them after yourself.
+* _Do not_ use sleep or other timing assumptions in tests. It is always, always, wrong and
will fail intermittently on any test server with other things going on that causes delays.
+* We are strongly recommending adding a _timeout_ value to all our test cases, to prevent
a build from completing indefinitely.
+### Configuration
+* Names should be thought through from the point of view of the person using the config.
+* The default values should be thought as best value for people who runs the program without
tuning parameters.
+* All configuration settings should be added to [default configuration file](
and [documented](
+### Concurrency
+Apache BookKeeper is a low latency system. So it is implemented as a purely asynchronous
service. This is accomplished as follows:
+* All public classes should be **thread-safe**.
+* We prefer using [OrderedSafeExecutor](
for executing any asynchronous actions. The mutations to same instance should be submitted
to same thread to execute.
+* If synchronization and locking is required, they should be in a fine granularity way.
+* All threads should have proper meaningful name.
+* If a class is not threadsafe, it should be annotated [@NotThreadSafe](
The instances that use this class is responsible for its synchronization.
+### Backwards Compatibility
+* Wire protocol should support backwards compatibility to enable no-downtime upgrades. This
means the servers **MUST** be able to support requests from both old and new clients simultaneously.
+* Metadata formats and data formats should support backwards compatibility.
diff --git a/site/community/ b/site/community/
index 70d29e8..e711ff3 100644
--- a/site/community/
+++ b/site/community/
@@ -2,6 +2,262 @@
 title: Contributing to Apache BookKeeper
-The Git repository for Apache BookKeeper is on GitHub at [{{ site.github_repo }}]({{ site.github_repo
}}). This is the primary repository, and all commits must be pushed to it.
+* TOC
-A full guide to contributing the BookKeeper can be found in [this Confluence page](
\ No newline at end of file
+The Apache BookKeeper community welcomes contributions from anyone with a passion for distributed
systems! BookKeeper has many different opportunities for contributions --
+write new examples/tutorials, add new user-facing libraries, work on the core storage components,
integrate with different metadata stores (ZooKeeper, Etcd etc), or
+participate on the documentation effort.
+We use a review-then-commit workflow in BookKeeper for all contributions.
+**For larger contributions or those that affect multiple components:**
+1. **Engage**: We encourage you to work with the BookKeeper community on the [Github Issues](
and [developer’s mailing list](../mailing-lists) to identify good areas for contribution.
+1. **Design:** More complicated contributions will likely benefit from some early discussion
in order to scope and design them well.
+**For all contributions:**
+1. **Code:** The best part ;-)
+1. **Review:** Submit a pull request with your contribution to our [GitHub Repo](
Work with a committer to review and iterate on the code, if needed.
+1. **Commit:** A BookKeeper committer merges the pull request into our [GitHub Repo](
+We look forward to working with you!
+## Engage
+### Mailing list(s)
+We discuss design and implementation issues on the [](
mailing list, which is archived [here](
Join by emailing [``](
+If interested, you can also join the other [mailing lists](../mailing-lists).
+### Github Issues
+We are moving to use [Github Issues]( as an issue
tracking and project management tool, as well as a way to communicate among a very diverse
and distributed set of contributors. To be able to gather feedback, avoid frustration, and
avoid duplicated efforts all BookKeeper-related work should be tracked there.
+If you do not already have an Github account, sign up [here](
+If a quick [search]( doesn’t
turn up an existing Github issue for the work you want to contribute, create it. Please discuss
your idea with a committer in Github or, alternatively, on the developer mailing list.
+If there’s an existing Github issue for your intended contribution, please comment about
your intended work. Once the work is understood, a committer will assign the issue to you.
If an issue is currently assigned, please check with the current assignee before reassigning.
+For moderate or large contributions, you should not start coding or writing a design document
unless there is a corresponding Github issue assigned to you for that work. Simple changes,
like fixing typos, do not require an associated issue.
+### Online discussions
+We are using [Apache BookKeeper Slack channel]( for online
discussions. You can self-invite yourself by accessing [this link](
+Slack channels are great for quick questions or discussions on specialized topics. Remember
that we strongly encourage communication via the mailing lists, and we prefer to discuss more
complex subjects by email. Developers should be careful to move or duplicate all the official
or useful discussions to the issue tracking system and/or the dev mailing list.
+## Design
+To avoid potential frustration during the code review cycle, we encourage you to clearly
scope and design non-trivial contributions with the BookKeeper community before you start
+We are using [BookKeeper Proposals](
for managing major changes to BookKeeper.
+## Code
+To contribute code to Apache BookKeeper, you’ll have to do a few administrative steps once,
and then follow the [Coding Guide](../coding_guide).
+### One-time Setup
+#### [Optionally] Submit Contributor License Agreement
+Apache Software Foundation (ASF) desires that all contributors of ideas, code, or documentation
to the Apache projects complete, sign, and submit an [Individual Contributor License Agreement](
(ICLA). The purpose of this agreement is to clearly define the terms under which intellectual
property has been contributed to the ASF and thereby allow us to defend the project should
there be a legal dispute regarding the software at some future time.
+We require you to have an ICLA on file with the Apache Secretary for larger contributions
only. For smaller ones, however, we rely on [clause five](
of the Apache License, Version 2.0, describing licensing of intentionally submitted contributions
and do not require an ICLA in that case.
+#### Obtain a GitHub account
+We use GitHub’s pull request functionality to review proposed code changes.
+If you do not already have a personal GitHub account, sign up [here](
+#### Fork the repository on GitHub
+Go to the [BookKeeper GitHub Repo]( and fork the repository
to your own private account. This will be your private workspace for staging changes.
+#### Clone the repository locally
+You are now ready to create the development environment on your local machine. Feel free
to repeat these steps on all machines that you want to use for development.
+We assume you are using SSH-based authentication with GitHub. If necessary, exchange SSH
keys with GitHub by following [their instructions](
+Clone your personal BookKeeper’s GitHub fork.
+    $ git clone<Github_user>/bookkeeper.git
+    $ cd bookkeeper
+Add Apache Repo as additional Git remotes, where you can sync the changes (for committers,
you need these two remotes for pushing changes).
+	$ git remote add apache
+	$ git remote add apache-github
+You are now ready to start developing!
+#### [Optional] IDE Setup
+Depending on your preferred development environment, you may need to prepare it to develop
BookKeeper code.
+##### IntelliJ
+###### Checkstyle
+IntelliJ supports checkstyle within the IDE using the Checkstyle-IDEA plugin.
+1. Install the "Checkstyle-IDEA" plugin from the IntelliJ plugin repository.
+1. Configure the plugin by going to Settings -> Other Settings -> Checkstyle.
+1. Set the "Scan Scope" to "Only Java sources (including tests)".
+1. In the "Configuration File" pane, add a new configuration using the plus icon:
+    1. Set the "Description" to "BookKeeper".
+    1. Select "Use a local Checkstyle file", and point it to
+      "buildtools/src/main/resources/bookkeeper/checkstyle.xml" within
+      your repository.
+    1. Check the box for "Store relative to project location", and click
+      "Next".
+    1. Configure the "checkstyle.suppressions.file" property value to
+      "suppressions.xml", and click "Next", then "Finish".
+1. Select "BookKeeper" as the only active configuration file, and click "Apply" and
+   "OK".
+1. Checkstyle will now give warnings in the editor for any Checkstyle
+   violations.
+You can also scan an entire module by opening the Checkstyle tools window and
+clicking the "Check Module" button. The scan should report no errors.
+Note: Selecting "Check Project" may report some errors from the archetype
+modules as they are not configured for Checkstyle validation.
+##### Eclipse
+Use a recent Eclipse version that includes m2e. Currently we recommend Eclipse Neon.
+Start Eclipse with a fresh workspace in a separate directory from your checkout.
+###### Initial setup
+1. Import the bookkeeper projects
+	File
+	-> Import...
+	-> Existing Maven Projects
+	-> Browse to the directory you cloned into and select "bookkeeper"
+	-> make sure all bookkeeper projects are selected
+	-> Finalize
+You now should have all the bookkeeper projects imported into eclipse and should see no compile
+###### Checkstyle
+Eclipse supports checkstyle within the IDE using the Checkstyle plugin.
+1. Install the [Checkstyle plugin](
+1. Configure Checkstyle plugin by going to Preferences - Checkstyle.
+    1. Click "New...".
+    1. Select "External Configuration File" for type.
+    1. Click "Browse..." and select "buildtools/src/main/resources/bookkeeper/checkstyle.xml".
+    1. Enter "BookKeeper Checks" under "Name:".
+    1. Click "OK", then "OK".
+### Create a branch in your fork
+You’ll work on your contribution in a branch in your own (forked) repository. Create a
local branch, initialized with the state of the branch you expect your changes to be merged
into. Keep in mind that we use several branches, including `master`, feature-specific, and
release-specific branches. If you are unsure, initialize with the state of the `master` branch.
+	$ git fetch apache
+	$ git checkout -b <my-branch> apache/master
+At this point, you can start making and committing changes to this branch in a standard way.
+### Syncing and pushing your branch
+Periodically while you work, and certainly before submitting a pull request, you should update
your branch with the most recent changes to the target branch.
+    $ git pull --rebase
+Remember to always use `--rebase` parameter to avoid extraneous merge commits.
+Then you can push your local, committed changes to your (forked) repository on GitHub. Since
rebase may change that branch's history, you may need to force push. You'll run:
+	$ git push <GitHub_user> <my-branch> --force
+### Testing
+All code should have appropriate unit testing coverage. New code should have new tests in
the same contribution. Bug fixes should include a regression test to prevent the issue from
+## Review
+Once the initial code is complete and the tests pass, it’s time to start the code review
process. We review and discuss all code, no matter who authors it. It’s a great way to build
community, since you can learn from other developers, and they become familiar with your contribution.
It also builds a strong project by encouraging a high quality bar and keeping code consistent
throughout the project.
+### Create a pull request
+Organize your commits to make a committer’s job easier when reviewing. Committers normally
prefer multiple small pull requests, instead of a single large pull request. Within a pull
request, a relatively small number of commits that break the problem into logical steps is
preferred. For most pull requests, you'll squash your changes down to 1 commit. You can use
the following command to re-order, squash, edit, or change description of individual commits.
+    $ git rebase -i apache/master
+You'll then push to your branch on GitHub. Note: when updating your commit after pull request
feedback and use squash to get back to one commit, you will need to do a force submit to the
branch on your repo.
+Navigate to the [BookKeeper GitHub Repo]( to create
a pull request. The title of the pull request should be strictly in the following format:
+	Issue <Github-issue-#> <Title of the pull request>
+Please include a descriptive pull request message to help make the comitter’s job easier
when reviewing. It’s fine to refer to existing design docs or the contents of the associated
JIRA as appropriate.
+If you know a good committer to review your pull request, please make a comment like the
following. If not, don’t worry -- a committer will pick it up.
+	Hi @<GitHub-committer-username>, can you please take a look?
+When choosing a committer to review, think about who is the expert on the relevant code,
who the stakeholders are for this change, and who else would benefit from becoming familiar
with the code. If you’d appreciate comments from additional folks but already have a main
committer, you can explicitly cc them using `@<GitHub-committer-username>`.
+### Code Review and Revision
+During the code review process, don’t rebase your branch or otherwise modify published
commits, since this can remove existing comment history and be confusing to the committer
when reviewing. When you make a revision, always push it in a new commit.
+Our GitHub repo automatically provides pre-commit testing coverage using Jenkins. Please
make sure those tests pass; the contribution cannot be merged otherwise.
+### LGTM
+Once the committer is happy with the change, they’ll approve the pull request with an LGTM
(“*looks good to me!*”) or a `+1`. At this point, the committer will take over, possibly
make some additional touch ups, and merge your changes into the codebase.
+In the case the author is also a committer, either can merge the pull request. Just be sure
to communicate clearly whose responsibility it is in this particular case.
+Thank you for your contribution to BookKeeper!
+### Deleting your branch
+Once the pull request is merged into the BookKeeper repository, you can safely delete the
branch locally and purge it from your forked repository.
+From another local branch, run:
+	$ git fetch origin
+	$ git branch -d <my-branch>
+	$ git push origin --delete <my-branch>
+## Commit (committers only)
+Once the code has been peer reviewed by a committer, the next step is for the committer to
merge it into the Github repo.
+Pull requests should not be merged before the review has approved from another committer.
Exceptions to this rule may be made rarely, on a case-by-case basis only, in the committer’s
discretion for situations such as build breakages.
+Committers should never commit anything without going through a pull request, since that
would bypass test coverage and potentially cause the build to fail due to checkstyle, etc.
In addition, pull requests ensure that changes are communicated properly and potential flaws
or improvements can be spotted. **Always go through the pull request, even if you won’t
wait for the code review.** Even then, comments can be provided in the pull requests after
it has been merged to work on follow-ups.
+Committing is managed by a python script [](
Just follow the instructions promoted by the
+script and types the information needed by the script.
+### Contributor License Agreement
+If you are merging a larger contribution, please make sure that the contributor has an ICLA
on file with the Apache Secretary. You can view the list of committers [here](,
as well as [ICLA-signers who aren’t yet committers](
+For smaller contributions, however, this is not required. In this case, we rely on [clause
five]( of the Apache License, Version
2.0, describing licensing of intentionally submitted contributions.
+### Tests
+Before merging, please make sure that Jenkins tests pass, as visible in the GitHub pull request.
Do not merge the pull request otherwise.
+### Finishing touches
+At some point in the review process, you should take the pull request over and complete any
outstanding work that is either minor, stylistic, or otherwise outside the expertise of the
contributor. The [merge script](
provides instructions for committers to address such minor conflicts.
+## Documentation
+### Website
+The BookKeeper website is in the same [BookKeeper Github Repo](
The source files are hosted under `site` directory in `master` branch,
+the static content is generated by CI job and merged into the `asf-site` branch.
+Follow the [README]( for making contributions
to the website.
diff --git a/site/community/ b/site/community/
new file mode 100644
index 0000000..21ff369
--- /dev/null
+++ b/site/community/
@@ -0,0 +1,93 @@
+title: Issue Report
+To report an issue, you will need to create a **[New Issue](**.
+Be aware that resolving your issue may require **your participation**. Please be willing
and prepared to aid the developers in finding the actual cause of the issue so that they can
develop a comprehensive solution.
+## Before creating a new Issue:
+-  Search for the issue you want to report, it may already have been reported.
+-  If you find a similar issue, add any new information you might have as a comment on the
existing issue. If it's different enough, you might decide it needs to be reported in a new
+-  If an issue you recently reported was closed, and you don't agree with the reasoning for
it being closed, you will need to reopen it to let us re-investigate the issue.
+-  Do not reopen the tickets that are in a previously completed milestone. Instead, open
a new issue.
+## Creating a Issue:
+Here is an very useful artical [How to report bugs effectively](
+### Provide useful and required information
+#### If it is a question
+-  Please check our [documentation]( first. 
+-  If you could not find an answer there, please consider asking your question in our community
mailing list at [](, or reach out
us on our [Slack channel](../slack).  It would benefit other members of our community.
+#### If it is a **FEATURE REQUEST**
+-  Please describe the feature you are requesting.
+-  Indicate the importance of this issue to you (_blocker_, _must-have_, _should-have_, _nice-to-have_).
Are you currently using any workarounds to address this issue?
+-  Provide any additional detail on your proposed use case for this feature.
+-  If it is a [BookKeeper Proposal](,
please label this issue as `BP`.
+#### If it is a **BUG REPORT**
+Please describe the issue you observed:
+- What did you do?
+- What did you expect to see?
+- What did you see instead?
+### Use Labels
+Issue labels help to find issue reports and recognize the status of where an issue is in
the lifecycle. An issue typically has the following 2 types of labels:
+1. **type** identifying its type.
+1. **area** identifying the areas it belongs to.
+#### Type
+- **type/bug**: The issue describes a product defect.
+- **type/feature**: The issue describes a new feature, which requires extensive design and
+- **type/question**: The issue contains a user or contributor question requiring a response.
+- **type/task**: The issue describes a new task, which requires extensive design and testing.
+#### Area
+- **area/bookie**: Code changes related to bookie storage.
+- **area/build**: Code changes related to project build.
+- **area/client**: Code changes related to clients.
+- **area/docker**: Code changes related to docker builds.
+- **area/documentation**: Code changes related to documentation (including website changes).
+- **area/metadata**: Code changes related to metadata management.
+- **area/protocol**: Protocol changes.
+- **area/release**: Release related tasks.
+- **area/security**: Security related changes.
+- **area/tests**: Tests related changes.
+#### Priority
+At most of the time, it is hard to find a right `priority` for issues. Currently we only
have one label `priority/blocker` for marking an issue as a blocker
+for a given release. Please only mark this issue as *blocker* only when it is a real blocker
for a given release. If you have no idea about this, just leave
+it as empty.
+#### Status
+If an issue is assigned to a contributor, that means there is already a contributor working
on it. If an issue is unassigned, you can pick this up by assigning
+it to yourself (for committers), or comment on the issue saying you would like to give it
a try.
+If an issue is not an issue anymore, close it and mark it as `status/wontfix`.
+All the issues marked as `status/help-needed` are good candidates for new contributors to
start with.
+#### BookKeeper Proposal
+If an issue is a `BookKeeper Proposal`, label it as `BP`.
+#### Milestone and Release
+If you want some features merge into a given milestone or release, please associate the issue
with a given milestone or release.
+If you have no idea, just leave them empty. The committers will manage them for you.
+Thank you for contributing to Apache BookKeeper!
diff --git a/site/community/ b/site/community/
new file mode 100644
index 0000000..8936023
--- /dev/null
+++ b/site/community/
@@ -0,0 +1,19 @@
+title: Community Meetings
+The community meeting runs bi-weekly on Thursday 8am - 9am PST. The meeting link is [](
+The meeting is typically comprised of 3 parts:
+- Discuss [BookKeeper Proposals](
+- Review and address concerns for any open pull requests.
+- Open discussion.
+As a member of the BookKeeper community, you are welcome to join any of the meetings if you
are interested in. No registration required.
+<iframe src=""
style="border: 0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
+### Past Community Meetings
+You can read the meeting notes from [past community meetings](
diff --git a/site/community/ b/site/community/
new file mode 100644
index 0000000..c5ac39b
--- /dev/null
+++ b/site/community/
@@ -0,0 +1,31 @@
+title: Papers and Presentations
+## Papers
+- [DistributedLog: A High Performance Replicated Log Service](,
Sijie Guo, Robin Dhamankar, and Leigh Stewart. Data Engineering (ICDE), 2017 IEEE 33rd International
Conference on. IEEE, 2017.
+- [Durability with BookKeeper](, Flavio P. Junqueira,
Ivan Kelly, Benjamin Reed
+## Presentations
+- [Apache BookKeeper: A High Performance and Low Latency Storage Service](,
Sijie Guo, Linux Vault 2017
+- [Apache BookKeeper as distributed Store](,
JV Jujjuri, ApacheCon 2016
+- [Building a Durable Real-Time Data Pipeline: Apache BookKeeper at Twitter](,
Leigh Stewart, Apache Big Data 2016 ( [Slides](
+- [Scale DistributedLog at Twitter](, Sijie Guo,
QCon Beijing, April 2016
+- [Building DistributedLog, a high-performance replicated log service](
Sijie Guo, Strata+Hadoop World, March 2016
+- [Building DistributedLog, a high-performance replicated log service](,
Sijie Guo, Sep 2015
+- [Cloud Messaging Service - Technical Overview](,
Matteo Merli, Sep 2015
+- [Building reliable systems with Apache BookKeeper](,
Matthieu Morel, Jun 2014
+- [Serving millions of journals with Apache BookKeeper](,
Flavio P. Junqueira, Ivan Kelly, March 2013
+- [Namenode High Availability with BookKeeper](,
Uma Maheswara Rao G, At Hadoop And BigData Technology Conference 2012
+- [Durability with BookKeeper](,
Flavio P. Junqueira, LADIS Workshop, July 2012
+- [BookKeeper](,
Flavio P. Junqueira, Hadoop in China, 2011
+## Blog Posts
+- [Open-sourcing Pulsar, Pub-sub Messaging at Scale](,
Sep 2016
+- [Majordodo - a Distributed Resource Manager built on top of Apache BookKeeper](,
March 2016 
+- [Building DistributedLog - Twitter's high performance replicated log service](,
Sep 2015
+- [BookKeeper - Yahoo's Distributed Log Storage - is an Apache Top Level Project](,
Feb 2015
+- [BookKeeper - Durability at Scale](,
Nov 2012
diff --git a/site/community/ b/site/community/
new file mode 100644
index 0000000..ac839ec
--- /dev/null
+++ b/site/community/
@@ -0,0 +1,33 @@
+title: Release Management
+> Apache BookKeeper community adopts [Time Based Release Plan](
starting from 4.6.0.
+Apache BookKeeper community makes a feture release every 3 month.
+- A month before the release date, the release manager will cut branches and also publish
a list of features that will be included in the release. These features will typically
+    be [BookKeeper Proposals](,
but not always.
+- Another week will be left for *minor* features to get in, but at this point the community
will start efforts to stabilize the release branch and contribute mostly tests and fixes.
+- Two weeks before the release date, the bookkeeper community will announce code-freeze and
start rolling out release candidates, after which only fixes for blocking bugs will be merged.
+## Current Release
+### Feature Release Window
+The next feature release is `4.6.0`. The release window is the following:
+| **Date** | **Event** |
+| August 12, 2017 | Merge window opens on master branch |
+| October 16, 2017 | Major feature should be in, Cut release branch |
+| October 23, 2017 | Minor feature should be in, Stabilize release branch |
+| October 30, 2017 - November 12, 2017 | Code freeze, Only accept fixes for blocking issues,
Rolling out release candidates |
+## Release Schedule
+- **4.6.0**: August 2017 - November 2017
+- **4.7.0**: November 2017 - February 2018
+- **4.8.0**: Februrary 2018 - May 2018
+- **4.9.0**: May 2018 - August 2018
+<iframe src=""
style="border: 0" width="800" height="600" frameborder="0" scrolling="no"></iframe>

To stop receiving notification emails like this one, please contact
['"" <>'].

View raw message