i’m +1 for move +removal of cyclic deps. i don’t know if william has time to wait on a move, vs a fork? or if he can fork, to get going and re-align if a move is eventually removed.
mark On Sat, 14 Dec 2024 at 21:20, Alex Porcelli <a...@porcelli.me> wrote: > Thank you for reaching out, William! > > As Eder rightly pointed out, the community focus has been primarily on > the core components. Unfortunately, this has left Dashbuilder > unmaintained. This is an area of concern for me as the Dashbuilder > codebase has remained untouched and is accumulating critical security > vulnerabilities. > > Rather than forking, an alternative solution would be to move it to a > different organization, where it could receive the attention and care > it deserves. > > Of course, such a move would require a community vote and, most > importantly, approval from the Apache Software Foundation, as they > currently own the brand and associated trademarks. > > I appreciate your efforts and interest in evolving Dashbuilder. > > I look forward to hearing the community's thoughts on this! > > P.S. I'm also forwarding this to the IPMC private mailing list for > awareness and feasibility analysis. > > On Fri, Dec 13, 2024 at 2:05 AM Toni Rikkola <trikk...@redhat.com> wrote: > > > > I see the benefits of a separate Dashbuilder. Having it under KIE if the > > uses extend KIE use cases is not ideal. > > > > However the cyclic dependency issue is something that I would like to > see a > > plan for. Just due to the reason that KIE builds and releases need to be > > made faster and more simple. This might take us in the wrong direction. > > > > Toni > > > > On Thu, Dec 12, 2024 at 8:30 PM Tiago Bento <tiagobe...@apache.org> > wrote: > > > > > Hi William, > > > > > > Thanks for reaching out with this proposal. We’ve been indeed short of > > > contributors for Dashbuilder inside Apache KIE, and I guess being > inside > > > Apache KIE also hasn’t been so nice for it. > > > > > > I’m all for letting it *intentionally* fade out inside KIE until it’s > > > eventually replaced once we find a suitable candidate (very likely this > > > fork under a new name you’re proposing!) > > > > > > One thing that concerns me, though, is the fact that we might run into > a > > > cyclic, dephased dependency relationship, should we try to depend on > this > > > new fork. > > > > > > For some reason, this subject seems to keep following me in the emails > I > > > send to Apache KIE’s mailing lists :) > > > > > > dashbuilder-components-* packages depend on our micro-frontends > Multiplying > > > Architecture core packages (envelope-bus and envelope), and I guess > this > > > dependency would be kept for this fork you’re proposing, given the > > > architecture Dashbuilder has chosen to follow. > > > > > > If that’s indeed the case, and you intend to keep depending on these > > > packages (for micro-frontend purposes), and we then decide to drop-in > > > replace Dashbuilder with the new forked project, we (Apache KIE) would > be > > > always depending on a previous version of ourselves transitively via > our > > > dependency with this new Dashbuilder fork. > > > > > > Please note that these technical issues I’m talking about here are > only for > > > making it clear that Apache KIE might not be able to depend on this new > > > forked Dashbuilder without creating a cyclic, dephased dependency > > > relationship, as Apache KIE can either be an upstream or a downstream > > > dependency relative to this new fork, not both. > > > > > > Apache KIE, from my perspective, currently is not able to move in the > pace > > > that you might be envisioning for Dashbuilder. And at the same time, > > > without active contributors and component SMEs for Dashbuilder, and > given > > > its somewhat complex tech stack and size, the current active Apache KIE > > > contributors might not be able to keep maintaining, evolving, and > releasing > > > Dashbuilder too. > > > > > > With all that said, and as a contributor to Apache KIE, I feel like > forking > > > or not forking is your individual choice… and I deeply appreciate you > > > reaching out for us to think together about what’s the smoothest path > > > moving forward. > > > > > > I’m always available for any additional conversations about this topic! > > > > > > Regards, > > > > > > Tiago Bento > > > > > > > > > On Thu, Dec 12, 2024 at 2:48 PM William Siqueira <wsiqu...@redhat.com> > > > wrote: > > > > > > > Hello, > > > > > > > > My name is William and I was a Dashbuilder contributor. > > > > > > > > We have been working with Dashbuilder for a while and we have a > roadmap > > > for > > > > quite a few improvements and we wanted to make some changes to its > core, > > > > also build new projects having dashbuilder as the core of it. > > > > > > > > Having this said, it would be great to fork dashbuilder core to a new > > > > project so it can evolve independently. By Dashbuilder core I mean > the > > > > following packages: > > > > > > > > * dashbuilder: The actual core with GWT and Errai > > > > * dashbuilder-components-*: Dashbuilder micro front-end components > and > > > its > > > > APIs > > > > > > > > The new fork will have a friendly license, which means that you > should be > > > > able to continue using it by just pointing dashbuilder-client[1] to > the > > > > package from the new project. All the other projects dependent on > > > > dashbuilder would continue working (Kubesmarts, vscode extension, > > > > dashboards and so on) with little or no change. > > > > > > > > Kindly let me know your thoughts about this. > > > > > > > > Thanks! > > > > > > > > [1] > > > > > > > > > > > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dashbuilder-client/package.json#L26 > > > > > > > > -- > > > > > > > > William Siqueira > > > > > > > > Software Engineer > > > > > > > > Red Hat > > > > > > > > <https://www.redhat.com> > > > > > > > > M: +55-12997070488 > > > > <https://red.ht/sig> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
