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