Re: Problem with LGTM on geode-native pull request
Hi, I updated the .lgtm.yml file so that the right version of Apache Geode is downloaded and now I get errors in the linking process about some symbols not found. Could anybody help with this? Thanks, Alberto On 30/7/19 15:50, Jacob Barrett wrote: > Yes, that seems to be the issue. Can you update the lgtm.yml and push to your > branch. > > Thanks, > Jake > > >> On Jul 30, 2019, at 5:09 AM, Alberto Gomez wrote: >> >> Hi, >> >> I am getting a failure on the C/C++ LGTM analysis over a recently >> created pull request on geode-native: >> https://github.com/apache/geode-native/pull/504 >> >> I have noticed that this it the first PR on geode-native having LGTM >> analysis. >> >> There is a .lgtm.yml on the repo that does not seem up to date as it >> references Apache 1.7.0. This could be the source of the problem. >> >> Any ideas? >> >> Thanks in advance, >> >> -Alberto G. >>
Re: Problem with LGTM on geode-native pull request
Linking errors look like (perhaps among other things) missing symbols for libcurl(?) needed by the Xerces library, which was recently added. We build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook Pros, but it appears LGTM is attempting to build on some other OS flavor and maybe missing some dependencies. I'll investigate this morning. Thanks, Blake On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez wrote: > Hi, > > I updated the .lgtm.yml file so that the right version of Apache Geode > is downloaded and now I get errors in the linking process about some > symbols not found. > > Could anybody help with this? > > Thanks, > > Alberto > > On 30/7/19 15:50, Jacob Barrett wrote: > > Yes, that seems to be the issue. Can you update the lgtm.yml and push to > your branch. > > > > Thanks, > > Jake > > > > > >> On Jul 30, 2019, at 5:09 AM, Alberto Gomez > wrote: > >> > >> Hi, > >> > >> I am getting a failure on the C/C++ LGTM analysis over a recently > >> created pull request on geode-native: > >> https://github.com/apache/geode-native/pull/504 > >> > >> I have noticed that this it the first PR on geode-native having LGTM > >> analysis. > >> > >> There is a .lgtm.yml on the repo that does not seem up to date as it > >> references Apache 1.7.0. This could be the source of the problem. > >> > >> Any ideas? > >> > >> Thanks in advance, > >> > >> -Alberto G. > >> >
Re: [DISCUSS] Time to cut Geode 1.10.0?
In preparation for cutting the release branch have we confirmed that Geode's LICENSE and NOTICE file been confirmed to accurately reflect what is being shipped for v1.10? >From Apache: http://www.apache.org/dev/licensing-howto.html *"*The LICENSE and NOTICE files must exactly represent the contents of the distribution they reside in." Ideally this is kept up to date during development as the dependencies change or are added but this often is missed and needs to be reconciled on develop before we cut a release branch. -Dick On Tue, Jul 30, 2019 at 6:04 PM Owen Nichols wrote: > From that email: > > To make this work, it's important to be strict > about cutting the release branch on the set date and only allow critical > fixes after the release has been cut. Once we start compromising on this, > we go down a slippery slope that ultimately leads to not getting the > predictability benefits described here. > > We are perilously close to the "slippery slope”: > * Geode 1.8.0 was announced on Dec 12 — almost 8 months ago > * Geode 1.9.0 was announced on Apr 25 — putting us about 5 weeks late > already on cutting the 1.10 branch > > It seems like the community reaction to branching from the SHA initially > proposed is “woah, not quite yet”. > > To get last-minute stuff in (or out) and get back on track, I propose > setting a strict CUT date for the 1.10 branch at 3PM PDT Thursday August 1. > > -Owen > > > > On Jul 30, 2019, at 5:31 PM, Alexander Murmann > wrote: > > > > Hi Karen, > > > > Here is the previous discussion that was very positively received: > > > https://lists.apache.org/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E > > > > However, JIRA tells me that GEODE-7013 is already fixed. If we were to go > > with a SHA from this week, for which Jake also chimed in with plenty of > > reasons, this should be in the release. > > > > On Tue, Jul 30, 2019 at 5:10 PM Karen Miller wrote: > > > >> Alexander, can you point me at the policy decision for the "critical > issue" > >> rule you mention? I always though it was up > >> to the release manager. > >> > >> I want GEODE-7013 fixes in because it is the right thing to do. Our > gfsh > >> help/hint wasn't working the way we say that it did. > >> With the fix, it does. I want either the documentation to match the > code, > >> or I want the code to match the documentation. > >> The fix in GEODE-7013 changes the code to match the existing > documentation, > >> so we don't have to change the documentation > >> (which would have needed to be cherry-picked into our 1.10 release > branch). > >> > >> > >> On Tue, Jul 30, 2019 at 11:47 AM Owen Nichols > wrote: > >> > >>> Our "critical issue” rule has the effect that the bar to commit to > >> develop > >>> is “low”, but the bar to cherry-pick to support branch is “very high”. > >>> > >>> Contributors could plan around this disparity more easily if any of the > >>> following were true: > >>> - releases were more frequent > >>> - planned cut date of release branch was announced in advance (rather > >> than > >>> retroactively) > >>> - a process existed for making exceptions to the “critical issue” rule > >>> > >>> I agree that the proposed SHA looks like a relatively stable > branchpoint > >>> (coming near the end of a nice period of solid green in the pipeline), > >> and > >>> I acknowledge that fair warning was given a week ago that a branch was > >>> “coming soon”, but I wonder if there is anything we can do to make the > >>> rules for what gets in a release and what doesn’t feel a little less > >>> arbitrary? > >>> > >>> -Owen > >>> > >>> > On Jul 30, 2019, at 11:16 AM, Alexander Murmann > >>> wrote: > > Dick, thank you for stepping up! > > I think it's great to cut the branch sooner rather than later. There > already is GEODE-7012 which introduces a distributed deadlock during > startup. That seems like a critical issue to fix. That should be able > >> to > happen after we cut the branch though. > > Karen, I wonder if that could be merged after the branch got cut, but > >>> also > wonder if that fits our "critical issue" rule for being merged after > >> the > branch has been cut or hold up the release. This has been broken since > >> a > very long time. Thoughts? > > On Tue, Jul 30, 2019 at 10:51 AM Karen Miller > >>> wrote: > > > I'd like to see the changes from > > https://issues.apache.org/jira/browse/GEODE-7013 included in the > >> Geode > > 1.10 > > release. GEODE-7013's changes restore gfsh help/hint behavior that > was > >>> lost > > during a refactor in the earliest > > releases of Geode. The commit occurred after SHA1 > > dc6890107a2651d8ba1450e8db8a1c39d712fdc7. > > Thanks. Karen > > > > > > On Tue, Jul 30, 2019 at 10:39 AM Dick Cavender > >>> wrote: > > > >> I'll take on the Release Manager role for Geode 1.10 with
Re: Problem with LGTM on geode-native pull request
Still looking into this, don’t expect to have a resolution today necessarily. I turned off network support in our build of Xerces, since we don’t use it, and that got rid of some, but not all, of the unresolved references. I’ll have to get hold of the LGTM Docker image to see what’s going on with the rest of the issues. I’m 100% convinced it’s not an issue with this PR, though - develop branch has the same problem. Thanks, Blake On Wed, Jul 31, 2019 at 7:08 AM Blake Bender wrote: > Linking errors look like (perhaps among other things) missing symbols for > libcurl(?) needed by the Xerces library, which was recently added. We > build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook > Pros, but it appears LGTM is attempting to build on some other OS flavor > and maybe missing some dependencies. I'll investigate this morning. > > Thanks, > > Blake > > > On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez > wrote: > >> Hi, >> >> I updated the .lgtm.yml file so that the right version of Apache Geode >> is downloaded and now I get errors in the linking process about some >> symbols not found. >> >> Could anybody help with this? >> >> Thanks, >> >> Alberto >> >> On 30/7/19 15:50, Jacob Barrett wrote: >> > Yes, that seems to be the issue. Can you update the lgtm.yml and push >> to your branch. >> > >> > Thanks, >> > Jake >> > >> > >> >> On Jul 30, 2019, at 5:09 AM, Alberto Gomez >> wrote: >> >> >> >> Hi, >> >> >> >> I am getting a failure on the C/C++ LGTM analysis over a recently >> >> created pull request on geode-native: >> >> https://github.com/apache/geode-native/pull/504 >> >> >> >> I have noticed that this it the first PR on geode-native having LGTM >> >> analysis. >> >> >> >> There is a .lgtm.yml on the repo that does not seem up to date as it >> >> references Apache 1.7.0. This could be the source of the problem. >> >> >> >> Any ideas? >> >> >> >> Thanks in advance, >> >> >> >> -Alberto G. >> >> >> >
Re: Problem with LGTM on geode-native pull request
I would say for this PR, back out the LGTM changes and just move forward ignoring the LGTM results. > On Jul 31, 2019, at 12:14 PM, Blake Bender wrote: > > Still looking into this, don’t expect to have a resolution today > necessarily. I turned off network support in our build of Xerces, since we > don’t use it, and that got rid of some, but not all, of the unresolved > references. I’ll have to get hold of the LGTM Docker image to see what’s > going on with the rest of the issues. I’m 100% convinced it’s not an issue > with this PR, though - develop branch has the same problem. > > Thanks, > > Blake > > > On Wed, Jul 31, 2019 at 7:08 AM Blake Bender wrote: > >> Linking errors look like (perhaps among other things) missing symbols for >> libcurl(?) needed by the Xerces library, which was recently added. We >> build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook >> Pros, but it appears LGTM is attempting to build on some other OS flavor >> and maybe missing some dependencies. I'll investigate this morning. >> >> Thanks, >> >> Blake >> >> >> On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez >> wrote: >> >>> Hi, >>> >>> I updated the .lgtm.yml file so that the right version of Apache Geode >>> is downloaded and now I get errors in the linking process about some >>> symbols not found. >>> >>> Could anybody help with this? >>> >>> Thanks, >>> >>> Alberto >>> >>> On 30/7/19 15:50, Jacob Barrett wrote: Yes, that seems to be the issue. Can you update the lgtm.yml and push >>> to your branch. Thanks, Jake > On Jul 30, 2019, at 5:09 AM, Alberto Gomez >>> wrote: > > Hi, > > I am getting a failure on the C/C++ LGTM analysis over a recently > created pull request on geode-native: > https://github.com/apache/geode-native/pull/504 > > I have noticed that this it the first PR on geode-native having LGTM > analysis. > > There is a .lgtm.yml on the repo that does not seem up to date as it > references Apache 1.7.0. This could be the source of the problem. > > Any ideas? > > Thanks in advance, > > -Alberto G. > >>> >>
