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/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] > > -- > Marek Novotny > -- > > RedHat JBoss Middleware > > Red Hat Czech s.r.o. > Purkynova 111 > 612 45 Brno
