Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Thanks for the detailed context Patrick! I see a lot of value on videoconferences for presentations and brainstorms but I tend to prefer mailing list as a medium for consensus-seeking discussions for the following reasons: - Asynchronous - gives folk time to think and digest (as mentioned by Ben on the Kubernetes thread); - Timezones - allows people from all timezones to participate; - Inclusivity - accommodates more people in the discussion. Regarding the proposed agenda of going through the unassigned issues to improve visibility on what needs to be done to ship 4.0 GA I think this is a great start but only covers part of the problem. I think we have 3 outstanding issues that are hampering visibility of 4.0 progress: a) Quality testing issues with no shepherd; b) Quality testing issues with shepherd, but no recent activity (~2 months or less); c) Quality testing issues with no objective acceptance criteria/Definition of Done; In order to facilitate the discussion I classified on this spreadsheet [1] the quality epic (CASSANDRA-15536) subtickets into two categories: ON TRACK / NEEDS ATTENTION. An issue "Needs Attention" if it has one of the 3 problems mentioned above and is "On Track" otherwise. ## ON TRACK: CASSANDRA-15583 4.0 quality testing: Tooling, Bundled and First Party CASSANDRA-15584 4.0 quality testing: Tooling - External Ecosystem CASSANDRA-15977 4.0 quality testing: Read Repair ## NEEDS ATTENTION: CASSANDRA-14746 Ensure Netty Internode Messaging Refactor is Solid CASSANDRA-15537 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test CASSANDRA-15538 4.0 quality testing: Local Read/Write Path: Other Areas CASSANDRA-15579 "4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair" CASSANDRA-15580 4.0 quality testing: Repair CASSANDRA-15581 4.0 quality testing: Compaction CASSANDRA-15582 4.0 quality testing: metrics CASSANDRA-15585 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance CASSANDRA-15587 4.0 quality testing: Platforms and Runtimes CASSANDRA-15588 4.0 quality testing: Cluster Upgrade CASSANDRA-15921 4.0 quality testing: Materialized View So in order to address these I think we should: a) Seek volunteers to shepherd unassigned items; b) Update status of inactive tickets; c) Define objective acceptance criteria for each quality issue; I believe we should do A) by actively seeking via mailing list volunteers for each unassigned quality issue, while B) and C) should be coordinated independently by the shepherd of each issue. In my view this should improve accountability and transparency into 4.0 GA progress. I would love to hear the community's thoughts on this. [1]: https://docs.google.com/spreadsheets/d/1E70HIo63KXP4ggLUCRYfuLLh_oJZNLuyuPdkiT6dMVE Em sex., 25 de set. de 2020 às 14:08, Patrick McFadin escreveu: > Hi Paulo, > > I appreciate you bringing this up because I'm sure that means plenty are > thinking the same thing. Let me give you a little context and history. > > Last ApacheCon I proposed setting up a periodic zoom call to emulate some > of the high bandwidth discussions that happen in-person. There was a good > deal of discussion about how to do this appropriately, specifically by not > creating isolated pockets of decision making. By providing yet another > interaction method, increase participation in the project. I have seen > these types of meetings work well in other OSS projects I'm involved with > but it needs to be right for ASF guidelines. > >- No final decisions are made during the call. Any proposals go to the >mailing list >- Make a recording and post so nothing is exclusive >- Post the chat transcripts (This is where the introverts interact and >it can be quite lively) > > I consider our Zoom call as part of a package of how we interact. > Jira - Code/feature specific discussion > Mailing List - Official record of discussions and decisions > Slack - Fast discussions with searchable text > Video Call - High bandwidth discussions and presentations. Transactional in > nature with an agenda. > > Having 25 people on a call to make a decision is not the intent or even > reasonable. No matter what the setting is, even on email we don't get that > many people weighing in on a topic. > > Using this meeting I posted as an example, the agenda is a discussion > focused on the three unassigned Jiras. I expect we will have a few people > that can directly speak about them and everyone else is a spectator or > commenting in chat. The intent is to drive some activity on Jira. > > The timezone thing bothers me more than anything. I can't figure out how to > make it completely equitable. The proposal as we formed the contributor > meetings was to rotate the time to accommodate European timezones to > Australia. The Kubernetes SIG had tried the 2 meetings in different halves > of the world. Eventually consistent discussions do
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
Can you flag those tickets as "blocked" or "awaiting feedback" if they're not Paulo? That way they show up in the kanban board and are easily visible. I spoke with Jon and Jordan last Friday about the project mgt side of things; we've dropped the ball on that front since beta but are planning to get back into the saddle on sending more frequent status updates as well as trying to prune and clean up that list and move things along that get blocked. More to come. On Mon, Sep 28, 2020 at 10:27 AM, Paulo Motta wrote: > Thanks for the detailed context Patrick! I see a lot of value on > videoconferences for presentations and brainstorms but I tend to prefer > mailing list as a medium for consensus-seeking discussions for the > following reasons: > - Asynchronous - gives folk time to think and digest (as mentioned by Ben > on the Kubernetes thread); > - Timezones - allows people from all timezones to participate; > - Inclusivity - accommodates more people in the discussion. > > Regarding the proposed agenda of going through the unassigned issues to > improve visibility on what needs to be done to ship 4.0 GA I think this is > a great start but only covers part of the problem. > > I think we have 3 outstanding issues that are hampering visibility of 4.0 > progress: > a) Quality testing issues with no shepherd; > b) Quality testing issues with shepherd, but no recent activity (~2 months > or less); > c) Quality testing issues with no objective acceptance criteria/Definition > of Done; > > In order to facilitate the discussion I classified on this spreadsheet [1] > the quality epic (CASSANDRA-15536) subtickets into two categories: ON TRACK > / NEEDS ATTENTION. An issue "Needs Attention" if it has one of the 3 > problems mentioned above and is "On Track" otherwise. > > ## ON TRACK: > > CASSANDRA-15583 4.0 quality testing: Tooling, Bundled and First Party > CASSANDRA-15584 4.0 quality testing: Tooling - External Ecosystem > CASSANDRA-15977 4.0 quality testing: Read Repair > > ## NEEDS ATTENTION: > > CASSANDRA-14746 Ensure Netty Internode Messaging Refactor is Solid > CASSANDRA-15537 4.0 quality testing: Local Read/Write Path: Upgrade and > Diff Test > CASSANDRA-15538 4.0 quality testing: Local Read/Write Path: Other Areas > CASSANDRA-15579 "4.0 quality testing: Distributed Read/Write Path: > Coordination, > Replication, and Read Repair" > CASSANDRA-15580 4.0 quality testing: Repair > CASSANDRA-15581 4.0 quality testing: Compaction > CASSANDRA-15582 4.0 quality testing: metrics > CASSANDRA-15585 4.0 quality testing: Test Frameworks, Tooling, Infra / > Automation > CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance > CASSANDRA-15587 4.0 quality testing: Platforms and Runtimes CASSANDRA-15588 > 4.0 quality testing: Cluster Upgrade CASSANDRA-15921 4.0 quality testing: > Materialized View > > So in order to address these I think we should: > a) Seek volunteers to shepherd unassigned items; > b) Update status of inactive tickets; > c) Define objective acceptance criteria for each quality issue; > > I believe we should do A) by actively seeking via mailing list volunteers > for each unassigned quality issue, while B) and C) should be coordinated > independently by the shepherd of each issue. > > In my view this should improve accountability and transparency into 4.0 GA > progress. I would love to hear the community's thoughts on this. > > [1]: > https://docs.google.com/spreadsheets/d/ > 1E70HIo63KXP4ggLUCRYfuLLh_oJZNLuyuPdkiT6dMVE > > Em sex., 25 de set. de 2020 às 14:08, Patrick McFadin > escreveu: > > Hi Paulo, > > I appreciate you bringing this up because I'm sure that means plenty are > thinking the same thing. Let me give you a little context and history. > > Last ApacheCon I proposed setting up a periodic zoom call to emulate some > of the high bandwidth discussions that happen in-person. There was a good > deal of discussion about how to do this appropriately, specifically by not > creating isolated pockets of decision making. By providing yet another > interaction method, increase participation in the project. I have seen > these types of meetings work well in other OSS projects I'm involved with > but it needs to be right for ASF guidelines. > > - No final decisions are made during the call. Any proposals go to the > mailing list > - Make a recording and post so nothing is exclusive > - Post the chat transcripts (This is where the introverts interact and it > can be quite lively) > > I consider our Zoom call as part of a package of how we interact. Jira - > Code/feature specific discussion > Mailing List - Official record of discussions and decisions Slack - Fast > discussions with searchable text > Video Call - High bandwidth discussions and presentations. Transactional > in nature with an agenda. > > Having 25 people on a call to make a decision is not the intent or even > reasonable. No matter what the setting is, even on email we don't get that > many people weighing in on a topic. > > Usin
Re: [DISCUSS] Next steps for Kubernetes operator SIG
I can agree with that Ben. Franck did a good job of outlining CassKop. Somebody from the cass-operator will be posting something similar and we can keep it on the mailing list. Patrick On Sun, Sep 27, 2020 at 2:16 PM Ben Bromhead wrote: > Thanks Frank and Stefan. > > @Patrick great suggestion and worthwhile getting everything on the table. > > One minor change I would advocate for. The SIG has been great to iterate > and interact on the details, but I really think this conversation given the > nature of the content needs to be on the mailing list. The mailing list is > really our system of record and the most accessible. > > It gives folk time to think and digest, it's asynchronous, easily > searchable and let's be honest, the majority of stakeholders in this are > not US based, so the timing issue then goes away and makes it easier for > people to participate in. I feel like we've made a lot more progress by > simply having this discussion here. > > So instead of a presentation, maybe just an email to the ML addressing the > headings that Patrick identified? > > > On Fri, Sep 25, 2020 at 7:55 AM Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > > > Hi, > > > > Patrick's suggestion seems good to me. > > > > I won't go into specifics here as I need to genuinely prepare for > > this. It is quite hard to dig deep into the solutions of others and > > bring some constructive criticism because it takes a lot of time to > > study it and everybody has some "why's" behind it. > > > > To summarize my goals and concerns: > > > > 1) We should be as much "Kubernetes operator idiomatic" as possible. > > Industry standards, no custom brain-child of this or that group > > because they think it is just cool or they just didn't know any > > better. I do NOT say it is like that right now, I just want to be > > ruthless here as much as possible when it comes to functionality and > > why it is done like that. It is awesome that we have already something > > latest (thanks to John) and it adheres to the latest releases. I > > personally had a hard time to keep up with all the releases, once I > > finished something and I aligned it, after a week or two there was > > already another one where things were different, it is a very > > fast-moving space and I hope that by time we develop something it will > > not be obsolete. > > > > 2) It may be easier said than done but it is guaranteed that people > > get emotional, it's their precious etc, so please let's go into this > > with good intentions, not trying to push one solution over the other > > just because they would like to see it there ... I will have an > > equally hard time to comply with this point. My plan is to explain > > what is _wrong_ with our solution. Where we made mistakes and what > > should be done differently but it is "too late" etc. It is quite hard > > to describe your work and all effort in this light but without telling > > what is wrong we can not decide what is good imho. > > > > 3) We should put something together fast enough so we can call it a > > release. We can always iterate on it for eternity. But the foundations > > need to be there. Here I want to say that I especially like what John > > did. I looked through these specs and it was obvious it has been > > written with care and attention. It looked _solid_. I am not sure how > > hard it is to put all other things on top of that, I truly do not, and > > here I think we would have to reinvent that wheel if we want to > > proceed because I can not imagine what it would be to retrofit e.g. > > CassKop on top of John specs, it is just like putting round pegs into > > the square holes, maybe some chunks would be reused easily but > > otherwise I worry we will be just on square one. > > > > One specific feeling I have as I read this is that even if there is > > the will to create the fourth operator, the respective parties will > > not be able to drop their own repository. The whole point behind this > > effort, to me, is to have a solid, community driven, stable, modern > > and feature complete operator people are truly using. I can see that > > once this is real, we will _really_ sunset our operator, redirecting > > people to the new operator on main readme doc etc, we truly mean it. > > Sure, if somebody comes and bug fix will be needed, we will fix it, > > but the whole point of doing this is to stop using what we have > > currently, over time, otherwise we are just splitting this space even > > more. If CassKop is not sure if they will use it because they do not > > know if that operator will be "enough" for them, aren't we just doing > > it wrong? If I exaggerate, they should be fine with deleting the whole > > repository and using just this Cassandra one we are going to make > > otherwise I don't see the point to work on this ... > > > > On Thu, 24 Sep 2020 at 20:45, Joshua McKenzie > > wrote: > > > > > > - choose cass-operator: it is not on offer right now so let’s see if it
Re: Cassandra Contributor Meeting to focus on outstanding 4.0 issues
> Can you flag those tickets as "blocked" or "awaiting feedback" if they're not Paulo? That way they show up in the kanban board and are easily visible. Good idea, Josh! I will wait a bit to see if folks agree with my proposed definition of "Needs Attention" and mark all those tickets as blocked tomorrow so people involved in those issues are aware. Em seg., 28 de set. de 2020 às 12:38, Joshua McKenzie escreveu: > Can you flag those tickets as "blocked" or "awaiting feedback" if they're > not Paulo? That way they show up in the kanban board and are easily > visible. > > I spoke with Jon and Jordan last Friday about the project mgt side of > things; we've dropped the ball on that front since beta but are planning to > get back into the saddle on sending more frequent status updates as well as > trying to prune and clean up that list and move things along that get > blocked. More to come. > > > On Mon, Sep 28, 2020 at 10:27 AM, Paulo Motta > wrote: > > > Thanks for the detailed context Patrick! I see a lot of value on > > videoconferences for presentations and brainstorms but I tend to prefer > > mailing list as a medium for consensus-seeking discussions for the > > following reasons: > > - Asynchronous - gives folk time to think and digest (as mentioned by Ben > > on the Kubernetes thread); > > - Timezones - allows people from all timezones to participate; > > - Inclusivity - accommodates more people in the discussion. > > > > Regarding the proposed agenda of going through the unassigned issues to > > improve visibility on what needs to be done to ship 4.0 GA I think this > is > > a great start but only covers part of the problem. > > > > I think we have 3 outstanding issues that are hampering visibility of 4.0 > > progress: > > a) Quality testing issues with no shepherd; > > b) Quality testing issues with shepherd, but no recent activity (~2 > months > > or less); > > c) Quality testing issues with no objective acceptance > criteria/Definition > > of Done; > > > > In order to facilitate the discussion I classified on this spreadsheet > [1] > > the quality epic (CASSANDRA-15536) subtickets into two categories: ON > TRACK > > / NEEDS ATTENTION. An issue "Needs Attention" if it has one of the 3 > > problems mentioned above and is "On Track" otherwise. > > > > ## ON TRACK: > > > > CASSANDRA-15583 4.0 quality testing: Tooling, Bundled and First Party > > CASSANDRA-15584 4.0 quality testing: Tooling - External Ecosystem > > CASSANDRA-15977 4.0 quality testing: Read Repair > > > > ## NEEDS ATTENTION: > > > > CASSANDRA-14746 Ensure Netty Internode Messaging Refactor is Solid > > CASSANDRA-15537 4.0 quality testing: Local Read/Write Path: Upgrade and > > Diff Test > > CASSANDRA-15538 4.0 quality testing: Local Read/Write Path: Other Areas > > CASSANDRA-15579 "4.0 quality testing: Distributed Read/Write Path: > > Coordination, > > Replication, and Read Repair" > > CASSANDRA-15580 4.0 quality testing: Repair > > CASSANDRA-15581 4.0 quality testing: Compaction > > CASSANDRA-15582 4.0 quality testing: metrics > > CASSANDRA-15585 4.0 quality testing: Test Frameworks, Tooling, Infra / > > Automation > > CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance > > CASSANDRA-15587 4.0 quality testing: Platforms and Runtimes > CASSANDRA-15588 > > 4.0 quality testing: Cluster Upgrade CASSANDRA-15921 4.0 quality testing: > > Materialized View > > > > So in order to address these I think we should: > > a) Seek volunteers to shepherd unassigned items; > > b) Update status of inactive tickets; > > c) Define objective acceptance criteria for each quality issue; > > > > I believe we should do A) by actively seeking via mailing list volunteers > > for each unassigned quality issue, while B) and C) should be coordinated > > independently by the shepherd of each issue. > > > > In my view this should improve accountability and transparency into 4.0 > GA > > progress. I would love to hear the community's thoughts on this. > > > > [1]: > > https://docs.google.com/spreadsheets/d/ > > 1E70HIo63KXP4ggLUCRYfuLLh_oJZNLuyuPdkiT6dMVE > > > > Em sex., 25 de set. de 2020 às 14:08, Patrick McFadin < > pmcfa...@gmail.com> > > escreveu: > > > > Hi Paulo, > > > > I appreciate you bringing this up because I'm sure that means plenty are > > thinking the same thing. Let me give you a little context and history. > > > > Last ApacheCon I proposed setting up a periodic zoom call to emulate some > > of the high bandwidth discussions that happen in-person. There was a good > > deal of discussion about how to do this appropriately, specifically by > not > > creating isolated pockets of decision making. By providing yet another > > interaction method, increase participation in the project. I have seen > > these types of meetings work well in other OSS projects I'm involved with > > but it needs to be right for ASF guidelines. > > > > - No final decisions are made during the call. Any proposals go to the > > mailing list > > - Make a recording a
