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 development) 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. Thanks, Wade =================== Wade Chandler e: [email protected] > On Oct 12, 2016, at 14:30, Emilian Bold <[email protected]> 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 < > [email protected]> 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 >>
