Page History

...

1. Correctness concerns: If a patch touching a lot of code and it is difficult to verify it's correctness, it might be rejected.
2. User space utilitiesfunctionality: If a patch is adding utility functions features that could exist in a third-party library package rather than Spark itself, we sometimes encourage users to publish utilities in their own library. This is especially true for large standalone modules.
3. Too complex: Spark desires to have a maintainable and simple codebase. If features are very complex relative to their benefit, they may be rejected.
4. Regressing behavior: If a patch regresses behavior that is implicitly or explicitly depended on by users, it might be rejected on this basis.
   
5. Introducing new API's: Patches that propose new public or experimental API's must meet a high bar in Spark due to our API compatibility guidelines.
6. Not applicable to enough users: Optimizations or features might be rejected on the basis of being too esoteric and not useful to a broad enough audience.
7. Introduction of dependencies: Due to the complex nature of Spark, we are conservative about introducing new dependencies. If patches add new dependencies to Spark, they may not be merged.

...