Hazelcast Enhancement Proposals
What is a Hazelcast Enhancement Proposal?
Hazelcast Enhancement Proposals ("HEPs") are proposals for new community driven features or enhancements to Hazelcast. The HEP procedure is inspired by OpenJDK's JEP process and helps organizing, planning and implementation of the prior named enhancements.
Why the Enhancement Proposals?
First of all we are always super excited to accept external contributions, this is what open source is all about, teamwork!
We want to ensure you get your changes merged in with the minimum fuss. For smaller changes just send a pull request (PR) just as you always did. Bigger features can be trickier as they often require a non-trivial amount of communication, synchronization and time. There is nothing more disappointing than refusing a nice contribution, that took a lot of effort and work, just because someone else is already working on it.
We value the time of our contributors and the Hazelcast Incubator is our attempt to provide our feedback as quickly as possible. We want to provide transparent work, a set of comprehensive rules and a simple process to help people find other interested companions, to encourage teamwork on amazing features and to prevent people from becoming upset about spent time when a pull request cannot be merged into the Hazelcast code base.
How to Submit a HEP Request?
HEPs are generally contributed by our community members. Hazelcast encourages its own employees to work with the community and help on questions asked. For questions specific to the HEP procedure please feel free to contact us at :
- mail: david@hazelcast.com
- twitter: @dbrimley or on the
- Hazelcast Gitter Channel: https://gitter.im/hazelcast/hazelcast
The best idea is to just drop a line and discuss your idea.
After discussion the easiest way is to use the wiki template to create your proposal and send it via mail: Hazelcast Enhancement Proposal ("HEP") Template, Version 1
What is the procedure?
The submitted Hazelcast Enhancement Proposals will be written to this wiki as quickly as possible. After submission there is a 1 week period of internal discussion with the team that is responsible for the selected component, as well as discussion from the community side. Things we look at in deciding to accept a HEP:
- Alignment with the features and architecture direction of Hazelcast
- Viability of the community team to develop
- Viability of the community team to maintain
Normally you can expect a HEP to be accepted but there might be cases where the proposal is not yet detailed enough, does not meet internal standards or is denied for other reasons. In any of those later cases we will always reason our decision and if there is a chance help on improving the proposal to resolve the denial reasons.
The Hazelcast Incubator procedure itself is documented in HEP 1 - Hazelcast Incubator and Hazelcast Enhancement Proposal ("HEP").
Once accepted, a repository is created at the Hazelcast Incubator Github repository and an initial fork for the new HEP is added. Any active work on the incubated enhancement happens here, specifications, documentation and issues will also be collected in this single place. In addition a public Gitter channel is registered for discussions to take place. Further interested people might also request to join the HEP at this point as contributors.
All additional information that are mentioned in the above template but are not in the online questionnaire will be filled out with the expected values by the community lead.
How to contribute to existing HEPs?
If a HEP is already existing and not yet finished, the best way to offer help or interest is to drop one of the authors a short line on twitter, jump into the HEP's Gitter channel or, if available, writing a mail. Interested people are expected to be accepted as new members to the HEP by the current team, if reasonable. Pull requests to an Incubator repository on Github are generally welcomed if not otherwise specified by the team working on the HEP.
After completing a HEP the enhancement will be merged into the Hazelcast code base. No further work can be done on the incubator repository and it will eventually be deleted. Therefore no new members can be accepted after completion of a HEP.
To extend a previously completed HEP or to create a maintenance release please issue a new proposal mentioning the reasons or enhancements over the old one.
Home of HEPs
HEPs are collected in a single place to give interested people a simple way to find out about existing proposals and start working themselves into the codebase of the enhancement. Pull requests against an Incubator repository of the project are welcomed!
HEPs are kept in the Hazelcast Incubator Github repository at: https://github.com/hazelcast-incubator
Once accepted, a repository is created here. Active work on the incubated feature happens here, issues and so on. In addition a public Gitter channel matching the HEP's shortname is created and used for further discussion.
Accepted HEPs
| HEP# | Name | Summary | Component | Status | Lead | Discussion |
|---|---|---|---|---|---|---|
Open Proposals
| Name | Summary | Component | Lead | Discussion |
|---|---|---|---|---|
| Hazelcast SPI for Indexing Services | The Hazelcast Indexing SPI will provide an extension SPI to implement arbitrary / user defined types of indexes. So far Hazelcast provides an indexing system for simple key/value indexed attributes but common questions include indexes for geospatial or partial indexes. | Core | Christoph Engelbert | https://gitter.im/hazelcast/hazelcast |
Closed Proposals
| HEP# | Name | Summary | Component | Status | Lead |
|---|---|---|---|---|---|
| 1 | Hazelcast Incubator and Hazelcast Enhancement Proposal ("HEP") | This proposal defines the coverage and the limits for the new Hazelcast Incubator. It is meant to help community members to work together and give them guidance on how to successfully help enhancing Hazelcast upon their ideas and visions. | Community Process | Completed | Christoph Engelbert |
| 2 | Hazelcast Discovery SPI | The Hazelcast Discovery SPI will provide an extension SPI to attach external cloud discovery mechanisms. Discovery is meant to find other Hazelcast instances based on certain filters and provide their corresponding IP addresses. | Integration | Completed | Paulo Pires |
| 3 | Entry Cost Calculator SPI | In the currently available memory cost calculator implementation, memory cost is not calculated when In-Memory-Format is not BINARY, thus eviction policy based on memory consumption can't be used at all. It would be beneficial to allow users assign their own memory-cost-calculator for such case via Config interfaces and in xml configuration. | Core | Suspended | Denis Sukhoroslov |
| 4 | Spring Data Integration Phase 1 (commons) | A first phase implementation for Spring Data Integration into Hazelcast, implementing "commons" features. | Integration | Completed | Neil Stevenson |
| 5 | Quartz JobStore Integration | This proposal contains a Cluster-Job-Store based on Hazelcast objects to be used with Quartz > V2.2. The job store is a derivation of the JDBC-Job-Store, delivered with the Quartz package. | Integration | Dead | Wolfgang Haag |
| 6 | Cascading Integration | Cascading is a data processing API and processing query planner used for defining, sharing, and executing data-processing workflows on a single computing node or distributed computing cluster. Per default Cascading runs on either in single-node (local-mode) setup or on top of hadoop using the hadoop mapreduce framework or Apache tez (in upcoming version 3). Hazelcast would be a good fit to act as an underlying execution framework alongside the already existing ones. | Integration | Dead | Alexander Toktarev |
| 7 | Hazelcast Python Client | This project aims to create a semi-functional Python client. The client will be able to execute operations on supported Hazelcast data structures. In addition, the client will be able to register for updates from the cluster and be able to keep track of them. | Client | Superseded | Jonathan Brodie |
| 8 | Hazelcast Distributed File System Layer | HZDFS the Hazelcast Distributed Filesystem Layer is a filesystem with simple access rights management and the possibility to store files larger than 2GB (chunked) in Hazelcast. | Integration | Suspended | Sven Ruppert |
Some Open Feature Requests
The following list shows a aggregation of open feature requests that might be interesting to be implemented by the community. If you are interested to any of those feature request to implement it in form of a HEP please drop a line on the above contact possibilities.
Effort and Difficulties are defined in 3 different types: S, M, L