+0 from me I think community contributions can be handled well in both cases, merge-forward or cherry-pick. As for the difficulty it is more a matter of habit, in my opinion.
I expect the cherry-pick approach to be less error-prone and mostly for that reason I would give it a try with all the drawbacks it has. On Fri, May 26, 2017 at 6:24 PM, Ina Panova <ipan...@redhat.com> wrote: > Usually, you tend not have your PR opened for months,especially if it is a > bugfix tracked in our sprint :) > > Really, what is difficult about step 5 and 6 i don't understand? you pull > changes so branch is up to date, then you merge into this branch, then you > push to upstream. If there are conflicts you are resolving them locally, > then pushing upstream. > > What i want to say in other words - right now the merge or PRs takes me > like 2 mins going through whole chain of branch-dev to master. Rarely i > need to solve conflicts, but honestly saying i do not remember when was > last time i've been solving those. > > With new approach it will be, merge here, cherry pick there, open pr for > cherry picks, merge pr, open redmine, change it,etc > > Those are my personal 2 cents. > I am opened to try this out, i just find that this new approach does not > cover the cost of steps and time involved for making the git history > cleaner and other things mentioned previously in my email > > > > -------- > Regards, > > Ina Panova > Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > On Fri, May 26, 2017 at 5:46 PM, David Davis <davidda...@redhat.com> > wrote: > >> The current workflow is more than a two-step process. To expand all the >> steps: >> >> 1. Decide what x.y-dev branch to open a PR against >> 2. Open a PR against that branch >> 3. After the PR is accepted, decide if you can actually still merge it >> against the branch. This is necessary if for example, if I opened a PR >> several months ago against 2.12-dev and it was since released. Then I have >> to update the PR to point to 2.13-dev. >> 4. Merge the PR >> 5. Merge the x.y-dev branch to master locally >> 6. Push the local changes directly to the upstream repository >> >> These steps 5 and 6 seem more error prone in that no one is reviewing >> them. In the git cherry-pick workflow, having someone reviewing the >> cherry-picks should reduce errors. Also, since you’re moving individual >> commits instead of merging whole branches together, mistakes should be far >> less disastrous if they do somehow occur. >> >> >> David >> >> On Fri, May 26, 2017 at 10:29 AM, Ina Panova <ipan...@redhat.com> wrote: >> >>> -0 >>> >>> I don't know, i am personally not super excited about cherry-picking, >>> too many involved resources imho in order to compensate crazy git history. >>> >>> 1. submit pr against master >>> 2. decide into which branches it should be cherry-picked >>> 3. submit PRs against those branches >>> 4. Find someone to approve it( person can approve it right away or can >>> forget), you then need again to bother the person to approve the PR, plus >>> you also can forget about them. >>> 5. If the bugfix/rfe/hotfix consists of several PRs, like platform and >>> plugin, you need to take care of more PRs and be sure you opened all of >>> them and merged all of them. >>> 6. since the commit id changes, you need to keep track of the info >>> externally. That means open Redmine and update it. >>> >>> >>> With merge forward you just merge forward and need to take care of: >>> >>> 1. be sure you merged all PRs through all branches. >>> 2. solve conflicts occasionally. >>> >>> >>> The concern Brian brought up - that contributors do not know against >>> which branch to submit PR. Instead of asking them to re-submit PR against >>> different branch we can cherry pick this, >>> We don't have that 'big traffic' of PRs from contributors and once in a >>> while we can cherry pick if the PR was submitted against wrong branch. >>> >>> Another thing which was stated in the motivation was 'We've also seen >>> some mistakes where branches are accidentally merged into other branches. " >>> I guess we will have much higher chance to make a mistake or forget >>> something between steps 1-6 mentioned for cherry-picking then steps 1-2 >>> mentioned for merging forward. >>> >>> >>> >>> -------- >>> Regards, >>> >>> Ina Panova >>> Software Engineer| Pulp| Red Hat Inc. >>> >>> "Do not go where the path may lead, >>> go instead where there is no path and leave a trail." >>> >>> On Thu, May 25, 2017 at 6:49 PM, Sean Myers <sean.my...@redhat.com> >>> wrote: >>> >>>> On 05/25/2017 10:30 AM, Patrick Creech wrote: >>>> > -1 >>>> > >>>> > While trying to come up with a decision on this topic, I googled "git >>>> merge vs cherry-pick". The >>>> > overwhelming ammount of search results were basically 'don't >>>> cherry-pick!'. The page that I favored >>>> > is [0]. It brings up some good points about loosing git's internal >>>> tracking of commits. It seems >>>> > cherry-picks do get new commit id's instead of using the same ones. >>>> While this site is basically a >>>> > 'Don't cherry pick' opinion piece, it did make me think about our >>>> motivations for moving away. >>>> >>>> Merging forward *does not* guarantee that the changes you're looking >>>> for actually exist on a branch. git-cherry does. The article you >>>> linked is citing a specific problem and blaming it on cherry-picking, >>>> which is that when cherry-picking commits *with conflicts*, you can >>>> confuse git-cherry. This is accounted for in the in the PUP, and for >>>> good reasons. >>>> >>>> > ... >>>> > >>>> > I'm more in favor of us re-evaluating when and how we manage the >>>> merge forwards (as it does appear >>>> > our current automation has been a big source of pain at least once), >>>> and believe that just adding >>>> > better process and diligence around our current way of doing things >>>> will probably be better than >>>> > inventing a new process and figuring out the pain points as we go >>>> there. >>>> >>>> In my experience, only one merge-forward problem was caused by >>>> automation (the mergepocalype, when 2.10 was considered "less than" >>>> 2.2, and got merged forward into a lower branch). The rest were >>>> intelligent humans making mistakes, first with a bad merge, and second >>>> by trusting that the appearance of a given commit hash on a branch >>>> means that the *change* associated with that commit hash therefore >>>> also appears on that branch (it does not). Perhaps ironically, any >>>> improvement to the merge-forward process would likely involve using >>>> git-cherry to track actual changes, ignoring what hash is where. >>>> >>>> The suggestions that we invent a better process for merging forward >>>> immeditaely followed by a suggestion to not invent a new process is a >>>> little bit confusing. Either deal with the merge-forward papercuts or >>>> the cherry-pick papercuts, it's inventing new process either way. When >>>> it comes to the merging forward process, the intelligent humans were >>>> (in my opinion) being diligent in their application of the process in >>>> every failure case I can recall, and I don't think just throwing more >>>> "diligence" at the problem will solve it. >>>> >>>> On the other hand, cherry-picking back from master is not a new >>>> process that we're inventing. This is a common workflow, not something >>>> being invented by this PUP, so the opportunity to find help with this >>>> process outside of this team is tremendously valuable. No such >>>> opportunity exists with the merge-forward strategy without moving to a >>>> more generally-accepted merging strategy like git flow(/driessen). >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
