Why not feature branches for individual issues? Why long lived “team” branches? 
I think feature branches work for the entire community, and they address a 
particular problem which should be fixed, and not a long list of them which is 
more likely to cause late integration; i.e. changes are not just for cnd or 
groovy, but to something more common.

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 

The feature branches then get merged back to development, and hopefully those 
are relatively small and fast lived branches. Everyone integrates on 
development sooner rather than later. If one needs to make modifications to 
something in lookup or some other shared thing, they would use a specific 
branch for that to make sure that is seen separately and faster other than at 
some other long lived branch which causes delay. Development goes to master 
when “stable”.

If a group needs a longer lived branch for some reason, they can do that here, 
but the point is to better think about early integration as well as the reality 
these are no longer products managed by Oracle, but the entire community, so 
early integration is going to be more important.

If broken out to separate clusters, which I think better supports the community 
working on smaller subsets, and am in favor of that, then a similar model would 
exist. But, it would be in each repository.




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

> On Oct 12, 2016, at 14:30, Emilian Bold <emilian.b...@gmail.com> wrote:
> Yes, I think it makes sense to use branches for 'teams'. Maybe even for
> main-silver, main-golden.
> --emi
> On Wed, Oct 12, 2016 at 9:23 PM, Vladimir Voskresensky <
> vladimir.voskresen...@oracle.com> wrote:
>> Hi,
>> On 12.10.2016 18:23, Eric Barboni wrote:
>>>     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
>> What if we leave one repository as it is now and move 'teams' into git
>> branches (core-main/cnd-main/...).
>> Teams will work on branches.
>> Then like now [1] the current push-cnd-main job can be replaced by
>> automatic 'push cnd-main into main-silver branch', while push-to-cnd-main
>> job will be automatic 'push main-silver into cnd-main'.
>> Branch main-silver is built and tested as now and on success main-silver
>> is pushed into main-golden for the production build.
>> Thanks,
>> Vladimir.
>> [1] http://wiki.netbeans.org/HgParallelProjectIntegration

Reply via email to