calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@apache.org>
Subject Re: [VOTE] Release apache-calcite-1.2.0-incubating (release candidate 1)
Date Mon, 13 Apr 2015 04:18:02 GMT
Sounds good
On Apr 12, 2015 9:16 PM, "Julian Hyde" <jhyde@apache.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message