I still don't see why doing another release is harmful.
People would have one more option of trying 0.14.2 immediately instead of
waiting for 0.15.0.
Why would we make them to wait for 0.15.0?
Also, we don't have to release for every bug fix, but we should do for
regression bugs.
This is a regress
@Jihoon,
As i said if you are a cluster operator and you have a long running
critical service why would you not wait couple of week, IMO this is not a
very critical bug and i don't think it is sustainable to do a release on
every bug.
The question how many cluster this issue is really affecting? an
Previous message sent from wrong email, please ignore.
+1 (binding)
src:
- verified hash and signature
- checked LICENSE, NOTICE, DISCLAIMER
- ran unit tests and compiled binary distribution
- ran RAT check
- ran integration tests
- ran all of the quickstart ingestion tutorials from the compiled
+1 (binding)
src:
- verified hash and signature
- checked LICENSE, NOTICE, DISCLAIMER
- ran unit tests and compiled binary distribution
- ran RAT check
- ran integration tests
- ran all of the quickstart ingestion tutorials from the compiled binary
bin:
- verified hash and signature
- checked LIC
+1
src package:
- verified signature/hash
- LICENSE, NOTICE, and DISCLAIMER are present
- unit tests passed
- RAT check passed
- built binary distribution
- ran quickstart tutorials: kafka indexing service and batch index task
bin package:
- verified signature/hash
- LICENSE, NOTICE, and DISCLAIM
Is anyone going to the Apache Roadshow in Chicago tomorrow? I'll be around
if anyone wants to meet up.
I don't think having releases to fix critical bugs has any negative impact
whatsoever on community. If anything, it shows we are willing to fix issues
as fast as possible. Also, we should strive to get new releases out as soon
as possible, there are great features and improvements coming in every
r
Slim, would you please elaborate more about your concern?
The bug mentioned above is pretty serious. People might choose one of
versions between 0.14.0 and 0.14.1 depending on what type of DataSketch
they want to use. Theta sketch is not much useful in 0.14.1 while quantiles
sketch has a problem i
A quote from Steve Tockey regarding documentation and comments and the cost
of maintaining software:
https://medium.com/@leventov/steve-tockey-on-software-documentation-and-comments-470751227a63
On Mon, 29 Apr 2019 at 19:30, Fangjin Yang wrote:
> Strong +1 agreement with Gian. I definitely see t
0 for me
We have just released 0.14.0 and 0.14.1 and soon will be releasing 0.15.0,
This release is effectively one bug fix that concerns one extension.
IMO this is a read flag of unstable release that can hurt the project
overall, we need to keep in mind that Druid is not a library but it is a
Di
Please use Throwables.getRootCause() as a robust way to get
e.getCause().getCause()... until null is encountered. I think this is
especially true in REST, where we should say
serverError().entity(ImmutableMap.of("error", Throwables.getRootCause(e)))
To provide the caller with the actual reason of
11 matches
Mail list logo
