Thanks everyone for all the feedback. This thread has been open for just over 2 weeks and it doesn't look like we have any further outstanding major issues or concerns. Are we ready to bring this to a vote?
On Tue, Jul 7, 2026, at 2:36 AM, Jon Haddad wrote: > I am an extremely enthusiastic +1 for this. > > I added support for EC2 role credentials recently which was a serious > headache due to the separation of the two projects. Having them together will > make these kinds of future improvements a lot easier. > > Thanks Josh for taking the lead on this. > > Jon > > On Mon, Jul 6, 2026 at 1:46 PM Josh McKenzie <[email protected]> wrote: >> __ >> I revised section 7 to try and make the intended split between the tactical >> (GitHub) and strategic (dev ML) more clear: >>> 7. Issue tracking, technical discussions, and code review: move to GitHub >>> >>> This CEP *formally proposes that **`cassandra-ecosystem`** use GitHub >>> Issues, GitHub Discussions, and GitHub Pull Requests* as its tracker, >>> discussion forum, and code-review surface - rather than creating a new JIRA >>> project (the previously-floated `CASSECO`). Discussion on github should be >>> constrained to tactical / technical topics (feature design, implementation, >>> testing, etc). For strategic topics (project governance, roadmap, >>> architecture, releases, etc) discussion should be kept to the dev ML. >>> Rationale: >>> • It keeps issues, technical discussions, code review, and code in one >>> place, lowering friction for the external contributors and downstream >>> consumers who already interact with these projects via GitHub. >>> • When we moved from code collaboration happening in JIRA comments to >>> happening in github PR’s years ago, our discussion around work fragmented. >>> The majority of that discussion already happens in github on PR’s; if we >>> move to using github discussions, projects, milestones, and centralize our >>> project management in github, we will have a more modern, feature-rich, and >>> interconnected platform for people to collaborate on. >>> • The vast majority of the industry and thus new contributors to the >>> cassandra ecosystem will be familiar with github; having to split their >>> workflows between github and JIRA presents a hurdle on both integrating >>> with the community and on longer-term collaboration. >>> • A brand-new repository is the natural, low-cost moment to adopt this >>> workflow; there is no legacy of in-flight JIRA process to disrupt within >>> the new repo. >>> • GitHub Discussions gives design conversations a durable, searchable home >>> (the `[DISCUSS]` mailing-list thread still governs the *CEP* process and is >>> used for the official system-of-record; Github discussions complement it >>> for implementation-level design). >>> • Note: all strategic project level discussions (architecture, roadmap, >>> releases, etc) should happen on the dev list. The intent is to have >>> tactical discussions (implementation, technical details, etc) centralized >>> in one location >>> • All conversation on GitHub will be reflected to a mailing list using >>> notifications >> >> >> >> On Sun, Jul 5, 2026, at 8:42 AM, Mick wrote: >>> >>> >>> > On 5 Jul 2026, at 14:37, Mick <[email protected]> wrote: >>> >> On 30 Jun 2026, at 19:38, Brandon Williams <[email protected]> wrote: >>> >> On Tue, Jun 30, 2026 at 12:18 PM Josh McKenzie <[email protected]> >>> >> wrote: >>> >>> >>> >>> So. In case this triggers anything for anyone, figured I'd raise it >>> >>> here. :) >>> >> >>> >> I do worry that moving discussion from ASF-controlled infrastructure >>> >> to Microsoft-controlled infrastructure will prove to be unwise in the >>> >> future. >>> > >>> > >>> > >>> > This is in a way a hard requirement from the ASF. >>> > All decision making must be _recorded_ on ASF-controller infrastructure. >>> > >>> > It is solved by sending all notifications to a mailing list. >>> > e.g. we can create a new read-only mailing list we all ecosystem >>> > discussions are copied to. >>> > >>> > This is why all other github activities are being sent to a ml, and which >>> > I believe is enforced by the .asf.yml >>> > >>> > It would also be possible, as a number of other apache projects have >>> > done, to migrate all our existing sidecar and analytics jira tickets to >>> > github issues. >>> >>> >>> And all binding votes need to still happen on the mailing list, like >>> releases. >>> >>> >>> >>
