Hi,
Just wanted to check if anyone has any feedback on this thread? Something we
want to discuss, add, change, adapt and adopt?
if we’re all good I’ll start a voting thread tonight for adopting this.
Cheers.
On 07-Aug-2014, at 10:39 am, Rohit Yadav wrote:
> Hi,
>
> I think the following can s
Hi Min,
On 07-Aug-2014, at 7:22 pm, Min Chen wrote:
> Hi Rohit,
>
> IMHO, the root cause for RM cherry-pick problem is code quality. Without
> solving that first based on some kind of enforcement, this will not help
> much. The reason to use forward branch and RM cherry-picking is to control
> w
Hi Rohit,
IMHO, the root cause for RM cherry-pick problem is code quality. Without
solving that first based on some kind of enforcement, this will not help
much. The reason to use forward branch and RM cherry-picking is to control
what can go to release branch. Your proposal removed that p
Hi Hari,
You’ve a valid concern, but on master when we’re pushing bugfixes for multiple
issues the RM eventually picks them to release branch anyway.
At the end of the day, usage of automated tests, build/unit tests will ensure
some quality control. This proposal will solve issues for RM (the c
Hi David,
On 07-Aug-2014, at 2:37 pm, David Nalley wrote:
> On Thu, Aug 7, 2014 at 4:39 AM, Rohit Yadav wrote:
>> Hi,
>>
>> I think the following can solve the cherry-picking problem but it needs
>> everyone’s support to work:
>>
>> - Once a release branch is cut out, all the committers and co
Hari,
if we merge we can no longer distinguish between minor and trivial or
major till block. And we shouldn't as we validate any staging branch
periodically before merging.
On Thu, Aug 7, 2014 at 2:51 PM, Harikrishna Patnala
wrote:
> Hi Rohit,
> Thanks for the proposal.
>
> I’ve some concerns.
Hi Rohit,
Thanks for the proposal.
I’ve some concerns.
If we work directly on release branch only (with out forward branch) I’m not
sure how we control regressions in the release time.
In case of forward branch cut from the release branch RMs will merge only
critical bug fixes to release branc
On Thu, Aug 7, 2014 at 4:39 AM, Rohit Yadav wrote:
> Hi,
>
> I think the following can solve the cherry-picking problem but it needs
> everyone’s support to work:
>
> - Once a release branch is cut out, all the committers and contributors
> “should” only work on the release branch. It can be dis
On Thu, Aug 7, 2014 at 3:09 PM, Rohit Yadav
wrote:
>
> On 07-Aug-2014, at 11:23 am, Rajani Karuturi wrote:
>
> > Hi Rohit,
> > Thanks for the proposal.
> >
> > I do not agree to the third point that RM should keep merging to master.
> We
> > could do that at the end of the release with a single
On 07-Aug-2014, at 11:23 am, Rajani Karuturi wrote:
> Hi Rohit,
> Thanks for the proposal.
>
> I do not agree to the third point that RM should keep merging to master. We
> could do that at the end of the release with a single merge.
By landing changes from release to master, we get continuous
Hi Rohit,
Thanks for the proposal.
I do not agree to the third point that RM should keep merging to master. We
could do that at the end of the release with a single merge.
That said, its definitely better than what we currently do and hence a +1
from me.
On Thu, Aug 7, 2014 at 2:09 PM, Rohit Y
Ah, an even smaller proposal then mine, good.
On Thu, Aug 7, 2014 at 10:39 AM, Rohit Yadav wrote:
> Hi,
>
> I think the following can solve the cherry-picking problem but it needs
> everyone’s support to work:
>
> - Once a release branch is cut out, all the committers and contributors
> “should
Hi,
I think the following can solve the cherry-picking problem but it needs
everyone’s support to work:
- Once a release branch is cut out, all the committers and contributors
“should” only work on the release branch. It can be discussed if we want to
work on it directly or branch out on it an
13 matches
Mail list logo
