Ahhh. Thank you Alexander. That makes sense. I agree with you, as I mentioned in an earlier email *I agree with the cutting the release branch, keep it sanitized from additional commits going into develop but ensure only these important critical fixes mentioned above in this chain makes it into the release branch.*
Regards Naba On Thu, Feb 14, 2019 at 1:42 PM Alexander Murmann <ajmurm...@gmail.com> wrote: > Naba, I agree that we should fix these before releasing. I was talking > about the trade offs between fixing on develop and then branch or branching > first and then fixing on develop and release branch. > > On Thu, Feb 14, 2019 at 1:18 PM Nabarun Nag <n...@pivotal.io> wrote: > > > I agree but not putting in these fixes means that we are releasing with > > serious known issues in the product. Hence in my opinion this risk is > > acceptable. > > > > Regards > > Naba > > > > On Thu, Feb 14, 2019 at 12:34 PM Alexander Murmann <amurm...@apache.org> > > wrote: > > > > > > > > > > For the second part, I am not sure how it was determined that fixes > for > > > > GEODE-6391, GEODE-6393, GEODE-6369, GEODE-6404 contains risk of > > > introducing > > > > more failures. Are we lacking tests , reviews etc. I apologize but I > > was > > > > not able to understand. > > > > > > > Not sure if you were responding to me. My concern wasn't that these > fixes > > > introduce a regression, but that other changes happening on develop > might > > > introduce new issues. > > > > > > That said, every change always carries some amount of risk to > introduce a > > > new issue on any codebase, Even 100% test coverage can only make it a > lot > > > less likely, but not remove the risk entirely. > > > > > > On Thu, Feb 14, 2019 at 12:00 PM Nabarun Nag <n...@pivotal.io> wrote: > > > > > > > I could not find any DISCUSS mails about not blocking a release. I > may > > be > > > > wrong, I apologize for that but could point me to the mail / > > > documentation > > > > about the release management. > > > > > > > > Regards > > > > Naba > > > > > > > > On Thu, Feb 14, 2019 at 11:52 AM Sai Boorlagadda < > > > > sai.boorlaga...@gmail.com> > > > > wrote: > > > > > > > > > Did we not agreed that we won't be blocking a release to include > > fixes > > > as > > > > > we are in a fixed release schedule? > > > > > > > > > > > > > > > On Thu, Feb 14, 2019 at 11:36 AM Alexander Murmann < > > > amurm...@apache.org> > > > > > wrote: > > > > > > > > > > > Usually I am a proponent of cutting a branch and then fixing > things > > > on > > > > > > there where things are more stable. In this case we seem to have > a > > > > large > > > > > > number of fairly serious concerns. Do we think the cost of > putting > > > this > > > > > > many fixes on develop + the release branch out-weights the > benefit > > of > > > > > less > > > > > > risk of new issues being introduced? > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thank you, Sai for taking over! > > > > > > > > > > > > On Thu, Feb 14, 2019 at 10:32 AM Sai Boorlagadda < > > > > > > sai.boorlaga...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > I volunteer to be the release manager for 1.9. > > > > > > > > > > > > > > Sai > > > > > > > > > > > > > > On Wed, Feb 13, 2019 at 7:48 PM Alexander Murmann < > > > > amurm...@apache.org > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > If there are no other takers, I can act as release manager > for > > > 1.9 > > > > > and > > > > > > > will > > > > > > > > cut a release branch this week. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann < > > > > > amurm...@apache.org > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi everyone! > > > > > > > > > > > > > > > > > > February 1st is approaching rapidly which means it's almost > > > time > > > > to > > > > > > cut > > > > > > > > > the 1.9 release. Who is interested in being the release > > manager > > > > for > > > > > > > 1.9? > > > > > > > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Alexander J. Murmann > (650) 283-1933 >
