ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: [VOTE] Apache Ignite 1.5.0-EA
Date Tue, 01 Dec 2015 00:56:10 GMT
On Mon, Nov 30, 2015 at 3:45 PM, Raul Kripalani <raulk@apache.org> wrote:

> On Mon, Nov 30, 2015 at 11:25 PM, Andrey Kornev <andrewkornev@hotmail.com>
> wrote:
> > And since you've asked for opinions, it's also my opinion that the
> > discussion about the naming was a non-consequential bikeshedding (
> > https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality) and
> > potentially causing unnecessary delays of the release which is already
> long
> > overdue.
> >
> I respect your opinion, obviously. But something being late is not an
> excuse for taking liberties with something so important and prominent as
> release naming policy and the lifetime of temporary binaries in external
> and public repositories. Those are the meeting points between our
> development process and the software discovery process by prospective
> users.

Raul, this is not the 1st Ignite release. Why don’t we follow our existing
procedures until we make and document new decisions? Judging by the way
this discussion is going, it could take a week for the community to reach a
consensus, which is hardly a reason to delay the release altogether.

I agree with you about the importance of release naming and the lifetime of
temporary binaries, but I suggest we start a new thread where we can
discuss these issues.

> Discussing names of private variables or an extra parenthesis in docs...
> Those are actual "bikeshedding". So in a way, I agree with you: we must
> focus on what's important.

You and I disagree here. Code consistency is hardly “bikeshedding”, and the
community is making an effort to enforce it. We should not fight it, but
rather embrace it, and make Ignite code clearly stand out among other
Apache projects. Having said that, I would be against holding back a
release because some variable was named wrong.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message