You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

1. Introduction

So far the list of components in Bigtop has remained fairly static with only the versions
of components being upgraded from time to time. This is about to change as we see new
projects being proposed. In order to maintain a certain quality bar we have to establish
a process of accepting patches for inclusion of new components.

Bigtop distribution doesn't have a notion of the "maintainers" and thus, even though the
upfront cost of inclusion may be payed by a single individual, the maintenance costs are
expected to be shared among all the members of our community. Hence it is important for
us to make sure that all members are comfortable with all the projects that are getting
added at least at a very basic level.

2. Hard expectations

This is a list of requirement that we don't want to deviate from unless there
is a really major shift in Bigtop's charter. Any project that violates at
least one of them will have very difficult time convincing us:

  1. Software projects are expected to be Licensed under Apache License, Version 2.0 (and their dependencies are expected to be compatible with this license)
  2. Software projects are expected to integrate well into "big data management software distribution based on Apache Hadoop"
  3. Software projects are expected to be unavailable (at least the desired version) from major Linux distributions (Debian, Ubuntu, RedHat, SuSE)
  4. Software projects are expected to be compatible with all of the supported platforms that Bigtop distribution is targeting
  5. Patches are expected to be added to the trunk first before adding to any released branches
  6. The following is expected to be provided with each patch adding a new project to Bigtop distribution:
    1. packaging code
    2. deployment code
    3. smoke testing code

3. Soft expectations

Violating any of these expectations will require an explicit explanation attached to
the proposal. They are flexible, but it doesn't mean that they can be disregarded
willy-nily.

  1. Project provides test artifacts that go beyond our basic smoke-testing requirement (integration testing)
  2. Project is an Apache Software Foundations project (note: this is different from licensing requirement)
  • No labels