Sounds good On Apr 12, 2015 9:16 PM, "Julian Hyde" <[email protected]> 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 > <[email protected]> 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 >
