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

[David Kupka]

On 11/10/16 16:27, Alexander Bokovoy wrote:
> On ti, 11 loka 2016, 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.
>>
>>> 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.
>>
>> In such case we would loose mail notifications and would have to extend
>> our tooling because ipatool can use only one upstream on push.
> So I still think this is not a problem. If people can agree which git
> repo clone will be primary one and submit merge requests against it,
> then there is no problem in having that git repo's branch to be
> submitted as the pull request against the main git repo. This way you'll
> get all the changes seen at the pull request sync time.
>

 From my POV, when we create the refactoring branches in upstream we get 
this for free:
* our minimal but convenient CI (lint + build on each PR)
* mail notifications
* tooling (ipatool pr-push XYZ -b refactoring-xyz just works)

When creating them elsewhere we get:
* confusion (no team-wide notifications, each effort in other fork)
* manual rebasing and pushing

So I think it's best to create the branches in upstream repo. I don't 
care about names and also I don't care what happens with them after the 
effort is done.

-- 
David Kupka