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
