You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Alex Porcelli <al...@porcelli.me> on 2023/11/03 18:30:12 UTC
Re: [DISCUSS] - Policy for opening issues in KIE
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.
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 <al...@porcelli.me> wrote:
>
> +1 from me :)
>
>
> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <ri...@gmail.com> 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 <al...@porcelli.me> 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
>> > <ri...@gmail.com> 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 <al...@porcelli.me> wrote:
>> > >
>> > > > On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
>> > > > <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
>> > > > For additional commands, e-mail: dev-help@kie.apache.org
>> > > >
>> > > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > For additional commands, e-mail: dev-help@kie.apache.org
>> >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <al...@porcelli.me>.
Sent!
On Tue, Nov 7, 2023 at 3:29 PM ricardo zanini fernandes
<ri...@gmail.com> wrote:
>
> Hey Alex, many thanks!
>
> For the incubator-kie-kogito-docs it's the main branch.
>
> On Tue, Nov 7, 2023 at 3:47 PM Alex Porcelli <po...@apache.org> wrote:
>
> > 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 <po...@apache.org> 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 <po...@apache.org>
> > 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 <mn...@redhat.com>
> > 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 <al...@porcelli.me>
> > wrote:
> > > >> >> +1 from me :)
> > > >> >>
> > > >> >>
> > > >> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <
> > ricardozanini@gmail.com> 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 <al...@porcelli.me>
> > 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
> > > >> >>>> <ri...@gmail.com> 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 <al...@porcelli.me>
> > wrote:
> > > >> >>>>>
> > > >> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
> > > >> >>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
> > > >> >>>>>> For additional commands, e-mail: dev-help@kie.apache.org
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>
> > ---------------------------------------------------------------------
> > > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > >> >>>> For additional commands, e-mail: dev-help@kie.apache.org
> > > >> >>>>
> > > >> >>>>
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > >> > For additional commands, e-mail: dev-help@kie.apache.org
> > > >> >
> > > >> --
> > > >> Marek Novotny
> > > >> --
> > > >>
> > > >> RedHat JBoss Middleware
> > > >>
> > > >> Red Hat Czech s.r.o.
> > > >> Purkynova 111
> > > >> 612 45 Brno
> > > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by ricardo zanini fernandes <ri...@gmail.com>.
Hey Alex, many thanks!
For the incubator-kie-kogito-docs it's the main branch.
On Tue, Nov 7, 2023 at 3:47 PM Alex Porcelli <po...@apache.org> wrote:
> 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 <po...@apache.org> 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 <po...@apache.org>
> 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 <mn...@redhat.com>
> 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 <al...@porcelli.me>
> wrote:
> > >> >> +1 from me :)
> > >> >>
> > >> >>
> > >> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <
> ricardozanini@gmail.com> 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 <al...@porcelli.me>
> 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
> > >> >>>> <ri...@gmail.com> 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 <al...@porcelli.me>
> wrote:
> > >> >>>>>
> > >> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
> > >> >>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
> > >> >>>>>> For additional commands, e-mail: dev-help@kie.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>
> ---------------------------------------------------------------------
> > >> >>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > >> >>>> For additional commands, e-mail: dev-help@kie.apache.org
> > >> >>>>
> > >> >>>>
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > >> > For additional commands, e-mail: dev-help@kie.apache.org
> > >> >
> > >> --
> > >> Marek Novotny
> > >> --
> > >>
> > >> RedHat JBoss Middleware
> > >>
> > >> Red Hat Czech s.r.o.
> > >> Purkynova 111
> > >> 612 45 Brno
> > >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Marek Novotny <mn...@redhat.com>.
i don't agree or disagree, even before transferring this repository
kiegroup/optaplanner-quickstarts, the default branch was 8.x and stable
branch was not accepting any PR as it was tested status for
documentation and end user.
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<mn...@redhat.com> 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<po...@apache.org> 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<po...@apache.org> 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<mn...@redhat.com> 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<al...@porcelli.me> wrote:
>>
>> +1 from me :)
>>
>>
>> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <
> ricardozanini@gmail.com> 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<al...@porcelli.me> 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
>> <ri...@gmail.com> 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<al...@porcelli.me> wrote:
>>
>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
>> <ri...@gmail.com> 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:dev-unsubscribe@kie.apache.org
>> For additional commands, e-mail:dev-help@kie.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
>> For additional commands, e-mail:dev-help@kie.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
>> For additional commands, e-mail:dev-help@kie.apache.org
>>
>> --
>> Marek Novotny
>> --
>>
>> RedHat JBoss Middleware
>>
>> Red Hat Czech s.r.o.
>> Purkynova 111
>> 612 45 Brno
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
>> For additional commands, e-mail:dev-help@kie.apache.org
>>
>> --
>> 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
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <al...@porcelli.me>.
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 <mn...@redhat.com> 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 <po...@apache.org> 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 <po...@apache.org> 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 <mn...@redhat.com> 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 <al...@porcelli.me> wrote:
>
> +1 from me :)
>
>
> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <
ricardozanini@gmail.com> 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 <al...@porcelli.me> 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
> <ri...@gmail.com> 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 <al...@porcelli.me> wrote:
>
> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
> --
> Marek Novotny
> --
>
> RedHat JBoss Middleware
>
> Red Hat Czech s.r.o.
> Purkynova 111
> 612 45 Brno
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
> --
> Marek Novotny
> --
>
> RedHat JBoss Middleware
>
> Red Hat Czech s.r.o.
> Purkynova 111
> 612 45 Brno
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Marek Novotny <mn...@redhat.com>.
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<po...@apache.org> 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<po...@apache.org> 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<mn...@redhat.com> 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<al...@porcelli.me> wrote:
>>>>>> +1 from me :)
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes<ri...@gmail.com> 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<al...@porcelli.me> 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
>>>>>>>> <ri...@gmail.com> 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<al...@porcelli.me> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
>>>>>>>>>> <ri...@gmail.com> 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:dev-unsubscribe@kie.apache.org
>>>>>>>>>> For additional commands, e-mail:dev-help@kie.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
>>>>>>>> For additional commands, e-mail:dev-help@kie.apache.org
>>>>>>>>
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
>>>>> For additional commands, e-mail:dev-help@kie.apache.org
>>>>>
>>>> --
>>>> Marek Novotny
>>>> --
>>>>
>>>> RedHat JBoss Middleware
>>>>
>>>> Red Hat Czech s.r.o.
>>>> Purkynova 111
>>>> 612 45 Brno
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@kie.apache.org
> For additional commands, e-mail:dev-help@kie.apache.org
>
--
Marek Novotny
--
RedHat JBoss Middleware
Red Hat Czech s.r.o.
Purkynova 111
612 45 Brno
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <po...@apache.org>.
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 <po...@apache.org> 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 <po...@apache.org> 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 <mn...@redhat.com> 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 <al...@porcelli.me> wrote:
> >> >> +1 from me :)
> >> >>
> >> >>
> >> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <ri...@gmail.com> 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 <al...@porcelli.me> 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
> >> >>>> <ri...@gmail.com> 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 <al...@porcelli.me> wrote:
> >> >>>>>
> >> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
> >> >>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@kie.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> >> >>>> For additional commands, e-mail: dev-help@kie.apache.org
> >> >>>>
> >> >>>>
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> >> > For additional commands, e-mail: dev-help@kie.apache.org
> >> >
> >> --
> >> Marek Novotny
> >> --
> >>
> >> RedHat JBoss Middleware
> >>
> >> Red Hat Czech s.r.o.
> >> Purkynova 111
> >> 612 45 Brno
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <po...@apache.org>.
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 <po...@apache.org> 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 <mn...@redhat.com> 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 <al...@porcelli.me> wrote:
>> >> +1 from me :)
>> >>
>> >>
>> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <ri...@gmail.com> 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 <al...@porcelli.me> 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
>> >>>> <ri...@gmail.com> 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 <al...@porcelli.me> wrote:
>> >>>>>
>> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
>> >>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@kie.apache.org
>> >>>>>>
>> >>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> >>>> For additional commands, e-mail: dev-help@kie.apache.org
>> >>>>
>> >>>>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>> > For additional commands, e-mail: dev-help@kie.apache.org
>> >
>> --
>> Marek Novotny
>> --
>>
>> RedHat JBoss Middleware
>>
>> Red Hat Czech s.r.o.
>> Purkynova 111
>> 612 45 Brno
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <po...@apache.org>.
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 <mn...@redhat.com> 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 <al...@porcelli.me> wrote:
> >> +1 from me :)
> >>
> >>
> >> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <
> ricardozanini@gmail.com> 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 <al...@porcelli.me>
> 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
> >>>> <ri...@gmail.com> 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 <al...@porcelli.me>
> wrote:
> >>>>>
> >>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
> >>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
> >>>>>> For additional commands, e-mail: dev-help@kie.apache.org
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> >>>> For additional commands, e-mail: dev-help@kie.apache.org
> >>>>
> >>>>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> --
> Marek Novotny
> --
>
> RedHat JBoss Middleware
>
> Red Hat Czech s.r.o.
> Purkynova 111
> 612 45 Brno
>
>
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Marek Novotny <mn...@redhat.com>.
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 <al...@porcelli.me> wrote:
>> +1 from me :)
>>
>>
>> On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes <ri...@gmail.com> 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 <al...@porcelli.me> 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
>>>> <ri...@gmail.com> 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 <al...@porcelli.me> wrote:
>>>>>
>>>>>> On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes
>>>>>> <ri...@gmail.com> 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: dev-unsubscribe@kie.apache.org
>>>>>> For additional commands, e-mail: dev-help@kie.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
>>>> For additional commands, e-mail: dev-help@kie.apache.org
>>>>
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
--
Marek Novotny
--
RedHat JBoss Middleware
Red Hat Czech s.r.o.
Purkynova 111
612 45 Brno