Thanks for stepping in Danny. Can I take your release ? On Mon, Feb 10, 2020 at 2:34 PM Julian Hyde <jh...@apache.org> wrote:
> It would be helpful for us to test third-party projects. > > But equally, it is useful for third-party projects to test against us. > (Especially non-open-source ones, which we cannot test.) I strongly suggest > that owners of those projects do a build and test against Calcite master > about 3 weeks before a Calcite release. It gives us chance to address any > regressions before the release. > > > In HerdDB we saw regressions too late and the code was no more compatible > > with Calcite master so we are still using a very old version of Calcite. > > I’ve seen that pattern often. It happened in Drill too, and they had to > make Herculean efforts to get back onto the latest release. It’s in no > one’s interests for dependent projects to slip behind. If the projects > raise issues in at the right time (about 2 weeks before a release) we > should endeavor to fix them. > > Julian > > > > > On Feb 9, 2020, at 6:13 AM, Enrico Olivelli <eolive...@gmail.com> wrote: > > > > Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <zabe...@gmail.com> ha > scritto: > > > >> Thanks for fixing the build Vladimir! > >> > >> I like the idea of testing against other projects on a weekly basis. It > >> will certainly help detect regressions early on. It might be a bit hard > to > >> maintain since there could be failures quite often but I guess we will > not > >> know till we try. > >> > >> Even before adding 3rd-party projects in the CI, I would say that is > worth > >> running our integration tests (Druid, Cassandra, Postgres, etc.) > > > > > > +1 > > > > I think that third party users should test their code against current > > Calcite master and report to this list all problems as soon as possible. > > > > In HerdDB we saw regressions too late and the code was no more compatible > > with Calcite master so we are still using a very old version of Calcite. > > > > We started to have a branch that builds and runs tests against Calcite > > master. > > Showstoppers in this process are when we break source/binary > compatibility > > in Calcite, so you have to maintain a separate branch, because you cannot > > depend on SNAPSHOT release and this is expected to happen at every > release. > > > > Having more frequent releases in Calcite would help a bit, but currently > it > > is not a big burden > > > > > > Enrico > > > > at a > >> regular basis by CI. I am checking them now and there seems to be again > >> failures. > >> > >> Best, > >> Stamatis > >> > >> > >> > >> On Sat, Feb 8, 2020 at 11:48 AM Vladimir Sitnikov < > >> sitnikov.vladi...@gmail.com> wrote: > >> > >>>> Are current -SNAPSHOT packages on repository.apache.org up to date ? > >>> > >>> The snapshots were not up to date because Calcite-Snapshots Jenkins job > >> was > >>> using beam Jenkins node somehow. > >>> I guess that was caused by misconfiguration of beam nodes. > >>> > >>> I've triggered the job manually, and it works now: > >>> https://builds.apache.org/job/Calcite-Snapshots/ > >>> On top of that, I've configured mails to dev@calcite list for the > >>> snapshots > >>> job so we'll know if it fails again. > >>> > >>>> I would like to test my projects in CI against current master > >>> > >>> I wonder if it makes sense to add GitHub Actions CI which would > validate > >>> third-party projects on a weekly basis. > >>> For instance, I have https://github.com/vlsi/mat-calcite-plugin , > which > >> is > >>> not that sophisticated, however, it would be nice to see > >>> if the upcoming Calcite version is going to break or not that client. > >>> > >>> For instance, Beam has quite interesting post-commit tests page: > >>> > https://github.com/apache/beam#post-commit-tests-status-on-master-branch > >>> > >>> WDYT? > >>> > >>> Vladimir > >>> > >> > >
