Hello everyone, I am not sure if there is some sort of consensus yet, but let me at least summarize and go on from there, it seems the traffic here is settled so I think we should move on to do a proposal in order to resolve this topic.
First and foremost, I created issue <https://github.com/apache/incubator-kie-kogito-examples/issues/2050> in examples so that we can easily track the work happening/needed to be done. >From my understanding there are 2 issues this thread brought up and tried to solve. 1. Missing examples for customers who are consuming our technology stack. 2. Missing examples integration with our CI & generally undefined development process for examples after the apache kie move and architecture discussions had started. Focus of my follow up here is issue number 1. Issue number 2 is up for grabs if anyone wants to take responsibility. With the regards to issue 1, do you agree that I create a new proposal to resolve this situation with the following steps: ( Details will be put into the proposal, I am keeping it high-level here ) 1. Investigate the example upgrade with `10.0.0` build, see if the build is stable, test pass etc. 2. Establish a common branch name pattern for examples stabilized with a particular release. 3. Contribute a PR with the stabilized examples and updated README file. 4. Update the README file for example of stable branch 5. Confirm with the community that the current set of examples is expected and from SME's their examples are working 6. Make the stable branch (whatever we decide on the name ) a default branch for examples 7. Announce the examples availability to the community. Let me know if this works for you if I do not get an explicit -1 for this, I ll proceed with the proposal on Friday 17th. Best regards, Dominik On Fri, 10 Jan 2025 at 16:34, Alex Porcelli <[email protected]> wrote: > Francisco, > > The steps described is for developers work with the examples. > > For end user to consume, the content of the release artifact will be pushed > to the examples repository (manually or automated) as described in my > proposal number 3. > > > On Fri, Jan 10, 2025 at 9:19 AM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > Hi Alex, > > Im wondering how is suppose to be easier for users to > > > > $ git clone kie-tools > > $ cd kie-tools > > $ pnpm bootstrap -F runtime-examples... > > $ cd examples/runtime-examples > > (to some extent at this point you can interact with the examples as a > > standalone thing) > > $ idea/code/eclipse . > > $ mvn clean compile, > > > > rather than, as Dominik just proposed, do > > > > 1. git clone [email protected]:apache/incubator-kie-kogito-examples.git > > 2. git checkout stable-10.0.0 > > 3. cd the-best-example-in-the-world > > 4. Follow README instructions to work with it > > > > > > > > On Fri, Jan 10, 2025 at 3:06 PM Alex Porcelli <[email protected]> wrote: > > > > > Enrique, unfortunately this is not entirely possible. The only reason > > > to move the examples under the kie-tools repo is because of examples > > > depending on kie-tools artifacts, so to properly build the examples > > > you have first build the dependencies. > > > > > > To work with the examples the steps would be something along the > > > following lines: > > > > > > $ git clone kie-tools > > > $ cd kie-tools > > > $ pnpm bootstrap -F runtime-examples... > > > $ cd examples/runtime-examples > > > (to some extent at this point you can interact with the examples as a > > > standalone thing) > > > $ idea/code/eclipse . > > > $ mvn clean compile, > > > > > > (this is not 100% precise because it depends on how the examples are > > > moved etc... but hopefully you get the idea). > > > > > > On Fri, Jan 10, 2025 at 5:55 AM Enrique Gonzalez Martinez > > > <[email protected]> wrote: > > > > > > > > Hi, > > > > > > > > Regarding this topic as some of the people mentioned before this is a > > > > matter of proper pipeline. Moving the examples to kie tools should be > > > > a temporary solution but we know that there is nothing more permanent > > > > than a temporary solution as everybody will get back to deadlines, TO > > > > DO list and so forth. > > > > > > > > In any case if we cannot find a proper solution in the pipeline, I am > > > > not against moving those examples to kie-tools with some conditions. > > > > > > > > 1. they should offer the same level of independence as it is now. > > > > Meaning that if I go to the folder of kie-tools/examples (or whatever > > > > it is) and I do mvn clean install it should be able to build with the > > > > 999-SNAPSHOT like other projects and take my local changes without > any > > > > further configuration. > > > > 2. it should support the same level of CI per PR like we have now. > Now > > > > examples are one repo but the CI execution is split in 2 (quarkus and > > > > spring boot) > > > > 3. any other tool used by kie-tools like pnpn should be unnecessary > to > > > > build the examples. > > > > 4. any version or snap version set by kie tools building tool can > > > > override during building but cannot set on pom. > > > > 5. any change in that structure without proper discussion should be > > > > result in an inmediate rollback without any approval required. > > > > > > > > Doing this mantain the kogito-examples independence even if we have > > > > them in kie-tools and for backender will have the same outcome and > > > > daily work. If those criteria are not met, I am against moving > > > > examples. > > > > > > > > Cheers :) > > > > > > > > > > > > El jue, 9 ene 2025 a las 16:56, Alex Porcelli (<[email protected] > >) > > > escribió: > > > > > > > > > > I’m looking for this new thread, but I don’t think it would > > invalidate > > > this > > > > > thread. > > > > > > > > > > The scope of this thread is clear, and if you hang in Zulip you can > > see > > > > > that users are completely lost with lack of any example…. I created > > my > > > own > > > > > example to help, but I don’t think this is the solution this > > community. > > > > > > > > > > I’d argue that the options are clear and also we defined, there’s > an > > > > > actionable plan and even commitment to execute. > > > > > > > > > > Alex > > > > > > > > > > On Thu, Jan 9, 2025 at 10:20 AM Paolo Bizzarri <[email protected]> > > > wrote: > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > I do think that this is relevant for the discussion on the kogito > > > examples. > > > > > > > > > > > > It is a necessary decision that we as a community we need to take > > > before > > > > > > making other modifications to the repo structure. > > > > > > > > > > > > Let's open a new thread so that first we can reach the consensus > on > > > which > > > > > > should be the general structure of the KIE project - in term of > > > > > > repositories - and then we can move forward identifying the > actions > > > > > > required to move into that direction and who can do this. > > > > > > > > > > > > Without this consensus things will keep getting discussed again > and > > > again, > > > > > > which is something no one wants. > > > > > > > > > > > > Regards > > > > > > > > > > > > P. > > > > > > > > > > > > On Thu, Jan 9, 2025 at 2:36 PM Alex Porcelli <[email protected]> > > > wrote: > > > > > > > > > > > > > Thank you, Tiago for steering back the thread to original > > problem. > > > > > > > > > > > > > > Please anyone feel free to open a new thread to discuss > whatever > > > you > > > > > > > consider necessary. Just be thoughtful to write not only > > opinions, > > > but > > > > > > > detailed plans with actionable items. Ideally with some level > of > > > > > > commitment > > > > > > > to an execution. > > > > > > > > > > > > > > - > > > > > > > Alex > > > > > > > > > > > > > > On Thu, Jan 9, 2025 at 8:15 AM Tiago Bento < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > Before I share my remarks about the "examples" topic in > > > particular, > > > > > > > > let me start by talking about a concept that I think is often > > > > > > > > mistakenly used in this mailing list -- "users". Users are > (the > > > way I > > > > > > > > see it at least) people who consume our software via our > > official > > > > > > > > releases. They (mostly) DO NOT care about where or how the > > > source code > > > > > > > > is hosted, built, released, nor how "hard" or "inconvenient" > it > > > is to > > > > > > > > develop the artifacts they actually depend on. Apache KIE > users > > > are > > > > > > > > not Apache KIE developers. For a long time now, I think we > > might > > > be > > > > > > > > focusing our technical discussions too much on us > (developers) > > > and too > > > > > > > > little on our users, who are the reason why we do all this in > > the > > > > > > > > first place. In the end, we want our software to be used to > > solve > > > > > > > > problems in the real world, and to help people outside of > this > > > little > > > > > > > > inner circle of developers (us) to do so. > > > > > > > > > > > > > > > > Alex created a thread to discuss a real problem our users are > > > facing, > > > > > > > > and we quickly turned it into a discussion on what's best for > > us > > > > > > > > developers. Alex also came up with a real solution to the > > > problem, and > > > > > > > > we started debating the entire architecture of the codebase, > > > with all > > > > > > > > sorts of arguments mixed into the conversation. We won't ever > > go > > > > > > > > anywhere if we continue discussing things this way. We can't > > > halt all > > > > > > > > technical/architectural discussions because we don't have a > > > "global" > > > > > > > > plan that will solve all our problems. So let's PLEASE take a > > > step > > > > > > > > back and talk about our focused subject on this thread: "How > > can > > > we > > > > > > > > allow our users consume meaningful example applications in an > > > easy > > > > > > > > way, for each release we do?". > > > > > > > > > > > > > > > > I compiled the two options that have been shared so far: > > > > > > > > > > > > > > > > 1. Move the example applications from `kogito-examples` to > > > > > > > > `kie-tools`'s `examples/` folder and create a new release job > > to > > > > > > > > publish a ZIP containing each of the examples as a release > > > artifact. > > > > > > > > 2. Integrate `kogito-examples` into our release process so > that > > > it has > > > > > > > > its versions properly updated and is tagged once a release is > > > > > > > > approved, and keep everything else as is, without references > to > > > > > > > > artifacts coming from `kie-tools`. > > > > > > > > > > > > > > > > What I most like about option 1 is that there are no changes > > > needed in > > > > > > > > "the CI" (other than removing kogito-examples from it, of > > > course, like > > > > > > > > we did for kogito-images recently). Moving our examples to > > > `kie-tools` > > > > > > > > would also allow for them to correctly and safely depend on > > tools > > > > > > > > artifacts, like the graphical Editors, Container images, and > > > Quarkus > > > > > > > > Dev UIs, which, as pointed out by Francisco, have become > > central > > > to > > > > > > > > the development of Decisions, Workflows, and Processes, and > > add a > > > > > > > > great value for people exploring these examples applications. > > > Users > > > > > > > > would be able to consume these example applications in the > same > > > way > > > > > > > > they consume other release artifacts, and we could even keep > a > > > > > > > > read-only repository where we publish these individual > > > applications > > > > > > > > for convenience (maybe ` > > > github.com/apache/incubator-kie-examples` > <http://github.com/apache/incubator-kie-examples> > > <http://github.com/apache/incubator-kie-examples> > > > <http://github.com/apache/incubator-kie-examples> > > > > > > <http://github.com/apache/incubator-kie-examples> > > > > > > > <http://github.com/apache/incubator-kie-examples>? > > > > > > > > <http://github.com/apache/incubator-kie-examples?>). > > > > > > > > IMHO, trying to make a repository satisfy both developers and > > > users > > > > > > > > will always yield a sub-optimal setup. > > > > > > > > > > > > > > > > This "CI" we're constantly referring to, to my best > knowledge, > > > is a > > > > > > > > mix of PR checks (`build-chain` + GitHub Actions) and release > > > > > > > > automations ("the Kogito framework" on Apache Jenkins) for > the > > > > > > > > `drools`, `optaplanner`, `kogito-runtimes`, `kogito-apps` > (and > > > more or > > > > > > > > less `kogito-examples`) repos. I personally do not know how > it > > > all > > > > > > > > works, but AFAIK `build-chain` was created by Enrique Cano > back > > > in Red > > > > > > > > Hat days and has been referred to by our PR checks [1]; and > > "the > > > > > > > > Kogito framework" on Apache Jenkins for release automation > has > > > always > > > > > > > > imposed challenges to us in terms of maintainability. Rodrigo > > > Antunes, > > > > > > > > Alex, and I suffered quite a bit with it during the push for > > > 10.0.0. > > > > > > > > > > > > > > > > While I believe both `build-chain` and "the Kogito framework" > > on > > > > > > > > Apache Jenkins to have been created by talented contributors > > with > > > > > > > > their best intentions in mind, both have evolved to be places > > > where no > > > > > > > > one wants to go; tools that no one really wants to > > > maintain/evolve. In > > > > > > > > my view, both have become an increasing risk to the > sustainable > > > growth > > > > > > > > of the Apache KIE community, so suggesting we delegate the > > > solution to > > > > > > > > a "new" problem to these systems (and therefore depending > more > > on > > > > > > > > them) doesn't really resonate with me, so I wouldn't go with > > > option 2. > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/.ci/actions/build-chain/action.yml#L36 > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jan 9, 2025 at 6:16 AM Gabriele Cardosi > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > I would like to quote: > > > > > > > > > > > > > > > > > > "So, first and foremost we should decide which is the ideal > > > situation > > > > > > > > where > > > > > > > > > we want to move our repos - one repo, two repo, many repos. > > > With > > > > > > ideal > > > > > > > > > situation I mean "what we think is the best architecture". > > > > > > > > > > > > > > > > > > There is a similar thread where we have been asked to > approve > > > a given > > > > > > > > > proposal without having defined the overall strategy for > > > code-base > > > > > > > > > management. > > > > > > > > > The lack of a clear architecture goal, IMO, affected a lot > of > > > our > > > > > > > > > decisions, that at a given point became "unavoidable" > while, > > > > > > actually, > > > > > > > > they > > > > > > > > > were not. > > > > > > > > > > > > > > > > > > So, to further the previous remarks, before going on with > > this > > > > > > > > discussion, > > > > > > > > > there are two topics to tackle once and for all > > > > > > > > > > > > > > > > > > 1. multiple repo vs mono-repo (global concern) > > > > > > > > > 2. What is exactly the scope of our examples ? (specific to > > > this > > > > > > > thread) > > > > > > > > > > > > > > > > > > About the latter, we also had a longish thread last summer, > > > about > > > > > > > > > "standalone" or similar, that basically ended up on nothing > > > because, > > > > > > if > > > > > > > > the > > > > > > > > > scope of something is not commonly clear and agreed upon, > > then > > > it is > > > > > > > > > impossible to get to a commonly shared solution. > > > > > > > > > > > > > > > > > > Best > > > > > > > > > Gabriele > > > > > > > > > > > > > > > > > > Il giorno gio 9 gen 2025 alle ore 08:43 Jan Šťastný < > > > > > > > > [email protected]> > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I'd like to add some high-level details of "the CI > > changes". > > > > > > > > > > > > > > > > > > > > From CI standpoint, adding kie-tools build into > build-chain > > > > > > > > configuration > > > > > > > > > > for drools/optaplanner/kogito-runtimes/kogito-apps is > > > possible. > > > > > > There > > > > > > > > would > > > > > > > > > > be adjustments needed for the examples to reference a > > > "local" image > > > > > > > > created > > > > > > > > > > during the same CI build, but that should be fine. The > > > execution > > > > > > > times > > > > > > > > > > would be extended by the time needed to build kie-tools > > > images due > > > > > > to > > > > > > > > > > repository changes up the stream (drools,...), but that's > > > closing a > > > > > > > > serious > > > > > > > > > > gap we have in the builds, so I don't worry too much. > > > > > > > > > > > > > > > > > > > > What implications this would have on kie-tools > > > pr-check/nightly > > > > > > > builds > > > > > > > > I > > > > > > > > > > don't know, it's a different CI solution from the rest. > > > > > > > > > > > > > > > > > > > > But as mentioned by others here - we need to clarify what > > is > > > our > > > > > > > > ultimate > > > > > > > > > > goal, which hugely affects CI. > > > > > > > > > > > > > > > > > > > > I have mentioned build-chain which is by many people > > > regarded as > > > > > > > > > > (un)necessary evil. I just want to highlight that when we > > > keep many > > > > > > > > > > repositories, then a solution without build-chain would > be > > a > > > > > > > > non-trivial > > > > > > > > > > effort comparable to the initial CI configuration after > the > > > > > > > repository > > > > > > > > > > transfer. Which I do not volunteer for. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > On Thu, 9 Jan 2025 at 07:20, Paolo Bizzarri < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > I do not think this is the correct approach. > > > > > > > > > > > > > > > > > > > > > > If we have a window with a broken glass, we can decide > to > > > use a > > > > > > > > newspaper > > > > > > > > > > > to close the hole because we do not have the money to > > > purchase a > > > > > > > new > > > > > > > > > > glass. > > > > > > > > > > > But this does not mean that using a newspaper is a good > > > strategy > > > > > > to > > > > > > > > fix a > > > > > > > > > > > window. > > > > > > > > > > > > > > > > > > > > > > So, first and foremost we should decide which is the > > ideal > > > > > > > situation > > > > > > > > > > where > > > > > > > > > > > we want to move our repos - one repo, two repo, many > > > repos. With > > > > > > > > ideal > > > > > > > > > > > situation I mean "what we think is the best > > architecture". > > > > > > > > > > > > > > > > > > > > > > Then we decide which steps we want to take in which > > > direction. > > > > > > > > > > > > > > > > > > > > > > WRT resources - i.e. time of people for fixing this or > > > that. It > > > > > > is > > > > > > > > very > > > > > > > > > > > hard to commit to "something" when it is not clear what > > is > > > this > > > > > > > > > > > "something". In our case, it is hard for me to commit > to > > > > > > > > "investigate CI > > > > > > > > > > > options" when it is pretty unclear which is the > situation > > > we want > > > > > > > to > > > > > > > > > > > achieve. > > > > > > > > > > > > > > > > > > > > > > As far as I remember, there have been multiple threads > in > > > the > > > > > > past > > > > > > > > months > > > > > > > > > > > where it is pretty clear that there is no agreement on > > the > > > > > > general > > > > > > > > > > > structure of repos and dependencies. > > > > > > > > > > > > > > > > > > > > > > Let's clarify first this, and then move forward. > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > Paolo > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 9:53 PM Alex Porcelli < > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > I'd agree to remove the link with tools if we'd > remove > > > the > > > > > > tools > > > > > > > > > > > > dependencies from the examples.... otherwise it > creates > > > the > > > > > > > > cyclical > > > > > > > > > > > > dependency - which was the reason Examples was > excluded > > > from > > > > > > the > > > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > I'm also happy if anyone here volunteers to explore > the > > > > > > > adjustments > > > > > > > > > > > > needed in the CI suggested by you... I'm also happy > > with > > > that. > > > > > > > > > > > > > > > > > > > > > > > > But in the end I expect that we get into a solution, > in > > > a way > > > > > > or > > > > > > > > > > > > another. I'd like to propose to use the general 72 > > hours > > > (as > > > > > > > > commonly > > > > > > > > > > > > used in Apache) to see if we get any volunteers to > take > > > on CI > > > > > > > > work. If > > > > > > > > > > > > we can't get it, I'd suggest narrowing the options to > > > either > > > > > > > adjust > > > > > > > > > > > > examples (remove dependencies to artifacts produced > by > > > tools > > > > > > > repo) > > > > > > > > or > > > > > > > > > > > > move the examples somewhere else. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 3:41 PM Francisco Javier > Tirado > > > Sarti > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > I would argue that examples depend more directly on > > > runtimes, > > > > > > > > apps or > > > > > > > > > > > > > drools than in tools or images, basically because a > > > > > > regression > > > > > > > in > > > > > > > > > > tools > > > > > > > > > > > > > code will hardly make any example IT to fail, but a > > > > > > regression > > > > > > > in > > > > > > > > > > > > runtimes, > > > > > > > > > > > > > apps or drools will certainly cause almost all > > > examples to > > > > > > > > > > malfunction. > > > > > > > > > > > > In > > > > > > > > > > > > > fact, in most cases, tool dependency is just an > > > optional > > > > > > add-on > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > > > > example, it's not part of the core functionality of > > the > > > > > > > example. > > > > > > > > A > > > > > > > > > > > proof > > > > > > > > > > > > of > > > > > > > > > > > > > that is that if the tool dependency is removed, > most > > > examples > > > > > > > > will > > > > > > > > > > > still > > > > > > > > > > > > > work (without the fancy graphical tool, but will > > still > > > work). > > > > > > > So, > > > > > > > > > > from > > > > > > > > > > > > that > > > > > > > > > > > > > point of view, it is kind of strange that examples > > are > > > moved > > > > > > > > > > precisely > > > > > > > > > > > to > > > > > > > > > > > > > the repo they have the weaker link to (I'm not > > arguing > > > to > > > > > > > remove > > > > > > > > the > > > > > > > > > > > > > dependency because I feel tools are a pivotal part > of > > > the > > > > > > > > platform > > > > > > > > > > that > > > > > > > > > > > > > makes a difference and we want to showcase that in > > our > > > > > > > > examples). We > > > > > > > > > > > also > > > > > > > > > > > > > have a couple of examples that, trying to > illustrate > > > k8s > > > > > > usage > > > > > > > > (which > > > > > > > > > > > is > > > > > > > > > > > > > also pivotal, but not strictly needed, because the > > > platform > > > > > > > also > > > > > > > > runs > > > > > > > > > > > on > > > > > > > > > > > > > baremetal), are really required to be executed > after > > > > > > everything > > > > > > > > else > > > > > > > > > > > has > > > > > > > > > > > > > been compiled, tested and deployed. > > > > > > > > > > > > > With that in mind, I think that moving stuff to the > > > last > > > > > > > > repository > > > > > > > > > > in > > > > > > > > > > > > the > > > > > > > > > > > > > chain (because I guess that's the reason Tools was > > the > > > chosen > > > > > > > > one) > > > > > > > > > > > should > > > > > > > > > > > > > be a kind of last resort, we need to explore the CI > > > issue > > > > > > > first. > > > > > > > > > > Maybe > > > > > > > > > > > it > > > > > > > > > > > > > is not that hard (for a person with enough > knowledge > > > of the > > > > > > > > internals > > > > > > > > > > > of > > > > > > > > > > > > > the CI pipeline, I'm clearly not that person) to > > > execute > > > > > > > > examples at > > > > > > > > > > > the > > > > > > > > > > > > > end of the CI pipeline. And definitely branching > > > examples > > > > > > repo > > > > > > > > for > > > > > > > > > > > > release > > > > > > > > > > > > > at the same time than the other repos should not > be a > > > huge > > > > > > > > problem > > > > > > > > > > > either > > > > > > > > > > > > > and I think it can be done independently of the CI > > > order > > > > > > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 8:17 PM Alex Porcelli < > > > > > > [email protected] > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Francisco, I think some clarifications are > needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > By “properly maintained,” I’m referring to > examples > > > that > > > > > > are > > > > > > > > fully > > > > > > > > > > > > > > integrated into our CI pipeline and constantly > > > updated to > > > > > > > > track the > > > > > > > > > > > > > > project’s versions, including release versions. > In > > > my view, > > > > > > > > > > ensuring > > > > > > > > > > > > > > that examples work not just with 999-SNAPSHOT but > > > also > > > > > > > released > > > > > > > > > > > > > > versions is critical. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding Snapshot Usage, while having examples > > > > > > automatically > > > > > > > > point > > > > > > > > > > > to > > > > > > > > > > > > > > 999-SNAPSHOT is helpful for early testing, we > need > > > to be > > > > > > > > cautious. > > > > > > > > > > > > > > Apache guidelines discourage the promotion of > > > snapshot > > > > > > > > artifacts > > > > > > > > > > as a > > > > > > > > > > > > > > primary means of distribution. Hence, it’s > > important > > > to > > > > > > offer > > > > > > > > > > > examples > > > > > > > > > > > > > > that align with actual release versions as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Current CI Limitations, although the examples > repo > > is > > > > > > > nominally > > > > > > > > > > > > > > integrated into CI for the runtimes and apps, the > > > setup is > > > > > > > not > > > > > > > > > > > > > > functioning as intended. Many examples require > > DevUI > > > or > > > > > > > > container > > > > > > > > > > > > > > images built in the kie-tools repository, which > > > aren’t > > > > > > fully > > > > > > > > > > captured > > > > > > > > > > > > > > in the current pipeline. This makes it difficult > to > > > trust > > > > > > CI > > > > > > > > > > results > > > > > > > > > > > > > > entirely. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And finally, my last proposal includes relocating > > the > > > > > > > examples > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > > > > > kie-tools repo (under an /examples folder) so > they > > > can be > > > > > > > > > > developed, > > > > > > > > > > > > > > built, and tested alongside the assets they > depend > > on > > > > > > (DevUI, > > > > > > > > > > > > > > container images, etc.). And part of this move, I > > > commit > > > > > > > > myself to > > > > > > > > > > > > > > adjust the release CI to produce a dedicated > > > “examples > > > > > > > > artifact”. > > > > > > > > > > > This > > > > > > > > > > > > > > should resolve the dependency and version-sync > > > issues while > > > > > > > > still > > > > > > > > > > > > > > allowing us to release the examples separately. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I hope these clarifications help. Please let me > > know > > > if you > > > > > > > > have > > > > > > > > > > any > > > > > > > > > > > > > > questions or concerns. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 4:55 AM Francisco Javier > > > Tirado > > > > > > Sarti > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > We need to define "properly maintained" ;). > > > Currently, > > > > > > > > examples > > > > > > > > > > > repo > > > > > > > > > > > > is > > > > > > > > > > > > > > > integrated into the CI pipeline for runtimes > and > > > apps. > > > > > > This > > > > > > > > means > > > > > > > > > > > > that if > > > > > > > > > > > > > > > some change in runtimes or apps repos breaks an > > > example, > > > > > > > the > > > > > > > > PR > > > > > > > > > > > will > > > > > > > > > > > > be > > > > > > > > > > > > > > red > > > > > > > > > > > > > > > and won't be merged. > > > > > > > > > > > > > > > That's another layer of "security" from a > quality > > > > > > > > perspective and > > > > > > > > > > > > forces > > > > > > > > > > > > > > us > > > > > > > > > > > > > > > to keep examples working. > > > > > > > > > > > > > > > They are also a good way for community users to > > > test the > > > > > > > > latest > > > > > > > > > > > > changes > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > main before they are released. If they checkout > > > main > > > > > > > branch, > > > > > > > > > > since, > > > > > > > > > > > > by > > > > > > > > > > > > > > > default, examples on main point to 999-SNAPSHOT > > > version, > > > > > > > they > > > > > > > > > > will > > > > > > > > > > > be > > > > > > > > > > > > > > using > > > > > > > > > > > > > > > latest snapshot, which is a good alternative > for > > > users > > > > > > that > > > > > > > > do > > > > > > > > > > not > > > > > > > > > > > > want > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > wait for a release to perform experiments. > > > > > > > > > > > > > > > Therefore, I think your latest proposal is > great. > > > We keep > > > > > > > > > > > everything > > > > > > > > > > > > as > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > is and release examples separately. > > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 1:17 AM Alex Porcelli < > > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for sharing your perspective, > Francisco. > > > You > > > > > > > raise a > > > > > > > > > > valid > > > > > > > > > > > > > > > > point about user experience; however having a > > > dedicated > > > > > > > > > > examples > > > > > > > > > > > > repo > > > > > > > > > > > > > > > > doesn’t necessarily help if it isn’t properly > > > > > > > > maintained—what’s > > > > > > > > > > > the > > > > > > > > > > > > > > > > purpose of an examples repository if it > doesn’t > > > > > > reference > > > > > > > > the > > > > > > > > > > > > current > > > > > > > > > > > > > > > > release? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One idea to address this, which we could > borrow > > > from > > > > > > our > > > > > > > > IBM > > > > > > > > > > > > > > > > colleagues, is to create a separate release > > > artifact > > > > > > for > > > > > > > > the > > > > > > > > > > > > examples. > > > > > > > > > > > > > > > > We could then publish the artifact content > > into a > > > > > > > dedicated > > > > > > > > > > > > repository > > > > > > > > > > > > > > > > manually whenever we cut a release. This way: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Maintenance & Integration: We still > integrate > > > the > > > > > > > > examples in > > > > > > > > > > > our > > > > > > > > > > > > > > > > main build process (so they remain aligned > with > > > each > > > > > > > > release). > > > > > > > > > > > > > > > > - User-Friendly Browsing: At the same time, > the > > > > > > > standalone > > > > > > > > > > > examples > > > > > > > > > > > > > > > > repository remains easy to browse, avoiding > the > > > > > > > complexity > > > > > > > > of a > > > > > > > > > > > > large, > > > > > > > > > > > > > > > > all-in-one codebase. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This approach keeps the examples maintained > in > > > sync > > > > > > with > > > > > > > > > > releases > > > > > > > > > > > > > > > > while offering a simpler path for users to > find > > > and > > > > > > > explore > > > > > > > > > > them > > > > > > > > > > > > > > > > without wading through the entire repository > > > > > > > > structure—which > > > > > > > > > > can > > > > > > > > > > > be > > > > > > > > > > > > > > > > overwhelming. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I volunteer myself to adjust the CI to > produce > > > this > > > > > > > > artifact in > > > > > > > > > > > the > > > > > > > > > > > > > > > > release pipeline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 7, 2025 at 6:51 AM Francisco > Javier > > > Tirado > > > > > > > > Sarti > > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > I can see why it is easier, from a > technical > > > point of > > > > > > > > view, > > > > > > > > > > > since > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > > > examples rely on tooling, to move all > > examples > > > to > > > > > > > tooling > > > > > > > > > > repo. > > > > > > > > > > > > > > > > > However, I hardly see why this makes users' > > > > > > experience > > > > > > > > > > better. > > > > > > > > > > > > > > > > > Let me elaborate, With examples repo, we > > > currently > > > > > > > have a > > > > > > > > > > place > > > > > > > > > > > > where > > > > > > > > > > > > > > > > users > > > > > > > > > > > > > > > > > can browse all examples starting from the > > repo > > > root. > > > > > > > > > > > > > > > > > With tooling repo, I guess they will start > > > browsing > > > > > > > under > > > > > > > > > > > > examples > > > > > > > > > > > > > > > > > directory? > > > > > > > > > > > > > > > > > If we are going for technical simplicity, I > > > guess it > > > > > > is > > > > > > > > > > > probably > > > > > > > > > > > > > > time to > > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > coherent and move all KIE content under the > > > same repo > > > > > > > > (I'm > > > > > > > > > > not > > > > > > > > > > > > for > > > > > > > > > > > > > > it, > > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > I have the feeling that there is a majority > > in > > > favour > > > > > > > of > > > > > > > > > > that, > > > > > > > > > > > so > > > > > > > > > > > > > > > > probably > > > > > > > > > > > > > > > > > time to vote?). > > > > > > > > > > > > > > > > > Which I feel is really awkward is to have > > > different > > > > > > > > > > strategies > > > > > > > > > > > > under > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > same label (some content in some separate > > > repos and > > > > > > > > gradually > > > > > > > > > > > > moving > > > > > > > > > > > > > > > > > everything to a repo named "tools" which is > > not > > > > > > really > > > > > > > > just > > > > > > > > > > > > "tools" > > > > > > > > > > > > > > > > > anymore) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 6, 2025 at 5:26 PM Jason Porter > > > > > > > > > > > > <[email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I know it makes for a larger repo, but > I’m > > > all for > > > > > > > > fewer > > > > > > > > > > > > > > repositories, > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > an easier setup for not only > contributors, > > > but all > > > > > > > > users. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Jason Porter > > > > > > > > > > > > > > > > > > Software Engineer > > > > > > > > > > > > > > > > > > He/Him/His > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IBM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Alex Porcelli <[email protected] > > > > > > > > > > > > > > > > > > > > Date: Monday, January 6, 2025 at 03:01 > > > > > > > > > > > > > > > > > > To: [email protected] < > [email protected] > > > > > > > > > > > > > > > > > > > > > Subject: [EXTERNAL] [DISCUSS] Missing > > > > > > kogito-examples > > > > > > > > > > update > > > > > > > > > > > > for > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > 10.0.0 release! > > > > > > > > > > > > > > > > > > Happy new 2025, everyone! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As we discussed when we started the > 10.0.0 > > > release > > > > > > > > process, > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > kogito-examples repository was neither > > > included in > > > > > > > the > > > > > > > > > > > release > > > > > > > > > > > > nor > > > > > > > > > > > > > > > > fully > > > > > > > > > > > > > > > > > > integrated into CI. Although some PR > checks > > > > > > consider > > > > > > > > > > > > > > kogito-examples, > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > gap ultimately led to absent examples for > > the > > > > > > 10.0.0 > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - The stable branch remains on versions > > 1.44 > > > and > > > > > > 8.44 > > > > > > > > > > > > > > > > > > - The main branch is on 999-SNAPSHOT > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Given that many of the kogito-examples > rely > > > on > > > > > > > > container > > > > > > > > > > > > images and > > > > > > > > > > > > > > > > Dev UI, > > > > > > > > > > > > > > > > > > we'd need to incorporate the repository > > into > > > our CI > > > > > > > > system > > > > > > > > > > to > > > > > > > > > > > > > > improve > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > current situation, which might take some > > > time and > > > > > > > will > > > > > > > > > > likely > > > > > > > > > > > > > > impact > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > upcoming releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alternatively, we could move the examples > > to > > > > > > > kie-tools > > > > > > > > (a > > > > > > > > > > > repo > > > > > > > > > > > > that > > > > > > > > > > > > > > > > already > > > > > > > > > > > > > > > > > > hosts all images and DevUI) so no CI > > changes > > > would > > > > > > be > > > > > > > > > > > required. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would love to hear your thoughts, > > > alternative > > > > > > > ideas, > > > > > > > > or > > > > > > > > > > > > concerns > > > > > > > > > > > > > > so > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > can have an actionable plan to do better > in > > > the > > > > > > next > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > >
