+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 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.
> 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.
>> On Wed, Oct 12, 2016 at 9:23 PM, Vladimir Voskresensky <
>> vladimir.voskresen...@oracle.com> wrote:
>>> 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  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.
>>>  http://wiki.netbeans.org/HgParallelProjectIntegration