Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Dinesh Joshi
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

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Benjamin Lerer
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

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Berenguer Blasi
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

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Berenguer Blasi
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

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Mick Semb Wever
> > > Berenguer pointed out to me that we already have a graph to track those > things: > > >

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Benjamin Lerer
> > 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

Re: [DISCUSS] Stabilizing 4.0

2020-06-30 Thread Benjamin Lerer
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