Sent! On Tue, Nov 7, 2023 at 3:29 PM ricardo zanini fernandes <[email protected]> wrote: > > Hey Alex, many thanks! > > For the incubator-kie-kogito-docs it's the main branch. > > On Tue, Nov 7, 2023 at 3:47 PM Alex Porcelli <[email protected]> wrote: > > > Ohh and I could use some help to know what branch I should use to send > > the PRs for incubator-kie-optaplanner-quickstarts and > > incubator-kie-kogito-docs repos. > > > > On Tue, Nov 7, 2023 at 1:32 PM Alex Porcelli <[email protected]> wrote: > > > > > > Following up on this thread regarding enabling GitHub Issues on all > > > repositories. I actually reached out to Apache Infra [1] asking for > > > that and, as somewhat expected, they told us to use the .asf.yaml > > > file. > > > > > > So I ended up creating a quick script and submit a PR for all repos > > > with the content necessary to enable GitHub Issues (note even if the > > > repo has the issues already enabled, it's not a bad idea to have the > > > .asf.yaml file in place): > > > > > > https://github.com/apache/incubator-kie-optaplanner/pull/3014 > > > https://github.com/apache/incubator-kie-drools/pull/5580 > > > https://github.com/apache/incubator-kie-docs/pull/4532 > > > https://github.com/apache/incubator-kie-benchmarks/pull/274 > > > https://github.com/apache/incubator-kie-kogito-runtimes/pull/3279 > > > https://github.com/apache/incubator-kie-kogito-examples/pull/1822 > > > https://github.com/apache/incubator-kie-kogito-images/pull/1710 > > > https://github.com/apache/incubator-kie-kogito-operator/pull/1533 > > > https://github.com/apache/incubator-kie-kogito-website/pull/73 > > > https://github.com/apache/incubator-kie-kogito-apps/pull/1912 > > > https://github.com/apache/incubator-kie-kogito-pipelines/pull/1120 > > > https://github.com/apache/incubator-kie-kogito-benchmarks/pull/18 > > > > > https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/297 > > > https://github.com/apache/incubator-kie-issues/pull/683 > > > > > > [1] - https://issues.apache.org/jira/browse/INFRA-25142 > > > > > > Alex > > > > > > > > > > > > On Mon, Nov 6, 2023 at 8:09 AM Alex Porcelli <[email protected]> > > wrote: > > > > > > > > Marek, > > > > > > > > I’d expect that a Red Hatter would reach out to Red Hat JIRA admins > > asking for such. > > > > > > > > Regards, > > > > Alex > > > > > > > > > > > > On Mon, Nov 6, 2023 at 3:52 AM Marek Novotny <[email protected]> > > wrote: > > > >> > > > >> > > > >> Dne 11/3/23 v 19:30 Alex Porcelli napsal(a): > > > >> > Just a quick follow-up on this topic regarding the non-apache JIRA > > > >> > projects for the transferred projects. > > > >> > > > > >> > We need to make sure that no one can add new issues to these old > > > >> > JIRAs. However, we should keep all the old information there because > > > >> > it's useful. > > > >> > > > >> How do you think that can be ensured ? > > > >> > > > >> > > > >> > > > > >> > People can look at the old stuff to understand the history or to > > > >> > connect it to new tasks. From now on, any new tasks should be > > written > > > >> > up in GitHub Issues, not JIRA. > > > >> > > > > >> > Even though we will be using GitHub Issues for new work, if there is > > > >> > already an issue in the old JIRA that explains a problem well, we > > > >> > don't need to write it all over again in GitHub. Just putting a link > > > >> > to the old JIRA issue in the new GitHub Issue is good enough. > > > >> > > > > >> > If we need to talk about an issue in detail, we will decide how to > > do > > > >> > that on a case-by-case basis. But mostly, we want to use GitHub > > Issues > > > >> > to talk things over. > > > >> > > > > >> > On Tue, Oct 31, 2023 at 1:58 PM Alex Porcelli <[email protected]> > > wrote: > > > >> >> +1 from me :) > > > >> >> > > > >> >> > > > >> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes < > > [email protected]> wrote: > > > >> >>> Oh that makes perfect sense. > > > >> >>> > > > >> >>> I agree that we can use the global one for fixing CVEs across all > > the > > > >> >>> repos, for example. Also, all the other use cases you mentioned. > > > >> >>> > > > >> >>> That's clear now, many thanks for clarifying. > > > >> >>> > > > >> >>> I'd like to hear from others. Do we have a +1 to use repo level > > issues? > > > >> >>> > > > >> >>> cheers! > > > >> >>> > > > >> >>> On Tue, Oct 31, 2023 at 2:50 PM Alex Porcelli <[email protected]> > > wrote: > > > >> >>> > > > >> >>>> Sorry my lack of clarity on my previous email. > > > >> >>>> > > > >> >>>> What I wanted to say is that we can use both, and move issues > > around > > > >> >>>> where we see better fit. I just don't think we can avoid a > > > >> >>>> commons/global one. > > > >> >>>> > > > >> >>>> On Tue, Oct 31, 2023 at 1:43 PM ricardo zanini fernandes > > > >> >>>> <[email protected]> wrote: > > > >> >>>>> Hey Alex! > > > >> >>>>> > > > >> >>>>> Thanks for the replies! > > > >> >>>>> > > > >> >>>>> I believe the use cases you just mentioned might have issues > > opened in > > > >> >>>> the > > > >> >>>>> other repositories and have GH to link them. Wouldn't that make > > sense? > > > >> >>>>> Plus, I believe these use cases are not the rule, but the > > exception. > > > >> >>>>> Usually, what we have is a single issue in the scope of a > > single repo. > > > >> >>>>> > > > >> >>>>>> So, based on the list above, the use of a centralized repo > > makes > > > >> >>>>> sense. But you know what? Moving issues around is quite easy > > within > > > >> >>>>> the same organization, so based on my input above I'd argue we > > can't > > > >> >>>>> live without a centralized repo... but you can certainly move > > issues > > > >> >>>>> to individual repos if they make more sense there.. as part of > > the > > > >> >>>>> developer workflow. > > > >> >>>>> > > > >> >>>>> Not sure if I understood your statement here 😅 > > > >> >>>>> > > > >> >>>>> So can we or not use the repo level approach? For example, see > > these I > > > >> >>>>> created yesterday: [1,2]. I had to add the "[SonataFlow > > Operator]" to the > > > >> >>>>> title to give context. Maybe adding more labels? :( > > > >> >>>>> > > > >> >>>>> Anyhow, I think we should take a path. If the usage is this > > central repo > > > >> >>>>> for issues, so be it. But I think, based on the feedback I got > > here, that > > > >> >>>>> we should focus on having the issues at the repo level. > > > >> >>>>> > > > >> >>>>> +1 for the comms strategy after having a release. > > > >> >>>>> > > > >> >>>>> [1] https://github.com/apache/incubator-kie-issues/issues/661 > > > >> >>>>> [2] https://github.com/apache/incubator-kie-issues/issues/660 > > > >> >>>>> > > > >> >>>>> On Tue, Oct 31, 2023 at 2:22 PM Alex Porcelli <[email protected]> > > wrote: > > > >> >>>>> > > > >> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes > > > >> >>>>>> <[email protected]> wrote: > > > >> >>>>>>> Hey folks! > > > >> >>>>>>> > > > >> >>>>>>> Last community meeting we had this topic pending regarding the > > > >> >>>>>>> communication of opening issues. > > > >> >>>>>>> > > > >> >>>>>>> I understand that we must use kie-issues now for opening > > issues and > > > >> >>>> not > > > >> >>>>>> an > > > >> >>>>>>> internal JIRA anymore. Great! I like GH issues more. > > Although, I > > > >> >>>> have a > > > >> >>>>>> few > > > >> >>>>>>> Qs and observations: > > > >> >>>>>>> > > > >> >>>>>>> 1) Why use a central repository for opening issues and not > > opening > > > >> >>>> issues > > > >> >>>>>>> in the respective repository? This is the convention, and > > each repo > > > >> >>>> might > > > >> >>>>>>> have different requirements. Like adding different labels or > > bots. > > > >> >>>>>> Having a > > > >> >>>>>>> central repo for issues seems an anti-pattern. > > > >> >>>>>> I agree in principle, however I think this is more complex > > than that. > > > >> >>>>>> The default use of centralized issue repository helps in the > > following > > > >> >>>>>> scenarios: > > > >> >>>>>> > > > >> >>>>>> - Issues that span multiple repositories (ie. a library > > upgrade) > > > >> >>>>>> - Some issues may be surfaced on one component but the real > > issue is > > > >> >>>>>> actually happening in another component. (ie. DMN Runner in KIE > > > >> >>>>>> Sandbox fails with certain input, JIT DMN Runner is failing, > > but the > > > >> >>>>>> bug is on DMN core engine) > > > >> >>>>>> - General users won't necessary know what repository stores > > the code > > > >> >>>>>> of the component that they are using > > > >> >>>>>> > > > >> >>>>>> So, based on the list above, the use of a centralized repo > > makes > > > >> >>>>>> sense. But you know what? Moving issues around is quite easy > > within > > > >> >>>>>> the same organization, so based on my input above I'd argue we > > can't > > > >> >>>>>> live without a centralized repo... but you can certainly move > > issues > > > >> >>>>>> to individual repos if they make more sense there.. as part of > > the > > > >> >>>>>> developer workflow. > > > >> >>>>>> > > > >> >>>>>> And just keep in mind, for all the purposes in the context of > > Apache, > > > >> >>>>>> the only real project is KIE, others are only submodules. > > > >> >>>>>> > > > >> >>>>>>> 2) Can't we have templates when opening issues? How do we > > > >> >>>> communicate to > > > >> >>>>>>> the community how to open issues? If we go with this central > > issues > > > >> >>>> repo, > > > >> >>>>>>> then we need to communicate in each repo that issues can't be > > opened > > > >> >>>>>> there. > > > >> >>>>>>> Or at least disable the issues tab via .asf.yaml file. This > > passes a > > > >> >>>>>> weird > > > >> >>>>>>> message to the community, IMO. The first impression is that > > we might > > > >> >>>> not > > > >> >>>>>>> accept issues. A newcomer will have to look for a > > contrib/readme > > > >> >>>> file to > > > >> >>>>>>> find where to open. > > > >> >>>>>> +1 for templates. And I don't think we need to block the > > github issues > > > >> >>>>>> in repos, we can change this right now (my +1 for that). > > > >> >>>>>> > > > >> >>>>>> For general communication, I think we all agreed to focus > > first on the > > > >> >>>>>> codebase move + a CI baseline... once we are able to cut our > > first > > > >> >>>>>> release, I suspect our focus will turn to our communications. > > > >> >>>>>> > > > >> >>>>>>> 3) Do we have to migrate internal opening JIRAs to GH Issues? > > If so, > > > >> >>>> can > > > >> >>>>>> we > > > >> >>>>>>> do it as we start working on them instead of a batch > > migration? > > > >> >>>>>> The agreement was to not migrate existing... but for anything > > to be > > > >> >>>>>> worked... it's expected the individual will copy-n-paste from > > JIRA to > > > >> >>>>>> GHI to track the work. > > > >> >>>>>> > > > >> >>>>>>> Thank u! > > > >> >>>>>>> -- > > > >> >>>>>>> Zanini > > > >> >>>>>> > > --------------------------------------------------------------------- > > > >> >>>>>> 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] > > > >> > > > > >> -- > > > >> Marek Novotny > > > >> -- > > > >> > > > >> RedHat JBoss Middleware > > > >> > > > >> Red Hat Czech s.r.o. > > > >> Purkynova 111 > > > >> 612 45 Brno > > > >> > > > > --------------------------------------------------------------------- > > 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]
