> On Oct 12, 2016, at 11:23, Eric Barboni <sk...@apache.org> wrote:
> Cluster separation seems very logical to me.
> Would it be possible to put build infrastructure alongside with source
> management ?
> With the split in cluster it may possible to get rid of the "team"
> repositories (i.e. "core-main","cnd-main","jet-main") but we may need another
> repository ( kind of current "main-silver" or "main-golden") to prevent a
> bad commit leading to compile error in one cluster to be propagated to the
> full NetBeans break the build for others who did not need this particular
I think extra community repositories, outside of user clones and repositories
for PRs and patches, unless they are specifically to independently hold a
cluster for the purpose of better and smaller granularity, are bad ideas. That
causes a lot more sync than I personally feel is needed. Feature branches and
simplicity for the committers sounds better IMO. Too, looking for ways to
reduce integration points sounds like a good idea; i.e. don’t have too many
long lived branches, but instead focus on features as the unit you are trying
to solve with long lived branches only existing for some really heavy thing
such as a massive refactor, and as such the branches become strategic versus
big artifacts in themselves.
In another email I mentioned something like:
i.e. (without a separate silver)
master (what used to be main-golden)
--development (what used to be main and silver (integration and main build))
----cnd/feature-abc (a cnd specific feature branch)
----groovy/feature-abc (a groovy specific feature branch)
------wadechandler/bug-or-feature-abc (a specific fix I want to merge up to
this feature branch with others)
----wadechandler/bug-xyz (a specific fix for a bug submitted by me to merge to
Too, I think if one is not a committer, their PRs would come from their own
individual repositories. I believe that is how we should accept patches going
forward. That allows us to then do code reviews right there in the PRs with
inline comments and other nice features plus there is a trail of all that data.
Merges between committers should also use PRs IMO. My teams use them, and they
work wonderfully. We also use branching, and that works out too.
These sound like good times to rethink some of the NB processes IMO considering
new infra and other concerns.