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 intheother 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 makessense. 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 andnotaninternal JIRA anymore. Great! I like GH issues more. Although, Ihave afewQs and observations: 1) Why use a central repository for opening issues and not openingissuesin the respective repository? This is the convention, and each repomighthave different requirements. Like adding different labels or bots.Having acentral 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 wecommunicate tothe community how to open issues? If we go with this central issuesrepo,then we need to communicate in each repo that issues can't be openedthere.Or at least disable the issues tab via .asf.yaml file. This passes aweirdmessage to the community, IMO. The first impression is that we mightnotaccept issues. A newcomer will have to look for a contrib/readmefile tofind 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,canwedo 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
OpenPGP_0x5381CEF06F213715.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
