+1 for feature/issue branches style as well, btw it's a part of git
It could simplify API/patch reviews as well.
In this context one repo has advantage as well, otherwise feature/issue
branches have to be created in multiple repos.
On 13.10.2016 15:18, Bruno Flávio wrote:
+1 for feature/issue branches.
Besides being easy to understand (and pretty standard procedure IMO) it
would also improve the work flow and collaboration between developers,
Right now I produce a patch and attach it to the issue I'm working on
prior to it's integration in the repo so that those watching the issue
can have a say before it's committed. This is a bit cumbersome and would
be nicely solved by short lived feature branches.
On 13/10/16 12:40, Wade Chandler wrote:
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
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.
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
On Wed, Oct 12, 2016 at 9:23 PM, Vladimir Voskresensky <
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
Teams will work on branches.
Then like now  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.