+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