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. > > > > >
