[infinispan-dev] Infinispan 7.1 plan

[Tristan Tarrant]

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 <mmarkus at redhat.com 
> <mailto:mmarkus at redhat.com>> wrote:
>
>>
>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel at hibernate.org 
>> <mailto:emmanuel at hibernate.org>> 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 <ttarrant at redhat.com 
>>> <mailto:ttarrant at redhat.com>> 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
>>>> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev