+1 for feature/issue branches style as well, btw it's a part of git philosophy.
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.


Thanks,
Vladimir.

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,
reporters.

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.

Regards,

-Bruno

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 
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: 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