[Freeipa-devel] Feature branches for sub-team efforts

[Simo Sorce]

On Tue, 2016-10-11 at 16:19 +0200, Petr Vobornik wrote:
> On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:
> > On ti, 11 loka 2016, Petr Vobornik wrote:
> >> Hi List,
> >>
> >> we discussed locally a proposal about creating a feature branch for each
> >> sub-team effort in our main git. Currently it would be for the 4 ongoing
> >> refactoring efforts + Simo's work
> >>
> >> Why?
> >> It will allow each developer to create a pull request against the
> >> feature branch and thus it will enable iterative development by multiple
> >> devs without affecting other sub-teams. When the feature(refactoring) is
> >> finished, the branch would be rebased on master and merged there. Note:
> >> rebases can be done as needed - e.g. when other subteam finishes its
> >> work.
> >>
> >> Concerns:
> >> 1. Upstream git repo would be full of such branches.
> >> - This can be mitigated by deleting the feature branches when their are
> >> released or merged(up to discussion)
> > Don't put them in the upstream git repo. Let people decide where they
> > want to have them -- all Fedora contributors have access to
> > fedorapeople.org git hosting and there is github one button click
> > ('Clone') away from the github mirror.
> > 
> > It is not a problem to keep a separate git branch published this way.
> > 
> 
> It is not a matter of making the code public. That can be done easily as
> you write. Other alternative is own branch in GitHub fork.

Please go with this.
I see no point in having these branches in the main repo, it is just
clutter.

> > May be I misunderstand you -- if you just want people to propose merge
> > requests on github with pre-defined names, then that's just fine.
> > 
> 
> Basically it's all about review.
> 
> Example use case: More than 1 devs are working on a same big effort.
> This effort will probably consists of 10s of commits. The big effort is
> divided into smaller ones which can be implemented and reviewed
> separately. In our previous mode, the sub task would be merged to master
> it is reviewed and ACKed. But now we cannot do that. We want to merge
> the whole big task at once when it is finishes and tested.
> 
> One dev could probably have a branch on personal fork of FreeIPA on
> GitHub which would work as the feature branch. Other team members would
> create pull requests against it.

Exactly.

> In such case we would loose mail notifications and would have to extend
> our tooling because ipatool can use only one upstream on push.

Why would you need ipatool for a working branch ?

> Pre-defined names for PRs is a good idea - we could easily see what
> effort the pull request is related to.

Predefined how ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York