Re: [Freeipa-devel] Feature branches for sub-team efforts
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
Re: [Freeipa-devel] Feature branches for sub-team efforts
On ke, 12 loka 2016, David Kupka wrote: 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 This is rehashing of what Petr wrote already. And I understand the benefits of it. However, I don't like one part of the proposal: removing branches from upstream when feature is merged. This is heavily against accountability -- we should never remove anything from the primary git tree. Also, this churn of branches creates a lot of issues in terms of maintaining internal git datastore as you'll need to clean it from time to time. At this point I don't really see how benefits could outweigh the negatives in the longer term. Thousands of projects are working with separate git trees and do pull requests without negative of having to keep all the temporary feature branches in the main git tree. Why can't we? 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 -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Feature branches for sub-team efforts
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 -- 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
Re: [Freeipa-devel] Feature branches for sub-team efforts
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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Feature branches for sub-team efforts
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
Re: [Freeipa-devel] Feature branches for sub-team efforts
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. 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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Feature branches for sub-team efforts
Hi, On 11.10.2016 15:11, 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. +1 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) Personally I would just keep them there, but I don't really care. 2. Too big traffic on a list. - IMO we actually want it - progress will be visible to others +1 Naming: I propose: refactoring-XXX feature-XXX I would be perfectly fine with just XXX, but again I don't really care. Thoughts? Anyone against? Honza -- Jan Cholasta -- 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
Re: [Freeipa-devel] Feature branches for sub-team efforts
On 10/11/2016 03:11 PM, 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) 2. Too big traffic on a list. - IMO we actually want it - progress will be visible to others Naming: I propose: refactoring-XXX feature-XXX Thoughts? Anyone against? Hi, I think feature branches are a good idea. Once they're merged, I would delete them. I'm for the refactoring-XXX naming convention. -- Tomas Krizek -- 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
[Freeipa-devel] Feature branches for sub-team efforts
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) 2. Too big traffic on a list. - IMO we actually want it - progress will be visible to others Naming: I propose: refactoring-XXX feature-XXX Thoughts? Anyone against? -- 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