I'm happy to work on those reverts, although if Anthony could elaborate on where exactly the version information was missing, that assuage some of my own worries as to whether it's the right approach. It's still not clear to me where .buildinfo is intended to be consumed.
On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag <n...@apache.org> wrote: > Yes Alexander, we are still waiting on the build info reverts from Patrick, > so, I think that this can be put into release/1.7.0. > > Sure Jinmei, you can go ahead and merge the change into release/1.7.0 > branch too when you merge the PR. Please do close the fixed version in the > JIRA as 1.7.0 > > Regards > Nabarun Nag > > > On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann <amurm...@pivotal.io> > wrote: > > > 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 > > > > > > -- > Regards > Nabarun Nag >
