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 > >
