+1 for feature/issue branches that shouldn't live long and master/devel for long term stuff. As far as I know, this is how we are supposed to use git.
On Fri, 2016-10-14 at 12:38 +0300, Vladimir Voskresensky wrote: > > In this context one repo has advantage as well, otherwise > feature/issue > branches have to be created in multiple repos. If an issue touches a huge number of different files, one repo makes it easier to solve. But as already said, from a contributor's point of view, it is easier to deal with smaller repos (fast to clone and don't take a lot of disk space). It also seems to be "the git way". > > 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 > > > > > > > > -- Julien Enselme http://www.jujens.eu/
signature.asc
Description: This is a digitally signed message part
