It's not the downstream repos responsibility to expose failures upstream. It's the opposite. No repo should have the ability to EVER stop downstream contributions. Be it unintentional or not.
On Fri, May 10, 2024 at 11:25 AM Gabriele Cardosi <[email protected]> wrote: > > Hi Francisco, > I'll give you an example I recently stumbled upon. > The generated rest endpoints also expose some json (the schema) and this > json depends on the model itself. > Changing the version of DMN, the required schema also gets modified. > But, then, the tooling code would not be able to correctly manage it > anymore. > In that specific case I'm pretty sure the snapshot would have break the ui. > Another point could be with the jitexecutor, whose behavior (and then > returned object) could be changed, breaking - again - ui. > Those are just a couple examples that come to my mind. > As you said, they are exposed through REST interfaces, but inside the > objects that are sent, it is easy to inadvertently introduce breaking > changes (e.g. change a String with a Number as identifier: it could be > dealt transparently by backend code, but it may have bad impact on tool > side) > Of course those are/should be easy to fix, but nevertheless could be an > unwanted problem, for the guys that maybe are working on something else and > suddenly have this to fix. > So, on one side I see the point of testing kie-tools with backend > snapshots, to find problems as early as possible; on the other side, I see > how this could impact the work on tooling side. > > I hope my POV could make sense... > > Il giorno ven 10 mag 2024 alle ore 17:06 Francisco Javier Tirado Sarti < > [email protected]> ha scritto: > > > HI Gabrielle, > > This is an interesting philosophical discussion. I agree that being a front > > developer requires different skills than being a backend developer. I often > > discuss with my science computing friends that the full stack developer > > does not exist (as the footballer that can use the two legs evenly ;)). > > Even if some of us are capable of working more or less efficiently on both > > sides, the truth is that we will always be more efficient as front or back > > (maybe twenty years ago, when UI were developed as standalone applications > > in C or Java there was not so clear distinction, but web applications (CSS > > mayhem), the emergence of several REACT javascript libraries and REST > > interfaces changed everything) > > That I believe justify keeping backend content in one repo and front end > > content in another repo. > > But what I'm discussing is something different. What I do not really get is > > what is the problem of testing tooling against mutable snapshot. Especially > > when the interface between front and back is based, or should be based, on > > loosely coupled REST interfaces. I hardly see how any change (except the > > ones affecting REST interface, which will be very rarely changed at this > > stage) in runtimes can affect tooling. So I feel we are imposing a > > condition on the software which is not really needed. > > > > On Fri, May 10, 2024 at 3:15 PM Gabriele Cardosi < > > [email protected]> > > wrote: > > > > > Hi Francisco, > > > I also have the same impression about sort of ambiguity and decisions not > > > made from the beginning. > > > I've worked on both the tooling side and the backend, and believe me it > > is > > > not just "fix as soon as happen" because, in the meantime, there are > > other > > > things/priorities to be after. > > > To be fair, the tooling guys are already after a big task, and I see > > their > > > need to avoid problems as much as possible. > > > And that me saying "their need" somehow suggests that there is actually > > > this sort of separation, due to the completely different architectural > > > scope, technical stack, etc. > > > Maybe first of all we should clearly identify all those details > > > > > > > > > > > > > > > Il giorno ven 10 mag 2024 alle ore 14:56 Francisco Javier Tirado Sarti < > > > [email protected]> ha scritto: > > > > > > > Alex, > > > > I'm just asking for a real use case example of how a change in the back > > > end > > > > can disrupt more the work of tooling than a change in KIE API can > > disrupt > > > > runtime work. > > > > I believe we are creating an artificial distinction between tooling and > > > the > > > > rest of the software based on historical reasons that no longer apply > > > once > > > > we are moving to a single release. > > > > Either we really justify that distinction on technical ground (which so > > > > far, despite tons of text, in my humble opinion, has not been done) or > > we > > > > change our mindset to the fact that we are now within a single release > > > > paradigm. > > > > And, recurring to history, as some wise man used to say, " A house > > > divided > > > > cannot stand" ;) > > > > > > > > On Fri, May 10, 2024 at 2:50 PM Alex Porcelli <[email protected]> > > wrote: > > > > > > > > > Francisco, > > > > > > > > > > You're minimizing the disruption in others' planned workload. You > > > > > can't just break other's work and say that sooner the better.. if > > > > > others have to fix, it's up to others define when to fix. > > > > > > > > > > On Fri, May 10, 2024 at 8:48 AM Francisco Javier Tirado Sarti > > > > > <[email protected]> wrote: > > > > > > > > > > > > Gabrielle, > > > > > > I think a real use case example where a change in the backend > > breaks > > > > > > tooling work in a way they are fully blocked. > > > > > > And, I would argue, if such thing ever occur, then as soon as we > > > detect > > > > > > that, the better. > > > > > > Just an example, let's say we change a REST endpoint in a way, > > > runtime > > > > > > tooling stops working, the sooner we realize that change is not > > > > > compatible > > > > > > with the tool, the better. > > > > > > > > > > > > On Fri, May 10, 2024 at 12:57 PM Gabriele Cardosi < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Hi Enrique, > > > > > > > I'm ignoring anything else, but regarding > > > > > > > > > > > > > > "The other topic you are talking is the build. The question was > > > > > summarized > > > > > > > by Francisco.if we build the repos in order, does kie tool able > > to > > > > > build > > > > > > > properly with the snapshots built in the pipeline or does need > > > > > additional > > > > > > > steps ?" > > > > > > > > > > > > > > I think the core of the problem is the following: > > > > > > > when we backender made a modification (e.g. in drools repo) we > > are > > > > > somehow > > > > > > > responsible to fix eventual break downstream (e.g. > > kogito-runtimes, > > > > > > > kogito-examples, etc), but we completely ignores the tooling, and > > > we > > > > > won't > > > > > > > probably be able to fix it. So, the tooling guys must rely on > > some > > > > > "stable" > > > > > > > version, otherwise we could break their work on a daily basis. > > > > > > > This is more or less the situation I found when I joined: the > > > drools > > > > > built > > > > > > > was separated from the drools-wb one, sometimes modification on > > > > drools > > > > > repo > > > > > > > broke drools-wb, and then they decided to pipeline the twos, to > > > have > > > > > > > immediate recognition, and fix, of that (at that time, our > > > drools-wb > > > > > job > > > > > > > was to build drools every morning and then start working on > > > > drools-wb: > > > > > if > > > > > > > something get broken in drools-wb, then we pinged drool devs to > > > > > understand > > > > > > > reason and eventually make fix). > > > > > > > The solutions I see for our situation are: > > > > > > > > > > > > > > 1. keep tooling depend on some stable release, preserving > > > > > independence > > > > > > > from backender changes > > > > > > > 2. enforce/improve cooperation between backender and tooling > > > guys, > > > > > so > > > > > > > that as soon as some breaking change is made by the former, > > the > > > > > latter > > > > > > > can > > > > > > > immediately fix > > > > > > > > > > > > > > > > > > > > > Side notes: > > > > > > > > > > > > > > 1. About point 1, I do not think it breaks the "single > > product" > > > > > rule, > > > > > > > because at release time everything should be aligned > > > > > > > 2. About point 2, I'm not sure it is so easy to do > > > > > > > 3. IMO this is completely transparent regarding where the > > code > > > > > lives, > > > > > > > and "single CI" means a single build system that properly > > > manages > > > > > the > > > > > > > code > > > > > > > to build > > > > > > > > > > > > > > Sorry if all the above was already clear and obvious to everyone > > 😀 > > > > > > > > > > > > > > Best > > > > > > > > > > > > > > Gabriele > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno ven 10 mag 2024 alle ore 12:08 Enrique Gonzalez > > Martinez > > > < > > > > > > > [email protected]> ha scritto: > > > > > > > > > > > > > > > Hi Alex > > > > > > > > > > > > > > > > You are mixing stuff here Alex. > > > > > > > > > > > > > > > > PR checks are there for guarding that nothing breaks when > > > somebody > > > > is > > > > > > > > pushing code. If kie tools can break because is not there it > > > means > > > > we > > > > > > > have > > > > > > > > a problem in there. Keep in mind i am not talking about the > > cause > > > > why > > > > > > > they > > > > > > > > are missing checks in our PR, it could be resources it could be > > > > > something > > > > > > > > else. > > > > > > > > > > > > > > > > The other topic you are talking is the build. The question was > > > > > summarized > > > > > > > > by Francisco.if we build the repos in order, does kie tool able > > > to > > > > > build > > > > > > > > properly with the snapshots built in the pipeline or does need > > > > > additional > > > > > > > > steps ? > > > > > > > > > > > > > > > > > > > > > > > > Publishing artifacts is a whole different topic from the build. > > > > > Regarding > > > > > > > > sync multiple deployments from the multirepo build i guess it > > > could > > > > > be a > > > > > > > > problem, but also that is not the question here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El vie, 10 may 2024, 11:55, Alex Porcelli <[email protected]> > > > > > escribió: > > > > > > > > > > > > > > > > > Tiago already provided a in-depth explanation of the issue in > > > > this > > > > > ML, > > > > > > > > > that is summarized in the circular dependency thread [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > TL;DR: **Today** KIE-Tools is not part of any PR checks in > > the > > > > > runtime > > > > > > > > > repositories (drools, optaplanner, runtimes and apps) - so a > > > > > change in > > > > > > > > > those repos can break KIE Tools. If we were to continue to > > use > > > > > > > > > SNAPSHOTs, we need unify to a single CI that would include > > all > > > > > > > > > repositories - including KIE Tools. > > > > > > > > > > > > > > > > > > [1] - > > > > > https://lists.apache.org/thread/58xm7pqdyztf7qztmhvntf8wdmvfx7jx > > > > > > > > > > > > > > > > > > On Fri, May 10, 2024 at 5:15 AM Francisco Javier Tirado Sarti > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > Hi Tiago, > > > > > > > > > > I would argue that, being all the repos part of the same > > > > release, > > > > > > > > mutable > > > > > > > > > > snapshot is perfectly acceptable. As it currently happens > > > > between > > > > > > > > > Runtimes > > > > > > > > > > repo and Drools repo (which have the Kie api) and Apps repo > > > and > > > > > > > > Runtimes > > > > > > > > > > repo. I, as I believe Enrique (at least if what I > > understood > > > > > from his > > > > > > > > > > e-mail) , do not understand why tooling should be different > > > in > > > > > that > > > > > > > > > regard. > > > > > > > > > > > > > > > > > > > > On Fri, May 10, 2024 at 1:26 AM Tiago Bento < > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Zanini and Enrique, > > > > > > > > > > > > > > > > > > > > > > Not sure if I'm making it sound differently, but > > everything > > > > I'm > > > > > > > > saying > > > > > > > > > > > is also aiming towards a healthy CI. Not only for > > > SonataFlow > > > > or > > > > > > > > Tools, > > > > > > > > > > > though. For all of Apache KIE. > > > > > > > > > > > > > > > > > > > > > > My main point is that mutable Maven SNAPSHOTs are harming > > > us, > > > > > > > giving > > > > > > > > a > > > > > > > > > > > false impression of synchronization between the repos. > > It's > > > > an > > > > > > > "easy > > > > > > > > > > > way out" we've been historically abusing, IMHO. > > > > > > > > > > > > > > > > > > > > > > One of the best advantages of having multiple repos is > > that > > > > > they > > > > > > > can > > > > > > > > > > > be individually developed, tested, and managed. However, > > by > > > > > using > > > > > > > > > > > Maven SNAPSHOTs as the synchronization mechanism, we > > can't > > > > > > > guarantee > > > > > > > > > > > that, since repos become broken on any given day. More > > than > > > > > that, > > > > > > > > it's > > > > > > > > > > > impossible to go "back in time" on our development > > > branches, > > > > > since > > > > > > > > the > > > > > > > > > > > SNAPSHOT version will always point to latest. > > > > > > > > > > > > > > > > > > > > > > Please read this section from the guidelines of the > > SciJava > > > > > project > > > > > > > > at > > > > > > > > > > > > > > > > https://github.com/scijava/pom-scijava-base/blob/main/README.md. > > > > > > > > > > > > > > > > > > > > > > "Reproducible builds. This rule means no SNAPSHOT > > > > > dependencies, no > > > > > > > > > > > SNAPSHOT parents, and no SNAPSHOT plugin versions. A > > > snapshot > > > > > > > version > > > > > > > > > > > is not immutable, which means that code which depends on > > a > > > > > snapshot > > > > > > > > > > > may build today, but not build tomorrow, if the snapshot > > is > > > > > later > > > > > > > > > > > changed. The best way to avoid this conundrum is to never > > > > > depend on > > > > > > > > > > > SNAPSHOT versions. Snapshot are best used for testing > > only; > > > > > they > > > > > > > can > > > > > > > > > > > be used transiently, but their use should never make it > > > onto > > > > > the > > > > > > > main > > > > > > > > > > > integration branch (e.g., main or master) of a project. > > See > > > > > also > > > > > > > > Using > > > > > > > > > > > snapshot couplings during development at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://imagej.net/develop/architecture#using-snapshot-couplings-during-development > > > > > > > > > > > ." > > > > > > > > > > > > > > > > > > > > > > This summarizes very well the problem I'm trying to > > convey > > > > > here. Of > > > > > > > > > > > course, their words are much more clear than all the > > > > > explanations I > > > > > > > > > > > tried giving so far. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 9, 2024 at 9:43 AM ricardo zanini fernandes > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Tiago, > > > > > > > > > > > > > > > > > > > > > > > > Again, this is a major problem in our current structure > > > > that > > > > > we > > > > > > > > > should > > > > > > > > > > > use > > > > > > > > > > > > another thread to discuss. For my proposal is to at > > least > > > > > have a > > > > > > > > > health > > > > > > > > > > > > cloud build platform. We can completely remove UI from > > > our > > > > > images > > > > > > > > in > > > > > > > > > the > > > > > > > > > > > > SonataFlow space and keep the consoles in kie-tools. > > Once > > > > we > > > > > > > solve > > > > > > > > > the > > > > > > > > > > > deep > > > > > > > > > > > > structural problem we have, we can evaluate it better. > > > What > > > > > we > > > > > > > > can't > > > > > > > > > do > > > > > > > > > > > is > > > > > > > > > > > > be behind and not release. > > > > > > > > > > > > > > > > > > > > > > > > The template image is pretty useful if you really want > > to > > > > > test > > > > > > > the > > > > > > > > > DevUI > > > > > > > > > > > in > > > > > > > > > > > > the image. You can easily pull the container file and > > > build > > > > > the > > > > > > > > image > > > > > > > > > > > > during your integration tests and run the tests you > > need. > > > > We > > > > > can > > > > > > > do > > > > > > > > > the > > > > > > > > > > > > same in the image. I don't see a waste of resources, > > but > > > > as a > > > > > > > > > temporary > > > > > > > > > > > > alternative until we figure out the deeper problem. > > > > > > > > > > > > > > > > > > > > > > > > At the moment, everything "tools" related is in a > > single > > > > > repo and > > > > > > > > the > > > > > > > > > > > other > > > > > > > > > > > > components are scattered in many other repos. We have > > to > > > > > decide > > > > > > > if > > > > > > > > we > > > > > > > > > > > want > > > > > > > > > > > > mono repos (infra-oriented) or context repos > > > > > (feature-oriented). > > > > > > > We > > > > > > > > > can't > > > > > > > > > > > > have both otherwise the mono repos will start to drag > > > > others > > > > > to > > > > > > > it, > > > > > > > > > as we > > > > > > > > > > > > are seeing happening. > > > > > > > > > > > > > > > > > > > > > > > > So IMO, we need first to sit down together and have a > > new > > > > > repo > > > > > > > > > structure > > > > > > > > > > > > design, perhaps based on components. We need to > > evaluate. > > > > > > > > > > > > > > > > > > > > > > > > For the time being, we need to move forward at least > > and > > > I > > > > > can > > > > > > > live > > > > > > > > > with > > > > > > > > > > > > integration tests at the end of the line using final > > > > > > > versions/built > > > > > > > > > > > > versions of the DevUI if needed for SonataFlow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 9, 2024 at 10:32 AM ricardo zanini > > fernandes > > > < > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Enrique! > > > > > > > > > > > > > > > > > > > > > > > > > > The images are using SNAPSHOTS from apps/runtimes > > > > > currently. > > > > > > > > There > > > > > > > > > was > > > > > > > > > > > a > > > > > > > > > > > > > decision in the past to build apps in the images from > > > the > > > > > > > > > > > main/versioned > > > > > > > > > > > > > branch. We are changing this to use > > SNAPSHOT/versioned > > > > > > > artifacts > > > > > > > > > > > published > > > > > > > > > > > > > in Maven. About kie-tools, I don't know either. > > > > > > > > > > > > > > > > > > > > > > > > > > We can use immutable snapshots (weekly, nightlies) > > > > > instead. I'm > > > > > > > > not > > > > > > > > > > > > > against it. But we do need those for integration > > tests > > > or > > > > > at > > > > > > > > least > > > > > > > > > a > > > > > > > > > > > robust > > > > > > > > > > > > > CI platform to do integration without snapshots. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers! > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 9, 2024 at 5:07 AM Enrique Gonzalez > > > Martinez > > > > < > > > > > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi Tiago, > > > > > > > > > > > > >> > > > > > > > > > > > > >> I think the discussion is related to the graph > > > > dependency > > > > > for > > > > > > > > > now. So > > > > > > > > > > > > >> I would keep that in mind. Anyway I am kinda > > surprised > > > > > about > > > > > > > > some > > > > > > > > > > > > >> concepts like (mutable snapshots and using snapshot > > > > > published > > > > > > > > > > > > >> timestamps like they are final). > > > > > > > > > > > > >> > > > > > > > > > > > > >> Now I think I understand where the problem lies now; > > > so > > > > > > > > basically > > > > > > > > > if > > > > > > > > > > > > >> we had the proper graph dependency project built > > based > > > > on > > > > > > > proper > > > > > > > > > > > > >> snapshots everything would build just ok. So my > > > question > > > > > is > > > > > > > > pretty > > > > > > > > > > > > >> simple, why is it not possible for kie tools or > > kogito > > > > > images > > > > > > > to > > > > > > > > > use > > > > > > > > > > > > >> the maven snapshot concept and point out to the last > > > > > snapshot > > > > > > > > > build > > > > > > > > > > > > >> (either local or remote) like other maven projects > > > work. > > > > > Is > > > > > > > > there > > > > > > > > > any > > > > > > > > > > > > >> limitation there ? > > > > > > > > > > > > >> > > > > > > > > > > > > >> El mié, 8 may 2024 a las 22:30, Tiago Bento (< > > > > > > > > > [email protected]>) > > > > > > > > > > > > >> escribió: > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > Hi Zanini! Welcome back, hope you had a great time > > > > > during > > > > > > > your > > > > > > > > > PTO. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > If I understand correctly, the way you see the > > > > > integration > > > > > > > > > between > > > > > > > > > > > > >> > repos relies heavily on timestamped SNAPSHOTs. > > This > > > > way: > > > > > > > > > > > > >> > 1. `kogito-images` would stop building > > > `kogito-apps`, > > > > > and > > > > > > > > would > > > > > > > > > rely > > > > > > > > > > > > >> > on timestamped SNAPSHOTs being published from > > > > > > > > > > > > >> > `drools/optaplanner/kogito-runtimes/kogito-apps`. > > > > > > > > > > > > >> > 2. `kie-tools` would start publishing timestamped > > > > > SNAPSHOTs > > > > > > > > for > > > > > > > > > its > > > > > > > > > > > UI > > > > > > > > > > > > >> > components, so they would be consumed downstream > > by > > > > > > > > > > > > >> > `kogito-serverless-operator`. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > If that's what you mean, let me elaborate on some > > of > > > > the > > > > > > > > > > > consequences > > > > > > > > > > > > >> > of this integration model, where we stop using the > > > > > mutable > > > > > > > > > > > > >> > 999-SNAPSHOT and start relying more on timestamped > > > > > SNAPSHOTs > > > > > > > > for > > > > > > > > > > > > >> > cross-repo synchronization: > > > > > > > > > > > > >> > a. Cross-repo PRs would not be possible anymore, > > > > > depending > > > > > > > on > > > > > > > > > which > > > > > > > > > > > > >> > repos are involved in the ensemble. This would > > > create > > > > > > > > boundaries > > > > > > > > > > > > >> > between certain groups of our repos, namely: > > > > > > > > > > > > >> > drools/optaplanner/kogito-runtimes/kogito-apps --> > > > > > > > > > kogito-images --> > > > > > > > > > > > > >> > kie-tools, --> kogito-serverless-operator. So 4 > > > > > "independent > > > > > > > > > > > > >> > clusters". > > > > > > > > > > > > >> > b. kogito-images, kie-tools, and > > > > > kogito-serverless-operator, > > > > > > > > > using > > > > > > > > > > > > >> > timestamped SNAPSHOTs between themselves, would > > make > > > > the > > > > > > > most > > > > > > > > > > > upstream > > > > > > > > > > > > >> > of the three (in this case, `kogito-images`), to > > be > > > > the > > > > > one > > > > > > > > > defining > > > > > > > > > > > > >> > what timestamped SNAPSHOT version we should use > > for > > > > its > > > > > > > > upstream > > > > > > > > > > > > >> > dependencies > > > > > > > (drools/optaplanner/kogito-runtimes/kogito-apps). > > > > > > > > > In > > > > > > > > > > > more > > > > > > > > > > > > >> > details: If `kogito-images` depends on > > > > > > > > > > > > >> > `drools/optaplanner/kogito-runtimes/kogito-apps` > > > using > > > > > > > version > > > > > > > > > > > > >> > 999-20240501, that's the version `kie-tools` and > > > > > > > > > > > > >> > `kogito-serverless-operator` need to use as well, > > as > > > > the > > > > > > > > > > > > >> > drools/optaplanner/kogito-runtimes/kogito-apps > > would > > > > > come > > > > > > > > > > > transitively > > > > > > > > > > > > >> > from the `kogito-images` dependency these two > > repos > > > > > would > > > > > > > > have. > > > > > > > > > > > This, > > > > > > > > > > > > >> > IMHO, causes a lot of confusion, since the dates > > on > > > > the > > > > > > > > > timestamped > > > > > > > > > > > > >> > SNAPSHOT versions have implicit transitive > > > > dependencies > > > > > to > > > > > > > > other > > > > > > > > > > > > >> > upstream projects that also have their own > > > timestamped > > > > > > > > SNAPSHOTs > > > > > > > > > > > > >> > published. I.e., 999-20240501 of `kie-tools` won't > > > be > > > > > > > aligned > > > > > > > > > with > > > > > > > > > > > > >> > 999-2024051 of > > > > > > > > `drools/optaplanner/kogito-runtimes/kogito-apps`. > > > > > > > > > > > > >> > c. Updating dependencies across the board would be > > > > much > > > > > more > > > > > > > > > > > > >> > difficult, as we would need to rely on a chain > > > > reaction > > > > > > > > starting > > > > > > > > > > > from > > > > > > > > > > > > >> > the > > `drools/optaplanner/kogito-runtimes/kogito-apps` > > > > > cluster > > > > > > > > > all the > > > > > > > > > > > > >> > way down to `kogito-serverless-operator`, > > releasing > > > > > > > > timestamped > > > > > > > > > > > > >> > SNAPSHOTs and sending PRs for each "cluster" along > > > the > > > > > way. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > I'm not sure this is the way we want to move > > > forward, > > > > > to be > > > > > > > > > honest, > > > > > > > > > > > as > > > > > > > > > > > > >> > these consequences need to be thoroughly examined > > by > > > > > people > > > > > > > in > > > > > > > > > the > > > > > > > > > > > > >> > community, so that all the side-effects of this > > > choice > > > > > are > > > > > > > > > clear to > > > > > > > > > > > > >> > everyone. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > To conclude, having `kie-tools` building a > > "template > > > > > image" > > > > > > > to > > > > > > > > > > > verify > > > > > > > > > > > > >> > that it will not break > > `kogito-serverless-operator` > > > > > > > > downstream, > > > > > > > > > and > > > > > > > > > > > > >> > having `kogito-serverless-operator` building parts > > > of > > > > > > > > > `kie-tools` to > > > > > > > > > > > > >> > incorporate the latest changes, IMHO, is: > > > > > > > > > > > > >> > 1. Duplication of building logic. IMHO, we can't > > > have > > > > > > > > individual > > > > > > > > > > > repos > > > > > > > > > > > > >> > creating its own up- and downstream CI systems. > > > > > > > > > > > > >> > 2. Conflicting with the timestamped SNAPSHOTs > > > strategy > > > > > for > > > > > > > > > > > integrating > > > > > > > > > > > > >> > repos, where boundaries are clearly defined. > > > > > > > > > > > > >> > 3. Wasteful use of resources (same that is > > happening > > > > > with > > > > > > > > > > > > >> > `kogito-images` building `kogito-apps` right now). > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > I'm sorry for bringing all this to this seemingly > > > > simple > > > > > > > > > proposal, > > > > > > > > > > > but > > > > > > > > > > > > >> > I'm afraid taking steps without knowing where > > we're > > > > > going > > > > > > > > isn't > > > > > > > > > the > > > > > > > > > > > > >> > way to move forward. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > Please let me know if I misunderstood something. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > On Wed, May 8, 2024 at 3:15 PM ricardo zanini > > > > fernandes > > > > > > > > > > > > >> > <[email protected]> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Hi! > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Sorry for the late reply, I was on PTO. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Replies inline. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > The `kie-tools` CI is not prepared to build > > > > > > > > > > > > >> > > `kogito-serverless-operator`, so the way > > > > > > > > > > > `kogito-serverless-operator` > > > > > > > > > > > > >> > > references the SonataFlow Quarkus Dev UI will be > > > > > important > > > > > > > > to > > > > > > > > > > > > >> > > establish the boundaries between both repos. To > > > > > further > > > > > > > > > develop > > > > > > > > > > > the > > > > > > > > > > > > >> > > SonataFlow Quarkus Dev UI and have its changes > > > > > reflect on > > > > > > > > the > > > > > > > > > > > > >> > > `kogito-swf-devmode` image, we need to come up > > > with > > > > a > > > > > > > > strategy > > > > > > > > > > > that is > > > > > > > > > > > > >> > > both safe, consistent, and enforces correctness. > > > > > There's > > > > > > > > also > > > > > > > > > the > > > > > > > > > > > fact > > > > > > > > > > > > >> > > that currently `kie-tools` depends on > > timestamped > > > > > > > SNAPSHOTs > > > > > > > > of > > > > > > > > > > > > >> > > Kogito/Drools, while > > `kogito-serverless-operator` > > > > uses > > > > > > > > > > > 999-SNAPSHOT, > > > > > > > > > > > > >> > > if I'm not mistaken. Can you elaborate a little > > > bit > > > > > more > > > > > > > on > > > > > > > > > how > > > > > > > > > > > you > > > > > > > > > > > > >> > > see this reference being done? Please consider > > > > > cross-repo > > > > > > > > PRs > > > > > > > > > for > > > > > > > > > > > big > > > > > > > > > > > > >> > > migrations like the Quarkus 3.8.4 that is > > > currently > > > > > > > > happening. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > This will make us discuss yet again the need of > > > > > snapshots > > > > > > > > for > > > > > > > > > the > > > > > > > > > > > UI > > > > > > > > > > > > >> > > components used by the images. The images must > > be > > > > the > > > > > end > > > > > > > of > > > > > > > > > the > > > > > > > > > > > build > > > > > > > > > > > > >> > > pipeline, where we aggregate every component we > > > ship > > > > > in a > > > > > > > > > single > > > > > > > > > > > > >> instance > > > > > > > > > > > > >> > > to release. Yet, they are a core part of the > > cloud > > > > > > > platform, > > > > > > > > > hence > > > > > > > > > > > > >> part of > > > > > > > > > > > > >> > > the Operator BDD, testing, integration, and > > > > > delivering. > > > > > > > > > > > Intermediate > > > > > > > > > > > > >> repos > > > > > > > > > > > > >> > > can't depend on them unless they are also > > > > responsible > > > > > for > > > > > > > > > > > maintenance > > > > > > > > > > > > >> and > > > > > > > > > > > > >> > > release like what we're doing with the consoles. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Also, the images can have a respin anytime we > > > need a > > > > > new > > > > > > > > > component > > > > > > > > > > > > >> bump. We > > > > > > > > > > > > >> > > do this all the time to fix CVEs or bug fixes > > in a > > > > > > > specific > > > > > > > > > > > component > > > > > > > > > > > > >> that > > > > > > > > > > > > >> > > is part of the image. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > The devui can be developed and maintained within > > > the > > > > > > > > kie-tools > > > > > > > > > > > repo > > > > > > > > > > > > >> and > > > > > > > > > > > > >> > > have tests that verify that component. The > > > > integration > > > > > > > will > > > > > > > > be > > > > > > > > > > > made > > > > > > > > > > > > >> on the > > > > > > > > > > > > >> > > Images/Operator side once we grab a latest > > > snapshot. > > > > > > > > > > > Alternatively, > > > > > > > > > > > > >> we can > > > > > > > > > > > > >> > > do: > > > > > > > > > > > > >> > > 1. The tools CI can fetch a template image, > > inject > > > > the > > > > > > > > > component, > > > > > > > > > > > and > > > > > > > > > > > > >> run > > > > > > > > > > > > >> > > the required tests > > > > > > > > > > > > >> > > 2. The image/operator CI can fetch and build the > > > UI > > > > > > > > > components and > > > > > > > > > > > > >> run the > > > > > > > > > > > > >> > > integration tests > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > Also, regarding point "4. Review the PR GHA > > > checks > > > > > to > > > > > > > run > > > > > > > > > CLI > > > > > > > > > > > tests > > > > > > > > > > > > >> > > once there's a change in the cmd module" of the > > > > > proposed > > > > > > > > > EPIC, I > > > > > > > > > > > think > > > > > > > > > > > > >> > > we might run into problems, since the `cmd` > > module > > > > > also > > > > > > > > > depends > > > > > > > > > > > on the > > > > > > > > > > > > >> > > `api` and `workflowproj` modules of > > > > > > > > > `kogito-serverless-operator.` > > > > > > > > > > > I'm > > > > > > > > > > > > >> > > afraid changes made to these two modules would > > > also > > > > > need > > > > > > > to > > > > > > > > > > > trigger a > > > > > > > > > > > > >> > > build of the `cmd` module, and they can > > > potentially > > > > > break > > > > > > > > it. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Sorry to not get into details there, but the new > > > cmd > > > > > > > module > > > > > > > > > will > > > > > > > > > > > be > > > > > > > > > > > > >> part of > > > > > > > > > > > > >> > > the Operator's workspace, any changes in any > > cross > > > > > > > > > dependencies > > > > > > > > > > > there > > > > > > > > > > > > >> will > > > > > > > > > > > > >> > > trigger the CI checks, as we are doing today in > > > the > > > > > > > builder > > > > > > > > > and > > > > > > > > > > > > >> > > workflowproj modules. It will be way easier to > > > > > maintain > > > > > > > the > > > > > > > > > CLI. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > These considerations alone, IMHO, expose one > > of > > > > the > > > > > > > > biggest > > > > > > > > > > > > >> challenges > > > > > > > > > > > > >> > > we have in our community right now, which is > > that > > > > the > > > > > > > > > definition > > > > > > > > > > > and > > > > > > > > > > > > >> > > implementation of the dependency graph between > > > > > > > > > > > repos/modules/packages > > > > > > > > > > > > >> > > is currently spread across many different "build > > > > > systems", > > > > > > > > > like > > > > > > > > > > > the > > > > > > > > > > > > >> > > new proposed GHA jobs exclusive to the > > > > > > > > > > > `kogito-serverless-operator` > > > > > > > > > > > > >> > > repo, the Build Chain system we have for the > > > > > Drools/Kogito > > > > > > > > > repos, > > > > > > > > > > > the > > > > > > > > > > > > >> > > `kie-tools` CI, and the many Jenkins jobs we > > have > > > on > > > > > > > > Apache's > > > > > > > > > > > Jenkins. > > > > > > > > > > > > >> > > There's also the fact that we have > > `kogito-images` > > > > > > > > selectively > > > > > > > > > > > > >> > > building parts of `kogito-apps` during its own > > > build > > > > > to > > > > > > > > > include > > > > > > > > > > > them > > > > > > > > > > > > >> > > in the images it produces. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > I agree. We would need to sit together and solve > > > > this > > > > > as a > > > > > > > > > team, > > > > > > > > > > > > >> having a > > > > > > > > > > > > >> > > nice integration across every repo. The > > > > kogito-images > > > > > > > > building > > > > > > > > > > > parts > > > > > > > > > > > > >> of the > > > > > > > > > > > > >> > > apps is something we currently working on, IIRC. > > > The > > > > > apps > > > > > > > > will > > > > > > > > > > > deploy > > > > > > > > > > > > >> a > > > > > > > > > > > > >> > > snapshot as part of the nightlies and the images > > > > will > > > > > be > > > > > > > > > using it. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > I just think it is important to highlight that > > > > this > > > > > > > > proposal > > > > > > > > > > > would > > > > > > > > > > > > >> > > only address a LOCAL problem related exclusively > > > to > > > > > the > > > > > > > > > SonataFlow > > > > > > > > > > > > >> > > section of the Apache KIE community, while, at > > the > > > > > same > > > > > > > > time, > > > > > > > > > not > > > > > > > > > > > > >> > > contributing to reducing the segmentation of the > > > > > Apache > > > > > > > KIE > > > > > > > > > > > community > > > > > > > > > > > > >> > > as a whole. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Yes, the proposal is to starting addressing the > > > > local > > > > > > > Apache > > > > > > > > > KIE > > > > > > > > > > > > >> SonataFlow > > > > > > > > > > > > >> > > Cloud platform first. But I agree that we need > > to > > > > > refactor > > > > > > > > > our CI > > > > > > > > > > > as a > > > > > > > > > > > > >> > > whole, which is something we should start in a > > new > > > > > thread. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Cheers! > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > On Mon, Apr 22, 2024 at 10:02 PM Tiago Bento < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > Zanini and Alex, > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > The task we agreed on for after releasing > > Apache > > > > > KIE 10 > > > > > > > is > > > > > > > > > > > > >> > > > > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/1040. > > > > > > > > > It > > > > > > > > > > > only > > > > > > > > > > > > >> > > > describes deleting the temporary copies we'll > > > have > > > > > on > > > > > > > KIE > > > > > > > > > Tools > > > > > > > > > > > and > > > > > > > > > > > > >> > > > reverting things back to where they were, > > using > > > > the > > > > > > > fixed > > > > > > > > > 10.0.0 > > > > > > > > > > > > >> > > > version. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Moving `kn-plugin-workflow` and the > > > > > > > > > > > `kogito-swf-{devmode,builder}` > > > > > > > > > > > > >> > > > images to `kogito-serverless-operator` would > > be > > > a > > > > > new > > > > > > > > move, > > > > > > > > > > > which I > > > > > > > > > > > > >> > > > understand is the scope of this proposal > > thread. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Doing so, however, will make > > > > > > > `kogito-serverless-operator` > > > > > > > > > > > depend on > > > > > > > > > > > > >> > > > `kie-tools`, since the SonataFlow Quarkus Dev > > UI > > > > is > > > > > > > hosted > > > > > > > > > there > > > > > > > > > > > > >> now, > > > > > > > > > > > > >> > > > and it is a dependency of the > > > `kogito-swf-devmode` > > > > > > > image. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > I'm saying this because I think we need to > > > further > > > > > > > discuss > > > > > > > > > the > > > > > > > > > > > > >> > > > consequences of this change... > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > The `kie-tools` CI is not prepared to build > > > > > > > > > > > > >> > > > `kogito-serverless-operator`, so the way > > > > > > > > > > > > >> `kogito-serverless-operator` > > > > > > > > > > > > >> > > > references the SonataFlow Quarkus Dev UI will > > be > > > > > > > important > > > > > > > > > to > > > > > > > > > > > > >> > > > establish the boundaries between both repos. > > To > > > > > further > > > > > > > > > develop > > > > > > > > > > > the > > > > > > > > > > > > >> > > > SonataFlow Quarkus Dev UI and have its changes > > > > > reflect > > > > > > > on > > > > > > > > > the > > > > > > > > > > > > >> > > > `kogito-swf-devmode` image, we need to come up > > > > with > > > > > a > > > > > > > > > strategy > > > > > > > > > > > that > > > > > > > > > > > > >> is > > > > > > > > > > > > >> > > > both safe, consistent, and enforces > > correctness. > > > > > There's > > > > > > > > > also > > > > > > > > > > > the > > > > > > > > > > > > >> fact > > > > > > > > > > > > >> > > > that currently `kie-tools` depends on > > > timestamped > > > > > > > > SNAPSHOTs > > > > > > > > > of > > > > > > > > > > > > >> > > > Kogito/Drools, while > > > `kogito-serverless-operator` > > > > > uses > > > > > > > > > > > 999-SNAPSHOT, > > > > > > > > > > > > >> > > > if I'm not mistaken. Can you elaborate a > > little > > > > bit > > > > > more > > > > > > > > on > > > > > > > > > how > > > > > > > > > > > you > > > > > > > > > > > > >> > > > see this reference being done? Please consider > > > > > > > cross-repo > > > > > > > > > PRs > > > > > > > > > > > for > > > > > > > > > > > > >> big > > > > > > > > > > > > >> > > > migrations like the Quarkus 3.8.4 that is > > > > currently > > > > > > > > > happening. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Also, regarding point "4. Review the PR GHA > > > checks > > > > > to > > > > > > > run > > > > > > > > > CLI > > > > > > > > > > > tests > > > > > > > > > > > > >> > > > once there's a change in the cmd module" of > > the > > > > > proposed > > > > > > > > > EPIC, I > > > > > > > > > > > > >> think > > > > > > > > > > > > >> > > > we might run into problems, since the `cmd` > > > module > > > > > also > > > > > > > > > depends > > > > > > > > > > > on > > > > > > > > > > > > >> the > > > > > > > > > > > > >> > > > `api` and `workflowproj` modules of > > > > > > > > > > > `kogito-serverless-operator.` > > > > > > > > > > > > >> I'm > > > > > > > > > > > > >> > > > afraid changes made to these two modules would > > > > also > > > > > need > > > > > > > > to > > > > > > > > > > > trigger > > > > > > > > > > > > >> a > > > > > > > > > > > > >> > > > build of the `cmd` module, and they can > > > > potentially > > > > > > > break > > > > > > > > > it. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > These considerations alone, IMHO, expose one > > of > > > > the > > > > > > > > biggest > > > > > > > > > > > > >> challenges > > > > > > > > > > > > >> > > > we have in our community right now, which is > > > that > > > > > the > > > > > > > > > > > definition and > > > > > > > > > > > > >> > > > implementation of the dependency graph between > > > > > > > > > > > > >> repos/modules/packages > > > > > > > > > > > > >> > > > is currently spread across many different > > "build > > > > > > > systems", > > > > > > > > > like > > > > > > > > > > > the > > > > > > > > > > > > >> > > > new proposed GHA jobs exclusive to the > > > > > > > > > > > `kogito-serverless-operator` > > > > > > > > > > > > >> > > > repo, the Build Chain system we have for the > > > > > > > Drools/Kogito > > > > > > > > > > > repos, > > > > > > > > > > > > >> the > > > > > > > > > > > > >> > > > `kie-tools` CI, and the many Jenkins jobs we > > > have > > > > on > > > > > > > > > Apache's > > > > > > > > > > > > >> Jenkins. > > > > > > > > > > > > >> > > > There's also the fact that we have > > > `kogito-images` > > > > > > > > > selectively > > > > > > > > > > > > >> > > > building parts of `kogito-apps` during its own > > > > > build to > > > > > > > > > include > > > > > > > > > > > them > > > > > > > > > > > > >> > > > in the images it produces. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > With all that said, I'm not opposed to moving > > > the > > > > > > > > > > > > >> `kn-workflow-plugin` > > > > > > > > > > > > >> > > > package from `kie-tools` to the `cmd` module > > of > > > > > > > > > > > > >> > > > `kogito-serverless-operator`. In fact, like I > > > said > > > > > in > > > > > > > the > > > > > > > > > past, > > > > > > > > > > > I > > > > > > > > > > > > >> > > > think it makes a lot of sense that they're > > part > > > of > > > > > the > > > > > > > > same > > > > > > > > > > > > >> > > > compilation unit, as they're very closely > > > related, > > > > > and > > > > > > > > > should > > > > > > > > > > > > >> > > > therefore be in sync at all times. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > I just think it is important to highlight that > > > > this > > > > > > > > proposal > > > > > > > > > > > would > > > > > > > > > > > > >> > > > only address a LOCAL problem related > > exclusively > > > > to > > > > > the > > > > > > > > > > > SonataFlow > > > > > > > > > > > > >> > > > section of the Apache KIE community, while, at > > > the > > > > > same > > > > > > > > > time, > > > > > > > > > > > not > > > > > > > > > > > > >> > > > contributing to reducing the segmentation of > > the > > > > > Apache > > > > > > > > KIE > > > > > > > > > > > > >> community > > > > > > > > > > > > >> > > > as a whole. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Regards, > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > Tiago Bento > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > On Fri, Apr 19, 2024 at 4:08 PM ricardo zanini > > > > > fernandes > > > > > > > > > > > > >> > > > <[email protected]> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > Alex, > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > Yes, in the proposal we just barely > > outlined. > > > I > > > > > create > > > > > > > > the > > > > > > > > > > > EPIC > > > > > > > > > > > > >> to have > > > > > > > > > > > > >> > > > > more details and start working on them as > > soon > > > > as > > > > > we > > > > > > > > > agree. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > On Fri, Apr 19, 2024 at 4:24 PM Alex > > Porcelli > > > < > > > > > > > > > > > [email protected]> > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > Thank you for outlining the tasks post the > > > > 10.x > > > > > > > > release. > > > > > > > > > > > It's > > > > > > > > > > > > >> > > > > > important to note that these are already > > > > > included in > > > > > > > > the > > > > > > > > > > > amended > > > > > > > > > > > > >> > > > > > proposal [1], specifically in steps 9 and > > > 10, > > > > > which > > > > > > > > the > > > > > > > > > > > > >> community has > > > > > > > > > > > > >> > > > > > voted on. If there are concerns about the > > > > > execution > > > > > > > of > > > > > > > > > these > > > > > > > > > > > > >> steps, > > > > > > > > > > > > >> > > > > > I'd like to reassure you that they will > > > > proceed > > > > > as > > > > > > > > > planned, > > > > > > > > > > > in > > > > > > > > > > > > >> > > > > > compliance with Apache guidelines. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > Looking ahead, after the release of > > version > > > > 10, > > > > > we > > > > > > > > > already > > > > > > > > > > > > >> agreed that > > > > > > > > > > > > >> > > > > > we'll need to have a thorough discussion > > > > > regarding > > > > > > > the > > > > > > > > > > > codebase > > > > > > > > > > > > >> > > > > > structure. This will allow us to refine > > our > > > > > > > > > understanding > > > > > > > > > > > of the > > > > > > > > > > > > >> > > > > > sub-brands, their interrelationships, and > > > > their > > > > > > > > > strategic > > > > > > > > > > > > >> positioning. > > > > > > > > > > > > >> > > > > > I agree that this is crucial for our next > > > > steps > > > > > and > > > > > > > > look > > > > > > > > > > > > >> forward to > > > > > > > > > > > > >> > > > > > our collaborative efforts in shaping this. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > [1] - > > > > > > > > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/pw327lkpmy9gxklq4t5zbwzxjo2y3c0w > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > On Fri, Apr 19, 2024 at 2:50 PM ricardo > > > zanini > > > > > > > > fernandes > > > > > > > > > > > > >> > > > > > <[email protected]> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > Folks, > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > I've outlined the tasks we need once we > > > > > release > > > > > > > 10.x > > > > > > > > > from > > > > > > > > > > > > >> kie-tools: > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-issues/issues/1102 > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > Once we release, we can detail this > > > planning > > > > > and > > > > > > > > start > > > > > > > > > > > > >> working on it > > > > > > > > > > > > >> > > > to > > > > > > > > > > > > >> > > > > > > have a streamlined process for the next > > > > > release. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > Please let me know if it makes sense to > > > you. > > > > > We > > > > > > > can > > > > > > > > > break > > > > > > > > > > > > >> down and > > > > > > > > > > > > >> > > > detail > > > > > > > > > > > > >> > > > > > > the tasks once we agree on this initial > > > > plan. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > > > > > > Cheers! > > > > > > > > > > > > >> > > > > > > -- > > > > > > > > > > > > >> > > > > > > Ricardo Zanini Fernandes > > > > > > > > > > > > >> > > > > > > Vida longa e próspera. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > >> > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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]
