Re: [VOTE] Release apache-calcite-avatica-go-5.0.0 (release candidate 0)
Hey everyone, Just a quick reminder that the vote for Avatica Go 5.0.0 is still open. Francis On 23/06/2020 1:30 pm, Francis Chuang wrote: Hi all, I have created a release for Apache Calcite Avatica Go 5.0.0, release candidate 0. Thanks to everyone who has contributed to this release. The release notes are available here: https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/_docs/go_history.md The commit to be voted on: https://gitbox.apache.org/repos/asf?p=calcite-avatica-go.git;a=commit;h=0e3f5df582a09ac90869611b2d0a64b9f9b566e2 The hash is 0e3f5df582a09ac90869611b2d0a64b9f9b566e2 The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-go-5.0.0-rc0/ The hashes of the artifacts are as follows: src.tar.gz C49DB10E 5CC08815 2EEFFC83 7DD339DF 3327125E DCBA5DA3 9C9E74E1 F277D554 34DBE407 5436849A A4124661 4527A769 80EA7334 8ABDB2FE 56AA5B20 4FDFA43D Release artifacts are signed with the following key: https://people.apache.org/keys/committer/francischuang.asc Instructions for running the test suite is located here: https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/develop/avatica-go.md#testing Please vote on releasing this package as Apache Calcite Avatica Go 5.0.0. To run the tests without a Go environment, install docker and docker-compose. Then, in the root of the release's directory, run: docker-compose run test When the test suite completes, run "docker-compose down" to remove and shutdown all the containers. The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite Avatica Go 5.0.0 [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Here is my vote: +1 (binding) Francis
Calcite-Master - Build # 1812 - Failure
The Apache Jenkins build system has built Calcite-Master (build #1812) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1812/ to view the results.
Re: [VOTE] Release apache-calcite-avatica-go-5.0.0 (release candidate 0)
Docker version 19.03.11, docker-compose version 1.25.5, build 8a1c60f6 * Checked signatures and checksums OK * Went over release note (Nice to see new contributors) OK * Checkout from git tag and run tests (docker-compose run test) OK * Download source artifacts and run tests (docker-compose run test) OK * Checked diff between repo and artifacts OK +1 (binding) Best, Stamatis On Sun, Jun 28, 2020 at 10:38 AM Francis Chuang wrote: > Hey everyone, > > Just a quick reminder that the vote for Avatica Go 5.0.0 is still open. > > Francis > > On 23/06/2020 1:30 pm, Francis Chuang wrote: > > Hi all, > > > > I have created a release for Apache Calcite Avatica Go 5.0.0, release > > candidate 0. > > > > Thanks to everyone who has contributed to this release. The release > > notes are available here: > > > https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/_docs/go_history.md > > > > > > The commit to be voted on: > > > https://gitbox.apache.org/repos/asf?p=calcite-avatica-go.git;a=commit;h=0e3f5df582a09ac90869611b2d0a64b9f9b566e2 > > > > > > The hash is 0e3f5df582a09ac90869611b2d0a64b9f9b566e2 > > > > The artifacts to be voted on are located here: > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-go-5.0.0-rc0/ > > > > > > The hashes of the artifacts are as follows: > > src.tar.gz C49DB10E 5CC08815 2EEFFC83 7DD339DF 3327125E DCBA5DA3 > > 9C9E74E1 F277D554 34DBE407 5436849A A4124661 4527A769 80EA7334 8ABDB2FE > > 56AA5B20 4FDFA43D > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/francischuang.asc > > > > Instructions for running the test suite is located here: > > > https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/develop/avatica-go.md#testing > > > > > > Please vote on releasing this package as Apache Calcite Avatica Go 5.0.0. > > > > To run the tests without a Go environment, install docker and > > docker-compose. Then, in the root of the release's directory, run: > > docker-compose run test > > > > When the test suite completes, run "docker-compose down" to remove and > > shutdown all the containers. > > > > The vote is open for the next 72 hours and passes if a majority of at > > least three +1 PMC votes are cast. > > > > [ ] +1 Release this package as Apache Calcite Avatica Go 5.0.0 > > [ ] 0 I don't feel strongly about it, but I'm okay with the release > > [ ] -1 Do not release this package because... > > > > > > Here is my vote: > > > > +1 (binding) > > > > Francis >
Calcite-Master - Build # 1813 - Still Failing
The Apache Jenkins build system has built Calcite-Master (build #1813) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1813/ to view the results.
Re: Re: [DISCUSS] Refactor how planner rules are parameterized
Indeed nice explanation Julian, thanks!
Regarding the transition one thing that might help is to try to put the new
model in a small release without other breaking changes.
We could get 1.24 out without the refactoring and soon afterwards release
1.25.
Given that the community has been rather silent on this I guess that people
don't really mind if it goes as is in the next release so I may be over
complicating things for no reason.
In the end, we have also committed features with bigger impact with no
special treatment.
Best,
Stamatis
On Fri, Jun 19, 2020 at 11:37 PM Haisheng Yuan wrote:
> Thank you for the detailed explanation, Julian.
>
> I will step aside, let you and other community members decide.
> Anyway, my comment is not blocking.
>
> Thanks,
> Haisheng
>
> On 2020/06/17 23:12:40, Julian Hyde wrote:
> > "I prefer the KISS principle" is a bit unfair. What I'm advocating is
> > also simple. But maybe from a different perspective.
> >
> > I am looking at it from the perspective of people who use rules, and
> > compose them into rule sets to perform particular optimizations. I
> > believe this is the most important perspective to focus on. These
> > people are the key audience to serve. The corpus of re-usable,
> > composable rules may be Calcite's most important contribution.
> >
> > To these people, a rule is not a class but an object. It has a
> > particular signature (in terms of the pattern of RelNodes that it
> > matches), maybe one or two configuration parameters (e.g.
> > FilterJoinRule.smart controls whether to automatically strengthen a
> > LEFT join to INNER), and it has code to generate a new RelNode when
> > matched.
> >
> > What do I mean by 'object'? Think of how you use regular expressions
> > in Java. You call java.util.regex.Pattern.compile("a[bc]*") and it
> > gives you a Pattern object. You do not know what fields are inside
> > that Pattern, you do not care whether the object you receive is a
> > Pattern or some sub-class of Pattern, but you know there are one or
> > two methods such as 'matcher(CharSequence)' that you can call.
> >
> > Our current API treats planner rules as classes. If you want to
> > customize a property of a rule (say make a FilterJoinRule with
> > smart=false, or change its RelBuilder, or make it match a
> > CassandraFilter rather than a LogicalFilter) then you have to make a
> > new rule instance by calling the constructor.
> >
> > When you call the constructor, you have to supply ALL of the
> > properties, including operands, and including properties that you
> > don't know or care about. If someone in three months adds a new
> > property, the signature of the constructor will change, and you will
> > have to go back and change your code. This is broken.
> >
> > Haisheng asked for evidence that the current system is broken.
> > https://issues.apache.org/jira/browse/CALCITE-3825 ("Split
> > AbstractMaterializedViewRule into multiple classes") is one example.
> > In my company, that change literally broke our code because we had
> > changed properties of some rules.
> >
> > Another example is https://issues.apache.org/jira/browse/CALCITE-3975
> > ("Add options to ProjectFilterTransposeRule to push down project and
> > filter expressions whole, not just field references"). With that
> > change, I broke my own code. I added two new arguments, 'boolean
> > wholeProject, boolean wholeFilter' to ProjectFilterTransposeRule's
> > constructor, deprecated the previous constructor, and created quite a
> > few conflicts in another dev branch that I was working on.
> >
> > These kinds of problems are not uncommon. Because it is difficult to
> > reconfigure rules, or evolve them by adding extra arguments, people
> > are more likely to copy-paste rule code into their own projects, and
> > less like to contribute back.
> >
> > In most rules, operands are created evaluating a complex expression -
> > made up of calls to static methods such as RelOptRule.operand - in a
> > constructor as an argument to the base class constructor. This is a
> > code smell. Such code is hard to move elsewhere.
> >
> > We treat operands as immutable, but actually they are mutable. Every
> > operand contains mutable fields 'solveOrder', 'ordinalInParent' and
> > 'ordinalInRule' that are assigned in the RelOptRule constructor. We
> > don't prevent you from passing the same operand to two different rule
> > instances, but if you did, bad things would happen. Actually I think
> > people would love to be able to say 'create a rule instance the same
> > as this, but replacing LogicalFilter with CassandraFilter' but we
> > don't make it easy, and copying operands from one rule to another is
> > certainly the wrong way to achieve it.
> >
> > Given all of these problems, the solution was to convert rules into
> > data objects. Those data objects are the new Config interface and its
> > sub-interfaces. (I used an interface because the ImmutableBeans
> > framework makes it easy to create immutable
