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
