Thank you all those who responded.
One potential way we could speed up sussing out issues is running regular "Bug
Bashes" with the help of the user community. We could periodically post stats
and recognize folks who contribute the most issues. This would help gain
confidence in the builds we're
It is a good catch, Mick. :-)
I will triage those tickets to be sure that our view of things is accurate.
On Tue, Jun 30, 2020 at 11:38 AM Berenguer Blasi
wrote:
> That's a very good point. At the risk of saying sthg silly or being
> captain obvious, as I am not familiar with the project dynam
That's a very good point. At the risk of saying sthg silly or being
captain obvious, as I am not familiar with the project dynamics, there
should be a periodic 'backlog triage' or similar. Otherwise we'll have
the impression we have just a handful of pending issues while another
10x packet is hidin
That is a good finger in the air starting point imo. We'd have to adjust
the backing filter to reflect exactly what we want. But we have the data
and a graph report available already at hand which is good :-)
On 30/6/20 11:09, Benjamin Lerer wrote:
>> It would be nice to have a graph on our weekly
>
>
> Berenguer pointed out to me that we already have a graph to track those
> things:
>
>
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=weekly&daysprevious=30&cumulative=true&versionLabels=none&selectedProjectId=12310865&reportKey=com.at
>
> It would be nice to have a graph on our weekly status of the number of
> issues reported on 4.0. I feel like having a visual representation of the
> number of bugs on 4.0 over time would be really helpful to give us a
> feeling of the progress on its stability.
>
Berenguer pointed out to me th
Thanks a lot for starting this thread Dinesh.
As a baseline expectation, we thought big users of Cassandra should be
> running the latest trunk internally and testing it out for their particular
> use cases. We wanted them to file as many jiras as possible based on their
> experience. Operations s
