calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: [VOTE] Release apache-calcite-1.2.0-incubating (release candidate 1)
Date Mon, 13 Apr 2015 04:16:07 GMT
Jacques, you are correct; I prefer (b). Not that I like seeing a -1,
but the vote at least provides a time constraint.

The Apache voting process [
https://www.apache.org/foundation/voting.html ] says:

  Votes on whether a package is ready to be released use majority
  approval -- i.e. at least three PMC members must vote affirmatively
  for release, and there must be more positive than negative votes.
  Releases may not be vetoed.

This is markedly different from the consensus on which other kinds of
votes operate. My interpretation is that they want to encourage
progress over perfection, and avoid stalemate. We should of course
hear all voices, and should strive to achieve consensus.

I could have done a better job of reaching consensus during the vote.

Jacques, I agree with you, the release is borderline. Please, let's
release it and get to work on the next one.

Julian


On Sat, Apr 11, 2015 at 11:42 AM, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
> Regarding 'half of the world', I believe it is not the last time we are
> going to face the issue.
>
> I think it makes more sense to go ahead (release 1.2 as is), and start
> using CI to test such issues (e.g. to have CI runs in different time zones).
>
> Regarding 'releasing non-buildable' versions, I do not like that in
> general, however I think we never can give 100% guarantee, so it is fine to
> discuss/agree on the case by case basis.
>
> For instance, Calcite 1.2 uses identityHashCode as _unique_ identifiers of
> statements.
> Should I elaborate why that is inherently broken?
> Not sure if we should veto 1.2 due to the defect ('calcite executes wrong
> sql'), but that is clear example of 'never releasing due to fixes here and
> there'.
>
> Well, those kind of 'random' issues can be captured by durability testing.
> It would be nice to have a long running test (e.g. a couple of days) to
> test against memory leaks/random failures.
>
> Regards,
> Vladimir Sitnikov

Mime
View raw message