flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: [DISCUSS] Project build time and possible restructuring
Date Wed, 22 Feb 2017 13:08:34 GMT
I'm not against splitting but I wan't to highlight that there are other
 - We could split the tests run on travis logically. For example, run unit
tests and integration tests separately. This would have the benefit that
you would see early on if the (fast) unit tests fail. We could also split
by components. Maybe have: runtime tests, API tests and library tests.
 - We could also look into using Jenkins properly, have separate pre-commit
hooks that run on PRs that test the code in a fine-grained way. Units
tests/IT tests, separate Jenkins profiles for runtime, API and so on.

On Wed, 22 Feb 2017 at 11:06 Gábor Hermann <mail@gaborhermann.com> wrote:

> Hi all,
> I'm also in favor of splitting, but only in terms of committers. I agree
> with Theodore, that async releases would cause confusion. With time
> based releases [1] it should be easy to sync release.
> Even if it's possible to add committers to different components, should
> we do a more fine-grained split? E.g. should we split the committers of
> Gelly and ML? If not, committers should be trusted not to fiddle with
> something that's not their territory. That might not be a problem, as it
> seems to be the case right now.
> What should we do if ASF does not allow splitting? Should we add more
> committers and trust them not to touch code that's not their
> responsibility? That's the same as no split in terms of committers
> (build time can be lowered of course).
> What about ensuring code quality? In my opinion the primary reason of
> being a committer is to ensure code quality. Committers are trusted to
> adhere to a certain code quality, partly determined by developer
> guidelines, and make others adhere too.
> By adding more committers with less consideration, we are risking the
> quality of different components. That might not be a problem, because
> that's the price of a more dynamic development in libraries etc., but we
> should ensure that *eventually* the code quality converges to what's
> expected by Flink. So a new committer would learn some of the
> responsibilities as a committer, not as a contributor. But what if the
> new committer fails to adhere? Is there a way to revoke committer status?
> [1] https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases
> Cheers,
> Gabor

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message