Re: Handling of HBase version specifics.
Yes and yes :) I think we should make a sweep and fix (or disable) all failing tests.Then absolutely let no further commit through that fails any test. Our Jenkins builds do seem to have a lot of environmental issues, too, though. As for the supported HBase versions. There's a line of course.I think we're down to HBase 2.x (master), HBase 1.5.x, HBase 1.4.x, and HBase 1.3.xHopefully Phoenix has no direct dependency on what specific version of HDFS that actual HBase instance is using. Even then it's four branches to maintain separately. We have the test load right now anyway, it's just spread over 4 branches. -- Lars On Sunday, May 19, 2019, 9:18:19 PM PDT, James Taylor wrote: I think it’s a good idea, but even before this you have to ask when a Jenkins build actually succeeded. How about solving that first? On Sun, May 19, 2019 at 1:34 PM Nick Dimiduk wrote: > I think this is generally a good idea for managing multiple target > runtimes. > > One question I have though: is it really necessary that we support so many > release branches and so many compile targets? What about the versions of > Hadoop underneath each of those versions of HBase? Are we committed to > running against ever version of HDFS that each of those HBase releases > support? The test load will be massive and the suite itself must be > rock-solid in order to run across so many permutations. I fear that’s an > unreasonable burden for an open source community. > > Thanks, > Nick > > On Sat, May 18, 2019 at 11:36 AM Thomas D'Silva > wrote: > > > +1, I think this is a good idea. This would make it easier to contribute > > and commit since you would only have to create a single patch. > > The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should > make > > sure our precommit build will run the tests for all the modules. > > > > > > > > On Fri, May 17, 2019 at 11:23 AM la...@apache.org > > wrote: > > > > > Hi all, > > > historically we have a branch of each version of HBase we want to > > > support.As a result we have many branches, committing is a hassle and > it > > is > > > easy to miss a change across branches. > > > Instead we could have a maven module per version of HBase we want to > > > support and move the version dependent code there.Take a look at what > > > Tephra is doing: https://github.com/apache/incubator-tephra > > > They have a compat module for each supported version of HBase, and > > version > > > dependent code is "simply" copied into those modules.There's still > > > duplicate code, but at least there's one branch to maintain. > > > It's somewhat of a bigger project now. > > > Thoughts? > > > -- Lars > > > > > >
Re: Handling of HBase version specifics.
I think it’s a good idea, but even before this you have to ask when a Jenkins build actually succeeded. How about solving that first? On Sun, May 19, 2019 at 1:34 PM Nick Dimiduk wrote: > I think this is generally a good idea for managing multiple target > runtimes. > > One question I have though: is it really necessary that we support so many > release branches and so many compile targets? What about the versions of > Hadoop underneath each of those versions of HBase? Are we committed to > running against ever version of HDFS that each of those HBase releases > support? The test load will be massive and the suite itself must be > rock-solid in order to run across so many permutations. I fear that’s an > unreasonable burden for an open source community. > > Thanks, > Nick > > On Sat, May 18, 2019 at 11:36 AM Thomas D'Silva > wrote: > > > +1, I think this is a good idea. This would make it easier to contribute > > and commit since you would only have to create a single patch. > > The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should > make > > sure our precommit build will run the tests for all the modules. > > > > > > > > On Fri, May 17, 2019 at 11:23 AM la...@apache.org > > wrote: > > > > > Hi all, > > > historically we have a branch of each version of HBase we want to > > > support.As a result we have many branches, committing is a hassle and > it > > is > > > easy to miss a change across branches. > > > Instead we could have a maven module per version of HBase we want to > > > support and move the version dependent code there.Take a look at what > > > Tephra is doing: https://github.com/apache/incubator-tephra > > > They have a compat module for each supported version of HBase, and > > version > > > dependent code is "simply" copied into those modules.There's still > > > duplicate code, but at least there's one branch to maintain. > > > It's somewhat of a bigger project now. > > > Thoughts? > > > -- Lars > > > > > >
Re: Handling of HBase version specifics.
I think this is generally a good idea for managing multiple target runtimes. One question I have though: is it really necessary that we support so many release branches and so many compile targets? What about the versions of Hadoop underneath each of those versions of HBase? Are we committed to running against ever version of HDFS that each of those HBase releases support? The test load will be massive and the suite itself must be rock-solid in order to run across so many permutations. I fear that’s an unreasonable burden for an open source community. Thanks, Nick On Sat, May 18, 2019 at 11:36 AM Thomas D'Silva wrote: > +1, I think this is a good idea. This would make it easier to contribute > and commit since you would only have to create a single patch. > The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should make > sure our precommit build will run the tests for all the modules. > > > > On Fri, May 17, 2019 at 11:23 AM la...@apache.org > wrote: > > > Hi all, > > historically we have a branch of each version of HBase we want to > > support.As a result we have many branches, committing is a hassle and it > is > > easy to miss a change across branches. > > Instead we could have a maven module per version of HBase we want to > > support and move the version dependent code there.Take a look at what > > Tephra is doing: https://github.com/apache/incubator-tephra > > They have a compat module for each supported version of HBase, and > version > > dependent code is "simply" copied into those modules.There's still > > duplicate code, but at least there's one branch to maintain. > > It's somewhat of a bigger project now. > > Thoughts? > > -- Lars > > >
Re: Handling of HBase version specifics.
+1, I think this is a good idea. This would make it easier to contribute and commit since you would only have to create a single patch. The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should make sure our precommit build will run the tests for all the modules. On Fri, May 17, 2019 at 11:23 AM la...@apache.org wrote: > Hi all, > historically we have a branch of each version of HBase we want to > support.As a result we have many branches, committing is a hassle and it is > easy to miss a change across branches. > Instead we could have a maven module per version of HBase we want to > support and move the version dependent code there.Take a look at what > Tephra is doing: https://github.com/apache/incubator-tephra > They have a compat module for each supported version of HBase, and version > dependent code is "simply" copied into those modules.There's still > duplicate code, but at least there's one branch to maintain. > It's somewhat of a bigger project now. > Thoughts? > -- Lars >
