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]
