> On Oct 12, 2016, at 11:23, Eric Barboni <sk...@apache.org> 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 

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.



Wade Chandler
e: cons...@wadechandler.com

Reply via email to