I agree here with the concerns. Moving to GH infrastructure also feels orthogonal to the CEP, and as Benedict mentioned can be separated out of the proposal and have its own dedicated discussion.
On 2026/07/08 17:49:06 Benedict Elliott Smith wrote: > Several people have expressed concern about this part of the proposal, > whereas the rest is uncontentious. > > My view is that the projects should not diverge in issue tracking procedure, > as this is confusing for users and contributors. Others have expressed other > reservations. > > The point is that this requires a dedicated discussion with an appropriate > subject to invite participation exploring these concerns. Without this I > would vote against the CEP as it stands, but if this part of the proposal > were split out I’m sure the CEP could progress uncontested. > > On 2026/07/08 17:16:53 Josh McKenzie wrote: > > > This has implications for the project as a whole > > Could you elaborate? > > > > > I do worry that moving discussion from ASF-controlled infrastructure > > > ... > > > us moving closer instead seems directionally wrong to me. > > The CEP now explicitly proposes moving issue tracking to github, not > > project discussions, and auto-forwarding conversation to a ML. There's > > little difference to our existing dependency for PR reviews, and the ASF > > has blessed it as an approved space to do our work. > > > > Active contributors to these projects on this thread are in favor of these > > changes; before we split out this aspect of things let's make sure we're > > all aligned and our reasoning is on the table. > > > > On Wed, Jul 8, 2026, at 6:07 AM, Aleksey Yeshchenko wrote: > > > This ^ > > > > > > And this: > > > > > > > I do worry that moving discussion from ASF-controlled infrastructure > > > > to Microsoft-controlled infrastructure will prove to be unwise in the > > > > future. > > > > > > With more high profile OSS projects moving away from GitHub, > > > and its availability and reliability on the decline, us moving closer > > > instead seems directionally wrong to me. But it should really be > > > a separate discussion, and perhaps a different CEP. > > > > > > > On 8 Jul 2026, at 09:53, Benedict Elliott Smith <[email protected]> > > > > wrote: > > > > > > > > Please separate out the proposal to migrate to GitHub issue tracker > > > > etc. into its own discussion and vote, as this was flying under the > > > > radar. This has implications for the project as a whole, and should be > > > > considered in isolation. > > > > > > > > On 2026/07/08 03:22:46 Bernardo Botella wrote: > > > >> Let’s vote! > > > >> > > > >> El El mar, 7 jul 2026 a las 21:26, Josh McKenzie <[email protected]> > > > >> escribió: > > > >> > > > >>> 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. > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > > > > > > >
