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 such as host replacement, expansions, shrinks, etc. > and obviously any issues with durability, performance, availability. This > was thought to generate a body of work (jiras), when fixed, over time would > stabilize trunk. When we see the trickle of new jiras coming to a halt or > at least nothing serious shows up, thats when the big users of Cassandra > would feel comfortable running the build in prod. This would be a good time > to cut the final stable release. >
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. It might also be interesting to see which components are the most affected to help us to determine where we should increase the testing. We also created a confluence doc for a test plan with major areas that > require testing. There were shepherds that were tentatively assigned[1]. > The rationale for this doc was that these areas have significantly changed > and we need more eye balls on it to ensure stability. The shepherds would > help guide the testing for these areas. I had a quick look at the JIRAs associated with the different areas of the plan and a lot of them appear to be blocked. I believe that most people are unsure of what or how to test things and want to get some feedback before starting to add tests. It would be great if in the coming weeks we can all help to unblock those tickets by clarifying what needs to be done on each of them. I guess that none of us have a clear picture but sharing ideas would definitely help. :-) The final concern was around some people felt that the lack of visible > activity signals that the project is dead. While I don't fully agree with > this assessment, I suspect sending a periodic update on new issues or test > runs that people are running to the mailing list would definitely help > keeping everyone engaged. It also helps bring visibility to the community. > I am not 100% sure whether it is feasible for everyone to share what > they're doing internally but I think if you're working on something, > summarizing on a weekly or biweekly basis can help the community. This is > just a thought and if there are other suggestions, lets discuss them > without shooting down new ideas (assume positive intent). > Your suggestion makes sense to me.Hopefully releasing 4.0-beta will also be a strong sign that the project is still active. On Mon, Jun 29, 2020 at 10:48 PM Dinesh Joshi <djo...@apache.org> wrote: > Hi all, > > I am starting a separate thread as the other thread has veered off in a > very different direction. The ground rules for this thread are that we are > not discussing branching models or release strategy here. > > Some folks in the community had the following questions and concerns: > > 1. Lack of clarity on how is stability and quality is being measured. > 2. Lack of visibility on the progress to stabilizing 4.0. > 3. Lack of clarity on what is remaining to get 4.0 to a stable state. > > My 2 cents on these 3 questions are as follows: > > 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 such as host replacement, expansions, shrinks, etc. > and obviously any issues with durability, performance, availability. This > was thought to generate a body of work (jiras), when fixed, over time would > stabilize trunk. When we see the trickle of new jiras coming to a halt or > at least nothing serious shows up, thats when the big users of Cassandra > would feel comfortable running the build in prod. This would be a good time > to cut the final stable release. > > We also created a confluence doc for a test plan with major areas that > require testing. There were shepherds that were tentatively assigned[1]. > The rationale for this doc was that these areas have significantly changed > and we need more eye balls on it to ensure stability. The shepherds would > help guide the testing for these areas. > > I think the big missing piece is that we don't know who is actively > running trunk internally and how aggressive their timelines are in getting > to a stable 4.0. However, we can see new jiras being reported every day. > There are also a lot of open jiras that require attention and they are > being reported by diverse set of Cassandra users which is great. I think > everyone would like to see a stable release in ~6 months from now. The > quality of this release will be dependent on how aggressively everyone in > the community tests the release in the coming weeks and months. > > The final concern was around some people felt that the lack of visible > activity signals that the project is dead. While I don't fully agree with > this assessment, I suspect sending a periodic update on new issues or test > runs that people are running to the mailing list would definitely help > keeping everyone engaged. It also helps bring visibility to the community. > I am not 100% sure whether it is feasible for everyone to share what > they're doing internally but I think if you're working on something, > summarizing on a weekly or biweekly basis can help the community. This is > just a thought and if there are other suggestions, lets discuss them > without shooting down new ideas (assume positive intent). > > Thanks, > > Dinesh > > [1] > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
