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

Reply via email to