You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Neil C Smith <ne...@apache.org> on 2021/11/10 17:57:42 UTC
Re: Apache JIRA vs GitHub issues / discussions
On Mon, 27 Sept 2021 at 18:54, Neil C Smith <ne...@apache.org> wrote:
> There's also the possibility some
> of this will end up revised on a wiki page around GitHub best
> practices across ASF ...
So, reviving this thread. That wiki page from Jarek did come about
btw, and is public access -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
Working on the 12.6 release is reminding how much I hate working with
JIRA as we have it set up right now. Either we need to improve how
we're using it, or we need to migrate - and I'm very much in the
latter camp! Something needs to improve, or I feel sorry for whoever
is leading on the next release process (not me!) :-)
The lack of useful synchronization between PRs and issues needs
addressing. The lack of linking, including conversations, milestones,
statuses, users, issue existence(!), etc. is massive duplicate effort.
Eric did a great job putting this page together
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+12.6
But the fact that we have two different change records, that we don't
have JIRA tickets for half the changes, and that half of those are
tickets created to link the PR to, is again a load of duplication.
Either way we also need templates for users to fill out, and to remove
access to things like priorities, and more eyes on the incoming ...
and ...
OK, rant over! :-) Frustration at play. I like Airflow's approach
linked above, but maybe we can do other things. But let's fix this
somehow before NB13!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache JIRA Open Resolved Tickets
Posted by Eric Bresie <eb...@gmail.com>.
When attempting to close it, a dialog shows indicating
"Closing an issue indicates that there is no more work to be done on it,
and that it has been verified as complete."
So guess that's some of the "governance" type to consider.
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 11:05 AM Eric Bresie <eb...@gmail.com> wrote:
> As of this writing there appear to be 190 issues (1) which are listed as
> "Resolved" but not Closed.
>
> Some (20) are duplicates which seems like a given
>
> Is there any reason some of these can't be "Closed"? There appears to be
> an option to do so on the ticket, but didn't no if there was any
> "governance" and/or authority that would preclude me from just clicking the
> "Close Issue" on some of these/
>
> Eric Bresie
> ebresie@gmail.com
>
> (1)
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20%3D%20Resolved%20AND%20project%20%3D%20NETBEANS%20ORDER%20BY%20cf%5B12313826%5D%20ASC
>
>
>
Apache JIRA Open Resolved Tickets
Posted by Eric Bresie <eb...@gmail.com>.
As of this writing there appear to be 190 issues (1) which are listed as
"Resolved" but not Closed.
Some (20) are duplicates which seems like a given
Is there any reason some of these can't be "Closed"? There appears to be
an option to do so on the ticket, but didn't no if there was any
"governance" and/or authority that would preclude me from just clicking the
"Close Issue" on some of these/
Eric Bresie
ebresie@gmail.com
(1)
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20%3D%20Resolved%20AND%20project%20%3D%20NETBEANS%20ORDER%20BY%20cf%5B12313826%5D%20ASC
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
For the "Others", they have components defined but there appear to be
soooooo many components, that it's only showing the "big hitters" with a
larger number for the given component category. I wonder if maybe reducing
the number to a smaller one or have a "top level" component would help
(i.e.Java, Gradle, Javascript, etc.) with a manager for that top level
category and then also break it down further if needed (i.e. Javascript -
Editor, Javascript - Libraries, etc.).
Maybe model after the Netcat tribes like (See
https://netbeans.apache.org/participate/netcat.html). Maybe that is a new
direction for Netcat groups to monitor specific "tribe" based areas to help
in triage as well.
PrefixTribe
[rcp]
API Support
[cnd]
C/C++
[db]
Databases
[debugger]
Debugger
[editor]
Editor
[groovy]
Groovy
[form]
GUI Builder
[j2ee]
Java EE
[fx]
Java FX
[maven]
Maven
[php]
PHP
[profiler]
Profiler
[unit]
Unit Testing
[versioning]
Version Control
[web]
Web Client
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 10:34 AM Eric Bresie <eb...@gmail.com> wrote:
>
> Eric Bresie
> ebresie@gmail.com
>
>
> On Thu, Nov 11, 2021 at 9:56 AM Neil C Smith <ne...@apache.org>
> wrote:
>
>> On Thu, 11 Nov 2021 at 15:44, Michael Bien <mb...@gmail.com> wrote:
>> > I do like the github issue tracker since it appears to be simpler while
>> > still doing its job. To keep an issue tracker useful, it does need
>> > maintenance though. E.g many projects automatically close issues if they
>> > are inactive for a certain amount of time. Having 32k open issues on
>> > jira like NB has, is no longer observable.
>> >
>> > Many "critical" issues i commented on asking if its still a problem were
>> > in fact already fixed. This has to be automated, nobody should have to
>> > do that manually. If the original poster cares about the issue and its
>> > closed by mistake, believe me, it will be reopened.
>> >
>> >
>> > i am for github issues, but someone would actually have to write the
>> > templates, and then also try to automate things, otherwise it will be
>> > jira 2.0 in a year or two.
>>
>> Absolutely! I'm basically saying let's follow what Airflow are doing,
>> and tweak where needed, rather than do this from scratch. They're an
>> ASF project that seemed to have the problems we have, and seem to have
>> addressed it in a way that we could use as a model - forms,
>> automation, etc. included.
>>
>> I'm for doing this for the same reason I was for ditching LTS - it's a
>> promise to our users we're not keeping. It feels worse than useless
>> right now - 32k open issues is just a black hole for users to vent
>> their frustrations into. We really need fewer, better quality issue
>> reports. So, why not see if we can learn from other ASF projects who
>> have been through this? It can't be worse! :-)
>>
>>
> Regarding quality reports, see my earlier emails about filters,
> dashboards, reports, etc.
>
> Having filters showing assorted results like open issues.
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20
>
> I think the JIRA Dashboards provide some of the quality issue reports
> being looked for to provide some guidance..
>
> I unable to to Share my personalized Netbeans dashboad so not sure this
> will be visible or not but with a dashboard like
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333642
>
>
> From that you can drill down to the given linked element (i.e. components,
> status, etc.) where applicable
>
> [image: image.png]
>
> And most importantly, triage for the open issues.
>
> (1) Break the list up into smaller subsets of issues (i.e. by components -
> see dashboard example)
> (2) Although a majority of these open tickets are not set or set to
> "Other" so maybe the first step would be to assign a given ticket to a
> component to start with).
> (3) Alternative labels (i.e. label as "duplicate", "ready to close",
> "reject", "close with no fix", etc) or field could be used to help as well
> in the triage process
> (4) then have "experts for the given components" could monitor these
> and/or provide focus on the components to help the validity of the tickets
> (determine if relevant still, OBE, is duplicate, or is fixed and should be
> closed)
>
> It's important to be cautious about closing items after a given time, just
> because an issue hasn't been worked on forever, doesn't mean there is not
> still an issue and just no one has committed to work on it.
>
> Eric Bresie
>
>
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 9:56 AM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 11 Nov 2021 at 15:44, Michael Bien <mb...@gmail.com> wrote:
> > I do like the github issue tracker since it appears to be simpler while
> > still doing its job. To keep an issue tracker useful, it does need
> > maintenance though. E.g many projects automatically close issues if they
> > are inactive for a certain amount of time. Having 32k open issues on
> > jira like NB has, is no longer observable.
> >
> > Many "critical" issues i commented on asking if its still a problem were
> > in fact already fixed. This has to be automated, nobody should have to
> > do that manually. If the original poster cares about the issue and its
> > closed by mistake, believe me, it will be reopened.
> >
> >
> > i am for github issues, but someone would actually have to write the
> > templates, and then also try to automate things, otherwise it will be
> > jira 2.0 in a year or two.
>
> Absolutely! I'm basically saying let's follow what Airflow are doing,
> and tweak where needed, rather than do this from scratch. They're an
> ASF project that seemed to have the problems we have, and seem to have
> addressed it in a way that we could use as a model - forms,
> automation, etc. included.
>
> I'm for doing this for the same reason I was for ditching LTS - it's a
> promise to our users we're not keeping. It feels worse than useless
> right now - 32k open issues is just a black hole for users to vent
> their frustrations into. We really need fewer, better quality issue
> reports. So, why not see if we can learn from other ASF projects who
> have been through this? It can't be worse! :-)
>
>
Regarding quality reports, see my earlier emails about filters, dashboards,
reports, etc.
Having filters showing assorted results like open issues.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20
I think the JIRA Dashboards provide some of the quality issue reports
being looked for to provide some guidance..
I unable to to Share my personalized Netbeans dashboad so not sure this
will be visible or not but with a dashboard like
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333642
From that you can drill down to the given linked element (i.e. components,
status, etc.) where applicable
[image: image.png]
And most importantly, triage for the open issues.
(1) Break the list up into smaller subsets of issues (i.e. by components -
see dashboard example)
(2) Although a majority of these open tickets are not set or set to "Other"
so maybe the first step would be to assign a given ticket to a component to
start with).
(3) Alternative labels (i.e. label as "duplicate", "ready to close",
"reject", "close with no fix", etc) or field could be used to help as well
in the triage process
(4) then have "experts for the given components" could monitor these and/or
provide focus on the components to help the validity of the tickets
(determine if relevant still, OBE, is duplicate, or is fixed and should be
closed)
It's important to be cautious about closing items after a given time, just
because an issue hasn't been worked on forever, doesn't mean there is not
still an issue and just no one has committed to work on it.
Eric Bresie
Re: Apache JIRA vs GitHub issues / discussions
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 11 Nov 2021 at 15:44, Michael Bien <mb...@gmail.com> wrote:
> I do like the github issue tracker since it appears to be simpler while
> still doing its job. To keep an issue tracker useful, it does need
> maintenance though. E.g many projects automatically close issues if they
> are inactive for a certain amount of time. Having 32k open issues on
> jira like NB has, is no longer observable.
>
> Many "critical" issues i commented on asking if its still a problem were
> in fact already fixed. This has to be automated, nobody should have to
> do that manually. If the original poster cares about the issue and its
> closed by mistake, believe me, it will be reopened.
>
>
> i am for github issues, but someone would actually have to write the
> templates, and then also try to automate things, otherwise it will be
> jira 2.0 in a year or two.
Absolutely! I'm basically saying let's follow what Airflow are doing,
and tweak where needed, rather than do this from scratch. They're an
ASF project that seemed to have the problems we have, and seem to have
addressed it in a way that we could use as a model - forms,
automation, etc. included.
I'm for doing this for the same reason I was for ditching LTS - it's a
promise to our users we're not keeping. It feels worse than useless
right now - 32k open issues is just a black hole for users to vent
their frustrations into. We really need fewer, better quality issue
reports. So, why not see if we can learn from other ASF projects who
have been through this? It can't be worse! :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache JIRA vs GitHub issues / discussions
Posted by Michael Bien <mb...@gmail.com>.
On 11.11.21 16:08, Neil C Smith wrote:
> On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
>> - Issue templates
>> - Pull request template
>> - Repository admins accept content reports
>> -
>> Assume since Issues are not presently in use that probably explains the
>> Issue template, but do the other items need to be considered?
> Interesting. Maybe. What does the last one mean exactly?!
>
> In addition to the wiki page mentioned above, I do recommend just
> having a look at how Airflow have their repository configured.
> https://github.com/apache/airflow
>
> They do have a simple PR template. The issues layout / forms are
> great - try working through the Issues / New Issue process!
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
I do like the github issue tracker since it appears to be simpler while
still doing its job. To keep an issue tracker useful, it does need
maintenance though. E.g many projects automatically close issues if they
are inactive for a certain amount of time. Having 32k open issues on
jira like NB has, is no longer observable.
Many "critical" issues i commented on asking if its still a problem were
in fact already fixed. This has to be automated, nobody should have to
do that manually. If the original poster cares about the issue and its
closed by mistake, believe me, it will be reopened.
i am for github issues, but someone would actually have to write the
templates, and then also try to automate things, otherwise it will be
jira 2.0 in a year or two.
-michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache JIRA vs GitHub issues / discussions
Posted by Christian Oyarzun <co...@oyarzun.net>.
+1, I agree with Neil and believe Apache NetBeans would benefit from
transitioning to what Airflow has done.
If we continue to use Jira, these changes might help some:
1. As Eric suggested, enable autolink for Jira issues.
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
2. Turn on more Jira automations like transition an issue once a PR has
been merged. (I don't think this is currently enabled)
https://www.atlassian.com/software/jira/automation-template-library/bitbucket-github-gitlab
--Christian
On Fri, Nov 12, 2021 at 6:24 AM Michael Bien <mb...@gmail.com> wrote:
> On 11.11.21 16:54, Eric Bresie wrote:
> > I've been following the openjdk side and they continue to have multiple
> > tracking systems which in that context is also burdensome but I believe
> > part of that is driven by the organization management side (have an
> > "official system of record for issues", have a secondary one on github
> > which still has to be linked up with each other). However, I noticed in
> PR
> > discussion some "switches" that can be added to the discussions to
> trigger
> > automatic things like or set state like request reviews, set milestones,
> > etc. How much of that is present in our current workflow?
>
> OpenJDK is using skara which was specifically written to integrate
> github with the existing OpenJDK workflow which was traditionally on
> mailing lists. Without an issue filed and linked to a PR or a
> contributor agreement signed, a PR won't even appear on the mailing list.
>
> This can be a high barrier for external contributors and small fixes,
> since an issue can be only filed if you find a sponsor or file a bug
> hoping that it might transition to an issue (i went through that).
>
> The slash commands are from skara.
>
> https://github.com/openjdk/skara
>
> this would be overkill for NB. But simple configurations, like for
> examples flags in PR text which trigger extra build actions, would be an
> option IMO.
>
> -michael
>
>
> >
> > Eric Bresie
> > ebresie@gmail.com
> >
> >
> > On Thu, Nov 11, 2021 at 9:44 AM Eric Bresie <eb...@gmail.com> wrote:
> >
> >> Eric Bresie
> >> ebresie@gmail.com
> >>
> >>
> >> On Thu, Nov 11, 2021 at 9:08 AM Neil C Smith <ne...@apache.org>
> >> wrote:
> >>
> >>> On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
> >>>
> >>>> - Repository admins accept content reports
> >>> Interesting. Maybe. What does the last one mean exactly?!
> >>>
> >>> Have to confess I don't know since I'm not an admin :-) but I'm
> guessing
> >> it has to do with reporting abuse of some kind for the given repository
> >>
> >>
> >>
> https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Apache JIRA vs GitHub issues / discussions
Posted by Michael Bien <mb...@gmail.com>.
On 11.11.21 16:54, Eric Bresie wrote:
> I've been following the openjdk side and they continue to have multiple
> tracking systems which in that context is also burdensome but I believe
> part of that is driven by the organization management side (have an
> "official system of record for issues", have a secondary one on github
> which still has to be linked up with each other). However, I noticed in PR
> discussion some "switches" that can be added to the discussions to trigger
> automatic things like or set state like request reviews, set milestones,
> etc. How much of that is present in our current workflow?
OpenJDK is using skara which was specifically written to integrate
github with the existing OpenJDK workflow which was traditionally on
mailing lists. Without an issue filed and linked to a PR or a
contributor agreement signed, a PR won't even appear on the mailing list.
This can be a high barrier for external contributors and small fixes,
since an issue can be only filed if you find a sponsor or file a bug
hoping that it might transition to an issue (i went through that).
The slash commands are from skara.
https://github.com/openjdk/skara
this would be overkill for NB. But simple configurations, like for
examples flags in PR text which trigger extra build actions, would be an
option IMO.
-michael
>
> Eric Bresie
> ebresie@gmail.com
>
>
> On Thu, Nov 11, 2021 at 9:44 AM Eric Bresie <eb...@gmail.com> wrote:
>
>> Eric Bresie
>> ebresie@gmail.com
>>
>>
>> On Thu, Nov 11, 2021 at 9:08 AM Neil C Smith <ne...@apache.org>
>> wrote:
>>
>>> On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
>>>
>>>> - Repository admins accept content reports
>>> Interesting. Maybe. What does the last one mean exactly?!
>>>
>>> Have to confess I don't know since I'm not an admin :-) but I'm guessing
>> it has to do with reporting abuse of some kind for the given repository
>>
>>
>> https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
>
> In addition to the wiki page mentioned above, I do recommend just
> having a look at how Airflow have their repository configured.
> https://github.com/apache/airflow
>
> They do have a simple PR template. The issues layout / forms are
> great - try working through the Issues / New Issue process!
>
Still looking at that and it seems reasonable
If the DIscussion is added to Github (assume one of the repository admins
could enable that in some way), how would that work with existing mailing
lists? Would it be like a new mailing list? Would things get mirrored to
the existing lists? Would posts on discussion get forwarded to emails?
Still raises the question, if the problem with current setup is mainly
driven by lack of integration between JIRA/Github - see autolink thread),
learning curve of JIRA (difficulty of using JIRA) - possibly lack of
process/documentation, and change control/management/time to do so, will
this still result in potentially new/different learning curve of GItHub
Issues/Discussions, having to change process/documentation again, and how
to handle existing ticket (doall the tickets get duplicated from JIRA to
GIt? Or maybe a subset [no need for closed ones unless some record of
these is preferred; try to avoid bringing duplicates, OBE tickets, etc.],
make JIRA read only after a time.
I've been following the openjdk side and they continue to have multiple
tracking systems which in that context is also burdensome but I believe
part of that is driven by the organization management side (have an
"official system of record for issues", have a secondary one on github
which still has to be linked up with each other). However, I noticed in PR
discussion some "switches" that can be added to the discussions to trigger
automatic things like or set state like request reviews, set milestones,
etc. How much of that is present in our current workflow?
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 9:44 AM Eric Bresie <eb...@gmail.com> wrote:
>
> Eric Bresie
> ebresie@gmail.com
>
>
> On Thu, Nov 11, 2021 at 9:08 AM Neil C Smith <ne...@apache.org>
> wrote:
>
>> On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
>>
>> > - Repository admins accept content reports
>>
>> Interesting. Maybe. What does the last one mean exactly?!
>>
>> Have to confess I don't know since I'm not an admin :-) but I'm guessing
> it has to do with reporting abuse of some kind for the given repository
>
>
> https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository
>
>
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 9:08 AM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
>
> > - Repository admins accept content reports
>
> Interesting. Maybe. What does the last one mean exactly?!
>
> Have to confess I don't know since I'm not an admin :-) but I'm guessing
it has to do with reporting abuse of some kind for the given repository
https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository
Re: Apache JIRA vs GitHub issues / discussions
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 11 Nov 2021 at 14:55, Eric Bresie <eb...@gmail.com> wrote:
> - Issue templates
> - Pull request template
> - Repository admins accept content reports
> -
> Assume since Issues are not presently in use that probably explains the
> Issue template, but do the other items need to be considered?
Interesting. Maybe. What does the last one mean exactly?!
In addition to the wiki page mentioned above, I do recommend just
having a look at how Airflow have their repository configured.
https://github.com/apache/airflow
They do have a simple PR template. The issues layout / forms are
great - try working through the Issues / New Issue process!
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
Slightly separate sub-topic but while on the Apache/Netbeans Github
repository site I noticed the Insite tab (see
https://github.com/apache/netbeans/pulse ) which seems to provide some
similar reports like those generated in JIRA as mentioned previously.
One sub-selections was how things align with "community" standards (see
https://github.com/apache/netbeans/community )
It seems like have green checks on all of these but the following
- Issue templates
- Pull request template
- Repository admins accept content reports
-
Assume since Issues are not presently in use that probably explains the
Issue template, but do the other items need to be considered?
Eric Bresie
ebresie@gmail.com
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 8:35 AM Eric Bresie <eb...@gmail.com> wrote:
> Not sure if this would help in integration between existing systems but is
> "autolink" enabled on github to ease references to NETBEANS JIRA tickets?
> If not and the github product (pro, enterprise, etc.) in use allows its use
> but if it does, it seems like it might help a little to put in a ticket
> reference which automatically links to the JIRA ticket.
>
> For more see
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
>
> Assume if setup with a prefix of NETBEANS pointing to a URL something like
> https://issues.apache.org/jira/browse/NETBEANS-<num> then references
> starting with NETBEANS may automatically link up.
>
> That does assume a ticket exists to do so.
>
> Eric Bresie
> ebresie@gmail.com
>
>
> On Wed, Nov 10, 2021 at 11:58 AM Neil C Smith <ne...@apache.org>
> wrote:
>
>> On Mon, 27 Sept 2021 at 18:54, Neil C Smith <ne...@apache.org>
>> wrote:
>> > There's also the possibility some
>> > of this will end up revised on a wiki page around GitHub best
>> > practices across ASF ...
>>
>> So, reviving this thread. That wiki page from Jarek did come about
>> btw, and is public access -
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>>
>> Working on the 12.6 release is reminding how much I hate working with
>> JIRA as we have it set up right now. Either we need to improve how
>> we're using it, or we need to migrate - and I'm very much in the
>> latter camp! Something needs to improve, or I feel sorry for whoever
>> is leading on the next release process (not me!) :-)
>>
>> The lack of useful synchronization between PRs and issues needs
>> addressing. The lack of linking, including conversations, milestones,
>> statuses, users, issue existence(!), etc. is massive duplicate effort.
>>
>> Eric did a great job putting this page together
>> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+12.6
>> But the fact that we have two different change records, that we don't
>> have JIRA tickets for half the changes, and that half of those are
>> tickets created to link the PR to, is again a load of duplication.
>>
>> Either way we also need templates for users to fill out, and to remove
>> access to things like priorities, and more eyes on the incoming ...
>> and ...
>>
>> OK, rant over! :-) Frustration at play. I like Airflow's approach
>> linked above, but maybe we can do other things. But let's fix this
>> somehow before NB13!
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
Re: Apache JIRA vs GitHub issues / discussions
Posted by Eric Bresie <eb...@gmail.com>.
Not sure if this would help in integration between existing systems but is
"autolink" enabled on github to ease references to NETBEANS JIRA tickets?
If not and the github product (pro, enterprise, etc.) in use allows its use
but if it does, it seems like it might help a little to put in a ticket
reference which automatically links to the JIRA ticket.
For more see
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
Assume if setup with a prefix of NETBEANS pointing to a URL something like
https://issues.apache.org/jira/browse/NETBEANS-<num> then references
starting with NETBEANS may automatically link up.
That does assume a ticket exists to do so.
Eric Bresie
ebresie@gmail.com
On Wed, Nov 10, 2021 at 11:58 AM Neil C Smith <ne...@apache.org> wrote:
> On Mon, 27 Sept 2021 at 18:54, Neil C Smith <ne...@apache.org> wrote:
> > There's also the possibility some
> > of this will end up revised on a wiki page around GitHub best
> > practices across ASF ...
>
> So, reviving this thread. That wiki page from Jarek did come about
> btw, and is public access -
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>
> Working on the 12.6 release is reminding how much I hate working with
> JIRA as we have it set up right now. Either we need to improve how
> we're using it, or we need to migrate - and I'm very much in the
> latter camp! Something needs to improve, or I feel sorry for whoever
> is leading on the next release process (not me!) :-)
>
> The lack of useful synchronization between PRs and issues needs
> addressing. The lack of linking, including conversations, milestones,
> statuses, users, issue existence(!), etc. is massive duplicate effort.
>
> Eric did a great job putting this page together
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+12.6
> But the fact that we have two different change records, that we don't
> have JIRA tickets for half the changes, and that half of those are
> tickets created to link the PR to, is again a load of duplication.
>
> Either way we also need templates for users to fill out, and to remove
> access to things like priorities, and more eyes on the incoming ...
> and ...
>
> OK, rant over! :-) Frustration at play. I like Airflow's approach
> linked above, but maybe we can do other things. But let's fix this
> somehow before NB13!
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>