> On Oct 12, 2016, at 11:23, Eric Barboni <[email protected]> wrote: > > Hi, > 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 > cluster >
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 development) 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. https://help.github.com/articles/about-pull-requests/ <https://help.github.com/articles/about-pull-requests/> These sound like good times to rethink some of the NB processes IMO considering new infra and other concerns. Wade =================== Wade Chandler e: [email protected]
