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?>). > > > > > > 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] > >
