Sure, you still want to review it in your IDE, and maybe run local tests, but ultimately merging via the GitHub UI.
Tristan On 20/10/14 18:37, Emmanuel Bernard wrote: > rebase is a oneliner op per branch you want to reapply whereas cherry > picking requires to manually select the commits you want. Underneath > in git guts it probably does the same. > > I have to admit I barely had the occasion to want to click the GitHub > UI button as except for simple documentation, reviewing code almost > always require to fetch the branch and look at it in an IDE of sort > for proper review. The documentation bit is actually even requiring > local run since Markdown / Asciidoc and all tend to silently fail a > syntax mistake. > > On 20 Oct 2014, at 18:28, Mircea Markus <[email protected] > <mailto:[email protected]>> wrote: > >> >> On Oct 20, 2014, at 17:21, Emmanuel Bernard <[email protected] >> <mailto:[email protected]>> wrote: >> >>> There is a difference between cherry picking and rebasing when it >>> comes to reapply a work on top of a branch. >> >> What is the difference? :-) >> >>> Do you dislike both equally compared to a merge (aka railroad nexus >>> git history approach)? >> >> Using github's "merge" button is pretty convenient imo, even though >> the history is not as nice as with a rebase (or cherry-pick, I miss >> the difference for now ) >> >>> >>> >>> On 20 Oct 2014, at 16:47, Tristan Tarrant <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> Hi guys, >>>> >>>> with the imminent release of 7.0.0.CR2 we are reaching the end of this >>>> release cycle. There have been a ton of improvements (maybe too many) >>>> and a lot of time has passed since the previous version (maybe to >>>> much). >>>> Following up on my previous e-mail about future plans, here's a >>>> recap of >>>> a plan which I believe will allow us to move at a much quicker pace: >>>> >>>> For the next minor releases I would like to suggest the following >>>> strategy: >>>> - use a 3 month timebox where we strive to maintain master in an >>>> "always releasable" state >>>> - complex feature work will need to happen onto dedicated feature >>>> branches, using the usual GitHub pull-request workflow >>>> - only when a feature is complete (code, tests, docs, reviewed, >>>> CI-checked) it will be merged back into master >>>> - if a feature is running late it will be postponed to the >>>> following minor release so as not to hinder other development >>>> >>>> I am also going to suggest dropping the cherry-picking approach and >>>> going with git merge. In order to achieve this we need CI to be >>>> always in top form with 0 failures in master. This will allow >>>> merging a PR directly from GitHub's interface. We obviously need to >>>> trust our tools and our existing code base. >>>> >>>> This is the plan for 7.1.0: >>>> >>>> 13 November 7.1.0.Alpha1 >>>> 18 December 7.1.0.Beta1 >>>> 15 January 7.1.0.CR1 >>>> 30 January 7.1.0.Final >>>> >>>> >>>> Tristan >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
