Dne 11/11/23 v 03:08 Alex Porcelli napsal(a):
Marek, I sent to stable branch... the reason is because it's the default branch.https://github.com/apache/incubator-kie-optaplanner-quickstarts/pull/616 On Wed, Nov 8, 2023 at 3:15 AM Marek Novotny<[email protected]> wrote:for optaplanner-quickstarts it is development branch Dne 11/7/23 v 19:46 Alex Porcelli napsal(a): 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/18https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/297https://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 adminsasking 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] -- Marek Novotny -- RedHat JBoss Middleware Red Hat Czech s.r.o. Purkynova 111 612 45 Brno
-- Marek Novotny -- RedHat JBoss Middleware Red Hat Czech s.r.o. Purkynova 111 612 45 Brno
OpenPGP_0x5381CEF06F213715.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
