You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by ricardo zanini fernandes <ri...@gmail.com> on 2023/10/30 13:16:48 UTC
[DISCUSS] - Policy for opening issues in KIE
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.
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.
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?
Thank u!
--
Zanini
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
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <al...@porcelli.me>.
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>.
+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
> >
> >
>
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by ricardo zanini fernandes <ri...@gmail.com>.
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
>
>
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <al...@porcelli.me>.
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
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by ricardo zanini fernandes <ri...@gmail.com>.
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
>
>
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Alex Porcelli <al...@porcelli.me>.
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
Re: [DISCUSS] - Policy for opening issues in KIE
Posted by Jason Porter <li...@apache.org>.
On 2023/10/30 13:16:48 ricardo zanini fernandes 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've wondered that myself, and I also prefer to have the issues at the repo level. If we can use kie-issues as an umbrella project, I'm all for that.
> 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.
I don't see why we can't use templates; in fact, that's something we should be doing so people know what to send and how to properly create the issue.
> 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?
I also don't see a problem with moving issues over one at a time as they're worked on.
>
> Thank u!
> --
> Zanini
>
---------------------------------------------------------------------
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 Enrique Gonzalez Martinez <el...@gmail.com>.
El lun, 30 oct 2023 a las 14:17, ricardo zanini fernandes
(<ri...@gmail.com>) escribió:
>
> 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 guess you mean issues by components like drools, jbpm, sonata,
runtimes, cloud... ¿?
+1 to that. Do you have a list ?
> 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.
Agreed.
> 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?
N/A in our case as we are working with GH already.
> Thank u!
> --
> Zanini
--
Saludos, Enrique González Martínez :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org