+1 On Mon, Feb 6, 2017 at 12:09 PM, Ina Panova <[email protected]> wrote:
> Seems like we are trying to choose/figure out what's more important - > linear commit history which is readable or confidence and ability to track > where exactly change had been applied? > > I agree with Mike and think that merging forward is so super simple, i > must admit i had issues to understand this strategy from the beginning but > now i could do that even with closed eyes. > > +1 of writing down the benefits of cherry-picking and clear our > expectations. > > > > -------- > 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, Feb 2, 2017 at 6:50 PM, David Davis <[email protected]> wrote: > >> I think the merging forward seems pretty straightforward as well (with >> some exceptions) but one of the my concerns is expecting community >> contributors to know our process, the last release branch, etc when they >> open a PR. Maybe this isn’t something to worry about though if we don’t >> have enough contributions from outside the core Pulp team. >> >> Another one of my concerns is the git history being cluttered by merging >> forward every time we commit a bug fix or hot fix (see my original email). >> Thinking through this a bit though, what if we merged forward commits less >> often? One option might be to only merge forward when we do a release. >> >> Also, I like the idea of creating a proposal and trying out cherrypicking >> to see what the benefits would be and if we actually meet those benefits by >> cherrypicking. >> >> >> David >> >> On Thu, Feb 2, 2017 at 10:46 AM, Michael Hrivnak <[email protected]> >> wrote: >> >>> This comes up periodically, and we've had split opinions for a long >>> time. I've been in the camp that likes merging, and finds it intuitive. But >>> I'm open to trying cherry-picking since there is a lot of interest. >>> >>> I must admit, I am always surprised when people describe merging forward >>> as complicated. For me, it boils down to this: >>> >>> - Features happen on master. No merging or cherry-picking required. >>> - Bug fixes happen on the last release branch. Merge your bugfix branch >>> to master and the release branch. Simple. >>> - Hotfixes are a rare exception that require slightly more thought, but >>> are still easy to reason about. If in doubt, "git merge-base [list all the >>> places you want to merge your fix]" tells you where to branch from. >>> >>> That's the extent of my thought process when merging forward. I am >>> generally interested to know more about how this process causes friction. >>> >>> But all of that said, I'm very happy to give cherry-picking a try. As >>> Brian said, my main concern would just be tracking where a change has been >>> applied. This is something I value a lot in the merge model. >>> >>> If we do switch, I think we should first write down specifically what >>> benefits we expect to get. That would help in two ways: 1) Make sure >>> everyone is on the same page about what we expect to gain. I suspect there >>> are differing assumptions across the group. 2) Enable us to evaluate >>> afterward to what extent the change was successful. >>> >>> Lastly, our current branching model was inspired by this classic >>> approach: >>> >>> http://nvie.com/posts/a-successful-git-branching-model/ >>> >>> If you're not familiar, it's worth a read for perspective. Their >>> "develop" branch is our "master". And obviously we don't do things in quite >>> the same way, but the general principles are the same. >>> >>> Michael >>> >>> On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <[email protected]> >>> wrote: >>> >>>> The main concern for me is how to track the cherry picks in Redmine. >>>> Using the rebase and merge approach, or if Github had a dedicate cherry >>>> pick feature, we still need a way in Redmine to know if any given bugfix >>>> has been applied to older release streams, i.e. the current bugfix release >>>> stream. >>>> >>>> On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <[email protected]> >>>> wrote: >>>> >>>>> > Thinking out loud, it would be nice if github would support a >>>>> "cherry pick" PR >>>>> >>>>> I think you can. The submitter just needs to open a PR against some >>>>> branch other than master, and the merger needs to select the rebase >>>>> and merge >>>>> <https://github.com/blog/2243-rebase-and-merge-pull-requests> GUI >>>>> option. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
