Thank you for the clarification, Ricardo. It absolutely makes sense to move the publication downstream.
With that being said, I'm still concerned about the usage of the images that won't be consumed downstream anymore (wondering if they will be useful or maybe they should be deprecated). On Mon, Jan 6, 2025 at 10:21 AM ricardo zanini fernandes <[email protected]> wrote: > > Hi all! > > Let me try to clarify some bits here to give more context. > > Currently, start.kubesmarts.org is a name/DNS owned by downstream, but the > process of publishing it, AFAIU, is *owned** by* *upstream*. That's the > problem. Also, we will rebrand the website on the downstream fork to follow > the downstream look and feel (aka remove Dashboards, Serverless Decision, > KIE logo, etc). > > *So the proposal is to remove this process from upstream but keep the > packages where they are* so that we can either incorporate them under > sandbox.kie.org or create a new one, maybe serverless.sandbox.kie.org. We > can have another thread to discuss that. > > Step 1: Remove any attachments from Apache KIE to start.kubesmarts.org > Step 2: Migrate the current website under a new domain or use the current > sandbox (maybe adding a new item named Serverless Workflows). > > I hope it's clear now. > > Cheers! > > On Thu, Jan 2, 2025 at 1:47 PM Alex Porcelli <[email protected]> wrote: > > > Agree with Jason about not issue on downstream; > > > > However I wonder if we need to continue having the images as part of the > > Apache KIE (incubating) releases, unless being used in practice by the > > project itself. > > > > I also would like what’s the plan to integrate it to existing sandbox or > > alike as suggested by Fabrizio. > > > > - > > Alex > > > > > > On Thu, Jan 2, 2025 at 12:05 PM Jason Porter <[email protected]> > > wrote: > > > > > I'm not sure what to do here. A downstream can do what they want, as long > > > as they're pointing back to the ASF site and the official upstream. > > There's > > > also some feedback at > > > https://www.apache.org/foundation/marks/downstream.html. There may be > > > others on cwiki, this was the first one that came up from Google. > > > > > > I don't really see this as a bad thing, as long as it follows the ASF > > > guidelines. > > > > > > On 2024/12/28 22:23:45 Fabrizio Antonangeli wrote: > > > > Below my answers: > > > > > > > > - What images are used by Kubesmarts? > > > > Currently, start.kubesmarts.org uses upstream images, but from the > > old > > > > quay.io/kie-tools: > > > > - > > > > > > > > > https://quay.io/repository/kie-tools/serverless-logic-web-tools-base-builder-image > > > > > > > > - > > > > > > > > > https://quay.io/repository/kie-tools/serverless-logic-web-tools-swf-builder-image > > > > > > > > - > > > > > > > > > https://quay.io/repository/kie-tools/serverless-logic-web-tools-swf-dev-mode-image > > > > > > > > - https://quay.io/repository/kie-tools/dashbuilder-viewer-image > > > > > > > > For the proposed downstream process, Kubesmarts would publish it own > > > > downstream images to its own Quay repository > > > > (https://quay.io/organization/kubesmarts) using downstream sources. > > > > > > > > - What are the purpose of those images. I mean, are they useful outside > > > > kubesmart deployment scope? > > > > Their primary scope is to create SonataFlow deployments on OpenShift > > > > from the webapp, but they are generic enough to be reused in a new > > > > upstream website. > > > > > > > > - What are the differences between SonataFlow and the code hosted by > > > > kubesmart? > > > > Currently Kubesmarts serves as the online sandbox for the kie-tools > > > > Serverless Logic Web Tools package (upstream). The deployments created > > > > by the webapp on OpenShift rely on SonataFlow. > > > > > > > > Fabrizio > > > > > > > > On Sat, 2024-12-28 at 15:12 -0500, Alex Porcelli wrote: > > > > > Thank you for the clarification. However my follow up question are: > > > > > > > > > > - what exactly images are used by kubesmarts? > > > > > - What are the purpose of those images - I mean, are they useful > > > > > outside > > > > > kubesmart deployment scope? > > > > > - Trying also to understand the relationship of SonataFlow and the > > > > > kubsmarts…. what are the differences between SonataFlow and the code > > > > > hosted > > > > > by kubesmart? > > > > > > > > > > - > > > > > Alex > > > > > > > > > > > > > > > On Sat, Dec 28, 2024 at 12:41 PM Fabrizio Antonangeli < > > > > > [email protected]> wrote: > > > > > > > > > > > Hi Alex, > > > > > > To summarize my proposal: > > > > > > > > > > > > * No sources will be moved out of kie-tools. > > > > > > * Currently, start.kubesmarts.org (a downstream DNS) is built > > using > > > > > > upstream sources and images. I propose changing this to use > > > > > > downstream sources and images, while keeping it under > > > > > > start.kubesmarts.org. > > > > > > * For the upstream version of the Serverless Logic Web Tools > > > > > > website, > > > > > > we suggest either creating a dedicated upstream DNS or > > > > > > incorporating > > > > > > it within sandbox.kie.org. > > > > > > > > > > > > Let me know if further details are needed. > > > > > > Best regards, > > > > > > Fabrizio > > > > > > > > > > > > On Tue, 2024-12-24 at 17:04 -0500, Alex Porcelli wrote: > > > > > > > Fabrizio, > > > > > > > > > > > > > > I’m sorry for being late here…. > > > > > > > > > > > > > > Unfortunately it is not clear to me what exactly you are > > > > > > > expecting. > > > > > > > > > > > > > > Kubesmart seems to be a downstream, and afaik, there is no legal > > > > > > > or > > > > > > > trademark implications… so all good here. > > > > > > > > > > > > > > Now… if you plan to move things out of Apache to Kubesmart, this > > > > > > > becomes > > > > > > > more tricky… and this is actually not clear if this is your > > > > > > > intention. > > > > > > > > > > > > > > Would be possible to you elaborate what exactly you want to move? > > > > > > > Something > > > > > > > like: > > > > > > > > > > > > > > dns - origin - destination > > > > > > > whatever.org - org1 - org2 > > > > > > > > > > > > > > artifact - repository - origin - destinatio > > > > > > > containerA - kie-tools - Apache - Org2 > > > > > > > > > > > > > > Regards, > > > > > > > _____________ > > > > > > > Alex Porcelli > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 18, 2024 at 8:07 AM Fabrizio Antonangeli < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > Dear Community, > > > > > > > > I would like to propose a temporary adjustment regarding the > > > > > > > > publishing > > > > > > > > and DNS management of the Serverless Logic Sandbox website. > > > > > > > > BackgroundCurrently, the community-facing website ( > > > > > > > > https://start.kubesmarts.org) > > > > > > > > is using the 0.32.0 image version. However, the latest upstream > > > > > > > > image > > > > > > > > tagged as 10.0.0 is only available in DockerHub under the > > > > > > > > Apache > > > > > > > > organization: > > > > > > > > * Apache DockerHub: apache/incubator-kie-serverless-logic-web- > > > > > > > > tools- > > > > > > > > swf-dev-mode [2] > > > > > > > > * Old KIE Tools Quay: > > > > > > > > kie-tools/serverless-logic-web-tools-swf-dev-mode-image [3] > > > > > > > > * Kubesmarts Quay: kubesmarts/incubator-kie-serverless-logic- > > > > > > > > web- > > > > > > > > tools-swf-dev-mode [1] > > > > > > > > Historically, before moving to Apache, Kubesmarts images were > > > > > > > > published > > > > > > > > under the KIE Tools Quay, which now doesn’t have 10.0.0 image > > > > > > > > tags. > > > > > > > > Since the current release process has changed, this workflow no > > > > > > > > longer > > > > > > > > exists. > > > > > > > > ProposalTo address the current issues and clarify ownership, I > > > > > > > > propose the > > > > > > > > following steps: > > > > > > > > 1. Migrate Publishing Procedure to Kubesmarts group > > > > > > > > - Change the publishing process for the Kubesmarts > > > > > > > > website > > > > > > > > to use > > > > > > > > our > > > > > > > > downstream source and downstream images. This aligns > > > > > > > > with > > > > > > > > our > > > > > > > > internal needs and ensures we have control over the > > > > > > > > images > > > > > > > > and > > > > > > > > versions being used. > > > > > > > > 2. Clarify DNS Ownership > > > > > > > > - The community should manage its own DNS, and we > > > > > > > > propose > > > > > > > > taking > > > > > > > > full > > > > > > > > ownership of the Kubesmarts DNS. This approach > > > > > > > > separates > > > > > > > > Red Hat's > > > > > > > > requirements from the community's work while providing > > > > > > > > a > > > > > > > > clear > > > > > > > > structure for future contributions. > > > > > > > > 3. Make a separate proposal for upstream DNS > > > > > > > > - We can develop a separate proposal for the upstream > > > > > > > > DNS or > > > > > > > > incorporate SLWT in the Sandbox using only upstream > > > > > > > > images > > > > > > > > > > > > > > > > Please share your thoughts. > > > > > > > > > > > > > > > > [1] kubesmarts/incubator-kie-serverless-logic-web-tools-swf- > > > > > > > > dev- > > > > > > > > mode > > > > > > > > > > > > > > > > > > > > > > > > > > > https://quay.io/repository/kubesmarts/incubator-kie-serverless-logic-web-tools-swf-dev-mode?tab=tags > > > > > > > > [2] apache/incubator-kie-serverless-logic-web-tools-swf-dev- > > > > > > > > mode > > > > > > > > > > > > > > > > > > > > > > > > > > > https://hub.docker.com/r/apache/incubator-kie-serverless-logic-web-tools-swf-dev-mode/tags > > > > > > > > [3] kie-tools/serverless-logic-web-tools-swf-dev-mode-image > > > > > > > > > > > > > > > > > > > > > > > > > > > https://quay.io/repository/kie-tools/serverless-logic-web-tools-swf-dev-mode-image?tab=tags > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
