When we spoke about "teams" we spoke in the context of how NetBeans
developer from Oracle have been working on NetBeans.

If you look at http://hg.netbeans.org/ there are multiple repositories with
the title "xxx team repository". So the profiler guys would commit their
(stil-not-finished) stuff in their own branch (which is similar in concept
to a feature branch) and only later on will their changes be pushed to
everybody else. This reduces the chance of a random commit breaking a build
for everybody.

So, by using the team branches it will be easier to continue development.

There is nothing stopping new or existing contributors to use feature
branches.

Do note that the purpose of this migration is just to be able to start
working under Apache. It is not about imposing a technical way of doing
software. Every community is allowed to develop software how they see fit.


--emi

On Fri, Oct 14, 2016 at 1:19 PM, Julien Enselme <jense...@jujens.eu> wrote:

> +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/

Reply via email to