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 <ndimi...@gmail.com> 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 > <tdsi...@salesforce.com.invalid> 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 <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 > > > > > >
