We're about due for releases of Avatica and Calcite. Who's next up on
the release manager schedule?
hi Julian:
I think you have a good idea. In the Calcite community, people can
know who has made changes by browsing GitHub, the number of PR contributions
and the activity of the community.And People can know their contributions in
`https://github.com/apache/calcite/graphs/contributors`.
I
agree with you, +1
----
??:
"dev"
+1 for not requiring the contributor's name in the commit message and
having "The following people contributed to this release" in the release
notes.
On 24/09/2021 6:20 am, Alessandro Solimando wrote:
Nowadays Github allows you to fetch that info very easily, I think it's a
leftover from the
Nowadays Github allows you to fetch that info very easily, I think it's a
leftover from the past where the task proved to be harder.
On Thu, 23 Sept 2021 at 22:09, Jacques Nadeau wrote:
> I lead towards allowing people to use github if they want to know who
> contributed what. Simple is better.
I lead towards allowing people to use github if they want to know who
contributed what. Simple is better.
On Thu, Sep 23, 2021 at 11:25 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> I incline to "The following people contributed to this release"
> For instance, I like the way
I incline to "The following people contributed to this release"
For instance, I like the way Gradle release notes are written:
https://docs.gradle.org/7.2/release-notes.html
The trick is that the author name does not convey the URL, so either we use
just names or we keep a contributor database.
A separate but related question: should we give people credit for their
contributions in the release notes? We could append a contributor’s name to
each contribution (achieving a similar effect to today). Or we could generate a
“The following people contributed to this release: …” paragraph per
+1 One of the reasons it was there was to make generating the
changelog easier. However, this could be easily scripted to pull out
the contributors name if needed.
--
Michael Mior
mm...@apache.org
Le jeu. 23 sept. 2021 à 05:23, Stamatis Zampetakis a écrit :
>
> Hi all,
>
> Currently we are
+1
> On Sep 23, 2021, at 2:23 AM, Stamatis Zampetakis wrote:
>
> Hi all,
>
> Currently we are supposed to append the contributors name to the commit
> summary when they are not committers of the project. The main reason for
> doing this if I am not mistaken is to give some credit to those
Hi all,
Currently we are supposed to append the contributors name to the commit
summary when they are not committers of the project. The main reason for
doing this if I am not mistaken is to give some credit to those people.
I did like this practice in the beginning but I think it adds some
Alessandro Solimando created CALCITE-4796:
-
Summary: Travis links in README.md should point to 'travis-ci.com'
instead of ' travis-ci.org'
Key: CALCITE-4796
URL:
I also check sqlite and mssql 2017 and obtain the same results, but i also
found that standard has differ treatment:
9.3 Set operation result data types
Function
Specify the Syntax Rules and result data types for s and s having set operators.
... skip ...
i)
Julian Hyde created CALCITE-4795:
Summary: In class SqlBasicCall, make the "operands" field private.
Key: CALCITE-4795
URL: https://issues.apache.org/jira/browse/CALCITE-4795
Project: Calcite
xzh_dz created CALCITE-4794:
---
Summary: Arithmetic remainder operator should be simplified
Key: CALCITE-4794
URL: https://issues.apache.org/jira/browse/CALCITE-4794
Project: Calcite
Issue Type:
That looks like a bug. Cloning a SqlCall and then calling setOperand on it is
valid, and should not modify the original SqlCall.
We tend to avoid calling ’set’ methods on SqlNodes - we treat them as immutable
except that the validator will replace an argument with an equivalent argument
(e.g.
16 matches
Mail list logo
