+1 to pushing to the branch. We can revisit a patch release if there are critical bugs.
On Tue, May 22, 2018 at 1:51 PM, Anirudh <anirudh2...@gmail.com> wrote: > I think pushing the fixes back to the release branch should be sufficient. > I am not sure why we need to maintain a different patches branch. I agree > that if there are a bunch of important fixes that didn't go into the > release, then we need to do a patch release for the same. > > On Tue, May 22, 2018 at 1:44 PM, sandeep krishnamurthy < > sandeep.krishn...@gmail.com> wrote: > > > 1.2.1 patch release with this bug fix (+ others if applicable) will be > very > > useful for the users. > > > > On Tue, May 22, 2018 at 1:08 PM, Rahul Huilgol <rahulhuil...@gmail.com> > > wrote: > > > > > Maybe we could do that now, after the code for the release has been > voted > > > on. We could maintain a patches branch for a release. This would also > be > > > helpful for users who are using a particular release version but > hesitate > > > to switch to the latest release when it's out because of the many > > changes. > > > Such users I've seen maintain their own patches branch. We could help > > them > > > and keep things consistent. We can cut a patch release from that if we > > have > > > many fixes or important fixes. > > > > > > On Thu, May 17, 2018 at 10:05 PM, Anirudh <anirudh2...@gmail.com> > wrote: > > > > > > > Thats an interesting suggestion. I understand the benefits, but this > > will > > > > complicate things if we want to do another quick release like the > > > previous > > > > one (for eg. if there is a license issue because of which the release > > is > > > > cancelled). > > > > > > > > Anirudh > > > > > > > > On Thu, May 17, 2018 at 9:23 PM, Naveen Swamy <mnnav...@gmail.com> > > > wrote: > > > > > > > > > why don't we cherry-pick and push it to the branch as well ? next > > time > > > a > > > > > release is cut from that branch we'll have everything working. > > > > > > > > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh <anirudh2...@gmail.com> > > > wrote: > > > > > > > > > > > Correction : This fix went into master but not 1.2 release. > > > > > > > > > > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh <anirudh2...@gmail.com> > > > > wrote: > > > > > > > > > > > > > Hi Xinyu, > > > > > > > > > > > > > > Thank you! This fix didnt went into master but not 1.2 release. > > > > > > > > > > > > > > Anirudh > > > > > > > > > > > > > > On Thu, May 17, 2018 at 5:23 PM, Chen, Xinyu1 < > > > xinyu1.c...@intel.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi all, > > > > > > >> > > > > > > >> Regarding to the following knowing issues listed below RC3: > > > > > > >> > > > > > > >> > > > > > > >> * CMake build ignores the USE_MKLDNN flag and doesn't > build > > > with > > > > > > >> MKLDNN support even with -DUSE_MKLDNN=1. To workaround the > issue > > > > > please > > > > > > >> see: #10801<https://github.com/apache/incubator-mxnet/issues/ > > > 10801 > > > > >. > > > > > > >> I think this problem has already been fixed in #10629< > > > > > > >> https://github.com/apache/incubator-mxnet/pull/10629> and we > > can > > > > use > > > > > > >> CMake to build MXNet with MKLDNN support on WIN32 platform > now. > > > > > > >> Xinyu > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Rahul Huilgol > > > > > > > > > > > -- > > Sandeep Krishnamurthy > > >
