Policy for accepting new modules and large contributions. Protocol for removing modules

[Roman Leventov <le...@apache.org>]

Historically, Druid has been exceptionally inclusive for external
contributors, but support costs are not taken into account.

Does anybody see this as a problem?

We may require for large "feature" PRs to core modules, including PRs into
some "core" extensions (such as kafka-indexing and sql) (those that
increase number of classes and complexity) to either
 - Be authored by a committer. So if a non-committer want to push such a
big change to the core, he needs to become a committer first.
 - Be "endorsed" by at least two committers who are recently active in
Druid. (Read: supporting Druid is part of their job duty, at least
part-time.)

Regarding removing old modules, we may revisit all extensions in
extensions-core and extensions-contrib.
 - The new contrib may not be tested in CI builds unless the contrib code
is changed in the PR (note: I failed to quickly find if Travis supports
such thing. It may not.)
 - Contrib modules may not be included in the general Druid distribution
(but some vendors may include some contrib modules into their
distributions).
 - Updating contrib modules' code (even making them compile against the
core) may become the sole responsibility of people who care about these
contrib modules.
 - If we see that some contrib module "falls off" and nobody updates it
for, say, one year, we remove the module from the codebase completely.

Note: both ideas presented above are merely ideas, not firm proposals.

Re: Policy for accepting new modules and large contributions. Protocol for removing modules

[Julian Hyde <jh...@apache.org>]

One line of this policy is problematic:

> Be "endorsed" by at least two committers who are recently active in
> Druid. (Read: supporting Druid is part of their job duty, at least
> part-time.)

It creates two tiers of committers.

Sustainability is a concern for all code contributions. The project can decide to reject contributions on that basis. But we have to trust that all committers are acting in the best interests of the project. Their employment status is irrelevant.

Julian


> On Mar 20, 2019, at 3:48 PM, Roman Leventov <le...@apache.org> wrote:
> 
> Historically, Druid has been exceptionally inclusive for external
> contributors, but support costs are not taken into account.
> 
> Does anybody see this as a problem?
> 
> We may require for large "feature" PRs to core modules, including PRs into
> some "core" extensions (such as kafka-indexing and sql) (those that
> increase number of classes and complexity) to either
> - Be authored by a committer. So if a non-committer want to push such a
> big change to the core, he needs to become a committer first.
> - Be "endorsed" by at least two committers who are recently active in
> Druid. (Read: supporting Druid is part of their job duty, at least
> part-time.)
> 
> Regarding removing old modules, we may revisit all extensions in
> extensions-core and extensions-contrib.
> - The new contrib may not be tested in CI builds unless the contrib code
> is changed in the PR (note: I failed to quickly find if Travis supports
> such thing. It may not.)
> - Contrib modules may not be included in the general Druid distribution
> (but some vendors may include some contrib modules into their
> distributions).
> - Updating contrib modules' code (even making them compile against the
> core) may become the sole responsibility of people who care about these
> contrib modules.
> - If we see that some contrib module "falls off" and nobody updates it
> for, say, one year, we remove the module from the codebase completely.
> 
> Note: both ideas presented above are merely ideas, not firm proposals.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@druid.apache.org
For additional commands, e-mail: dev-help@druid.apache.org