While there is a workaround this looks like a highly visible bug with a fairly safe fix. I am in favor of merging, since the branch is still distressed anyways.
Other opinions? On Wed, Sep 12, 2018 at 2:29 PM, Jinmei Liao <jil...@pivotal.io> wrote: > Should we include the fix for GEODE-5727 in the 1.7 release as well? > > Without the fix, the command "export cluster-config --zip-file-name=x.zip" > would fail with NPE, user has to use "export cluster-config > --zip-file-name=./x.zip" in order for export to work. > > PR for this fix is ready and could be merged soon. > > Jinmei > > > On Wed, Sep 12, 2018 at 11:12 AM Patrick Rhomberg <prhomb...@apache.org> > wrote: > > > I'm not sure PR 2457 will help with an ignored .buildinfo, but I'm not > sure > > as to why .buildinfo would be getting ignored by anything, either. > > > > PR 2457 deals with the still-needs-to-be-renamed > GemFireVersion.properties > > file and when it is generated. Previously, it was whenever the git index > > changed, which was too frequent. Not it is whenever the source > parameters > > are passed on the command-line with the build, which has presented issues > > outside the Concourse pipeline. PR 2457 splits the difference, > > regenerating the file anytime the SHA changes. > > > > The only interaction with .buildinfo that I can see is that if the build > > was run on a machine that was missing git, it would attempt to read > values > > instead from .buildinfo when creating the GemFireVersion.properties file. > > > > I guess I don't fully understand the problem Anthony has called out. > Where > > is it exactly that information previously gathered from .buildinfo is now > > missing? And are we certain that it was indeed pulling from .buildinfo > and > > not the aforementioned GemFireVersion.properties? > > > > On Wed, Sep 12, 2018 at 10:11 AM, Alexander Murmann <amurm...@pivotal.io > > > > wrote: > > > > > Hi everyone, > > > > > > It seems like that PR doesn't address the missing SHA issue either and > I > > am > > > not aware of any proposals to properly fix this. How viable is it to > > revert > > > the relevant Gradle build changes on support/1.7? > > > We could continue make the new Gradle approach work with our release > > > process on develop and hopefully release 1.8 with these changes. > > > > > > Are there any other proposals to unblock this? > > > > > > On Tue, Sep 11, 2018 at 5:41 PM, Anthony Baker <aba...@pivotal.io> > > wrote: > > > > > > > Slight clarification—the issue I mentioned is when a user builds > Geode > > > > from the source distribution. The source distribution that the > release > > > > manager creates has the correct .buildinfo file, it’s just ignored by > > the > > > > build. In short, the release manager can’t work around the problem. > > > > > > > > Does [1] help with this? > > > > > > > > Anthony > > > > > > > > [1] https://github.com/apache/geode/pull/2457 < > > > https://github.com/apache/ > > > > geode/pull/2457> > > > > > > > > > > > > > On Sep 11, 2018, at 3:16 PM, Alexander Murmann < > amurm...@pivotal.io> > > > > wrote: > > > > > > > > > > What's the consensus on the version info issue Anthony is calling > > out? > > > > Does > > > > > anyone have a proposal for fixing this for this release? Should > > Nabarun > > > > as > > > > > the release manager manually correct this for the release and we > > find a > > > > > permanent solution for 1.8? > > > > > > > > > > On Mon, Sep 10, 2018 at 12:33 PM, Anthony Baker <aba...@pivotal.io > > > > > > wrote: > > > > > > > > > >> Unfortunately it would require a fix to the build—it’s not about > > > > producing > > > > >> the release candidate. It’s when a user builds from the source > > release > > > > that > > > > >> the version info is ignored. > > > > >> > > > > >> Anthony > > > > >> > > > > >>> On Sep 10, 2018, at 10:02 AM, Nabarun Nag <n...@apache.org> > wrote: > > > > >>> > > > > >>> Hello Anthony, > > > > >>> > > > > >>> I plan to do that while creating the release candidate. If there > > are > > > no > > > > >>> concerns raised on the release branch, I will start with the > > process > > > > >> soon. > > > > >>> > > > > >>> Regards > > > > >>> Nabarun Nag > > > > >>> > > > > >>>> On Mon, Sep 10, 2018 at 8:51 AM Anthony Baker < > aba...@pivotal.io> > > > > >> wrote: > > > > >>>> > > > > >>>> Looks good Naba! Only thing I see right now is that building > from > > > the > > > > >>>> source distribution does not use the .buildinfo file, leaving > the > > > > >> version > > > > >>>> string empty. > > > > >>>> > > > > >>>> Anthony > > > > >>>> > > > > >>>> > > > > >>>>> On Sep 7, 2018, at 9:15 AM, Nabarun Nag <n...@apache.org> > wrote: > > > > >>>>> > > > > >>>>> CORRECTION: if '*no*' concerns are raised, we will start with > the > > > > >> voting > > > > >>>>> for the release candidate soon. > > > > >>>>> > > > > >>>>> Regrads > > > > >>>>> Nabarun Nag > > > > >>>>> > > > > >>>>>> On Fri, Sep 7, 2018 at 9:08 AM Nabarun Nag <n...@pivotal.io> > > > wrote: > > > > >>>>>> > > > > >>>>>> Hello Geode Dev Community, > > > > >>>>>> > > > > >>>>>> We have created a new release branch for Apache Geode 1.7.0 - > > > > >>>>>> "release/1.7.0" > > > > >>>>>> > > > > >>>>>> Previous branch was deleted and has been replaced with a fresh > > > one. > > > > >>>>>> > > > > >>>>>> Please do review and raise any concern with the release > branch. > > > > >>>>>> > > > > >>>>>> If concerns are raised, we will start with the voting for the > > > > release > > > > >>>>>> candidate soon. > > > > >>>>>> > > > > >>>>>> Regards > > > > >>>>>> Nabarun Nag > > > > >>>>>> > > > > >>>> > > > > >>>> -- > > > > >>> Regards > > > > >>> Nabarun Nag > > > > >> > > > > > > > > > > > > > > > > -- > Cheers > > Jinmei >