Hi all!
Thanks for kicking this off, Till, it is a good discussion to have. A few
thoughts from my side:
- From what I get from the first responses, from a development
convenience point the split in repositories would be desirable.
- The biggest obstacles on that way are probably the following two:
1. It is possible to break stuff "downstream", but that seems
manageable.
2. This makes releases more complex, and requires quite a lot of work
in the release scripts and infrastructure.
If someone would be up for spending quite a bit of time on (2), this
could work.
- It is important to emphasize that this would not mean that any of the
other repositories become any less important or second class citizens in
the Flink community.
For that reason, I would actually not do a split in committers / PMC,
but keep the community as a whole. As Gabor mentioned, so far committers
have been acting very responsible and conservative in what code they touch
without additional review - that has worked very well and not become a code
stability issue. I think we can keep that up. If we see that different
committer teams per sub-repository would help, we can revisit that thought.
- From an Apache point of view, having multiple repositories per project
is not a problem.
Having separate sets of committers probably requires to officially fork
off sub-projects, similar as it was with HCatalog and Hive. That is more
involved.
Stephan
On Wed, Feb 22, 2017 at 11:05 AM, Gábor Hermann <m...@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
>
>
