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.
Pre-defined names for PRs is a good idea - we could easily see what
effort the pull request is related to.
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
