+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  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. >>>  http://wiki.netbeans.org/HgParallelProjectIntegration >>> >