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/12/17 17:07:43 UTC
[LAZY CONSENSUS] GitHub issues migration
Following on from the recent email discussion on GitHub issues at
https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
the current lack of someone willing / able to address the concerns in
JIRA ..
I'm seeking lazy consensus on enabling GitHub issues and discussions
on the NetBeans repository, and porting Apache Airflow's model process
/ configuration to meet our requirements. The aim will be to use this
for tracking issues in release candidates starting from mid-January
when we branch off for NetBeans 13, with a full switch on release of
NetBeans 13.
See the wiki page on the full details of Airflow's process and best
practice advice at
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
From a release management perspective (frankly from any perspective!)
the current JIRA process is not working for us. Aside from the missing
synchronization of status, review, assignment, milestones, changes,
etc., we are meant to have a release process that prioritizes critical
and blocking issues after branching. That is not happening in any
viable way, and through each release I've been involved in RM'ing it's
got worse.
Some key points or divergences from the wiki page linked -
- We will not be migrating current JIRA issues en-masse. Do re-open
select criticals / blockers in 12.6 that still need addressing in 13
at branch!
- The primary change record will be pull requests (not the current mix
of JIRA and PR). No more need for extra issues just for this purpose.
There will be a maintainers only issue category for task / meta issue
tracking.
- We will have similar forms to Airflow ( see
https://github.com/apache/airflow/issues/new/choose ) with required
fields, automatic labelling, links to other sources of help, etc.
We'll use automation via workflows where useful.
- We will triage aggressively. Only issues that are reproducible in
the latest release, actionable, and not a won't-fix should remain
open. Everything else will be closed or converted to discussions as
and until an actionable issue can be created.
- We will keep issue prioritization in our hands. We will also look to
add labelling for regressions - realistically it's critical
*regressions*, as well as blockers, we most need to prioritize for
releases. And aside from this proposal, we really should revise the
issue priority criteria we inherited.
- We won't follow Airflow's model of a triage team (for now) - let's
get everyone involved in this!
This thread will be open for at least 72hrs under lazy consensus. As
before, I'd summarize and expand that to don't make extra work for
other people. ie. -1 any point here if you are offering an alternative
that you can help implement OR if any point will cause major problems
/ extra work for you.
Thanks,
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 1/4/22 10:59, Neil C Smith wrote:
> OK, thanks all! Closing this off now, and will start work on the
> configuration porting for review, as well as liaise with infra@ on a
> few things (eg. discussions requires manual switch I think)
>
> Also, a comment on this ...
>
> On Thu, 30 Dec 2021 at 16:37, Laszlo Kishalmi <la...@gmail.com> wrote:
>> Well, I still see this as leaving a junkyard behind and open a new one.
>>
>> Maybe moving the issues closer to the code would help to draw attention
>> to those issues.
>>
>> Anyway I have mixed feelings.
> I share those feelings, a lot! Without doubt we're leaving a junkyard
> behind, but I think that applies whether we migrate tools or not. We
> need to fix the process, and I don't see anyone going over the mass of
> old issues to check which are still valid, reproducible, important,
> etc.
>
> I really hope moving closer to the code and changing processes works.
> If not, and in a year we end up with a junkyard again, we've failed!
> We need to not let that happen.
>
> Best wishes,
>
> Neil
Let it be then!
Thank you Neil for the efforts you are putting into this!
>
> ---------------------------------------------------------------------
> 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
>
>
>
---------------------------------------------------------------------
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Neil C Smith <ne...@apache.org>.
OK, thanks all! Closing this off now, and will start work on the
configuration porting for review, as well as liaise with infra@ on a
few things (eg. discussions requires manual switch I think)
Also, a comment on this ...
On Thu, 30 Dec 2021 at 16:37, Laszlo Kishalmi <la...@gmail.com> wrote:
> Well, I still see this as leaving a junkyard behind and open a new one.
>
> Maybe moving the issues closer to the code would help to draw attention
> to those issues.
>
> Anyway I have mixed feelings.
I share those feelings, a lot! Without doubt we're leaving a junkyard
behind, but I think that applies whether we migrate tools or not. We
need to fix the process, and I don't see anyone going over the mass of
old issues to check which are still valid, reproducible, important,
etc.
I really hope moving closer to the code and changing processes works.
If not, and in a year we end up with a junkyard again, we've failed!
We need to not let that happen.
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Mar R <ma...@gmail.com>.
Better late than never :D to concerns about losing old bug reports etc,
will jira data be deleted? Because if not, it won't linked to github but
will still be there so in case of need some manual search and voilà, I know
it's not the best but better than anything.
Il giorno ven 31 dic 2021 alle ore 06:29 antonio <an...@vieiro.net> ha
scritto:
> +1 for using github issues.
>
> Note that Github is going to offer an OpenAPI 3.1 compliant REST API
> specification (it currently offers 3.0.3 specification) ([1], [2]).
>
> Someone could quickly create a client for this API (using an OpenAPI
> client-side generator as in [3], for instance) and bundle it in a
> NetBeans module, in order to have all those issues in the IDE itself.
>
> Wishing you all a happy 2022 entry,
> Antonio
>
>
> [1]
>
> https://github.blog/changelog/2021-12-16-openapi-description-of-rest-api-is-now-3-1-compliant/
>
> [2]
> Current 3.0.3 specification
>
> https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.yaml
>
> Next 3.1.0 specification
>
> https://raw.githubusercontent.com/github/rest-api-description/main/descriptions-next/api.github.com/api.github.com.yaml
>
> [3]
>
> https://javahowtos.com/guides/118-tools/434-java-rest-client-from-swagger-file-with-openapi-generator
>
> El 17/12/21 a las 18:07, Neil C Smith escribió:
> > Following on from the recent email discussion on GitHub issues at
> > https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
> > the current lack of someone willing / able to address the concerns in
> > JIRA ..
> >
> > I'm seeking lazy consensus on enabling GitHub issues and discussions
> > on the NetBeans repository, and porting Apache Airflow's model process
> > / configuration to meet our requirements. The aim will be to use this
> > for tracking issues in release candidates starting from mid-January
> > when we branch off for NetBeans 13, with a full switch on release of
> > NetBeans 13.
> >
> > See the wiki page on the full details of Airflow's process and best
> > practice advice at
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
> >
> > From a release management perspective (frankly from any perspective!)
> > the current JIRA process is not working for us. Aside from the missing
> > synchronization of status, review, assignment, milestones, changes,
> > etc., we are meant to have a release process that prioritizes critical
> > and blocking issues after branching. That is not happening in any
> > viable way, and through each release I've been involved in RM'ing it's
> > got worse.
> >
> > Some key points or divergences from the wiki page linked -
> >
> > - We will not be migrating current JIRA issues en-masse. Do re-open
> > select criticals / blockers in 12.6 that still need addressing in 13
> > at branch!
> > - The primary change record will be pull requests (not the current mix
> > of JIRA and PR). No more need for extra issues just for this purpose.
> > There will be a maintainers only issue category for task / meta issue
> > tracking.
> > - We will have similar forms to Airflow ( see
> > https://github.com/apache/airflow/issues/new/choose ) with required
> > fields, automatic labelling, links to other sources of help, etc.
> > We'll use automation via workflows where useful.
> > - We will triage aggressively. Only issues that are reproducible in
> > the latest release, actionable, and not a won't-fix should remain
> > open. Everything else will be closed or converted to discussions as
> > and until an actionable issue can be created.
> > - We will keep issue prioritization in our hands. We will also look to
> > add labelling for regressions - realistically it's critical
> > *regressions*, as well as blockers, we most need to prioritize for
> > releases. And aside from this proposal, we really should revise the
> > issue priority criteria we inherited.
> > - We won't follow Airflow's model of a triage team (for now) - let's
> > get everyone involved in this!
> >
> >
> > This thread will be open for at least 72hrs under lazy consensus. As
> > before, I'd summarize and expand that to don't make extra work for
> > other people. ie. -1 any point here if you are offering an alternative
> > that you can help implement OR if any point will cause major problems
> > / extra work for you.
> >
> > Thanks,
> >
> > 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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: [LAZY CONSENSUS] GitHub issues migration
Posted by antonio <an...@vieiro.net>.
+1 for using github issues.
Note that Github is going to offer an OpenAPI 3.1 compliant REST API
specification (it currently offers 3.0.3 specification) ([1], [2]).
Someone could quickly create a client for this API (using an OpenAPI
client-side generator as in [3], for instance) and bundle it in a
NetBeans module, in order to have all those issues in the IDE itself.
Wishing you all a happy 2022 entry,
Antonio
[1]
https://github.blog/changelog/2021-12-16-openapi-description-of-rest-api-is-now-3-1-compliant/
[2]
Current 3.0.3 specification
https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.yaml
Next 3.1.0 specification
https://raw.githubusercontent.com/github/rest-api-description/main/descriptions-next/api.github.com/api.github.com.yaml
[3]
https://javahowtos.com/guides/118-tools/434-java-rest-client-from-swagger-file-with-openapi-generator
El 17/12/21 a las 18:07, Neil C Smith escribió:
> Following on from the recent email discussion on GitHub issues at
> https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
> the current lack of someone willing / able to address the concerns in
> JIRA ..
>
> I'm seeking lazy consensus on enabling GitHub issues and discussions
> on the NetBeans repository, and porting Apache Airflow's model process
> / configuration to meet our requirements. The aim will be to use this
> for tracking issues in release candidates starting from mid-January
> when we branch off for NetBeans 13, with a full switch on release of
> NetBeans 13.
>
> See the wiki page on the full details of Airflow's process and best
> practice advice at
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>
> From a release management perspective (frankly from any perspective!)
> the current JIRA process is not working for us. Aside from the missing
> synchronization of status, review, assignment, milestones, changes,
> etc., we are meant to have a release process that prioritizes critical
> and blocking issues after branching. That is not happening in any
> viable way, and through each release I've been involved in RM'ing it's
> got worse.
>
> Some key points or divergences from the wiki page linked -
>
> - We will not be migrating current JIRA issues en-masse. Do re-open
> select criticals / blockers in 12.6 that still need addressing in 13
> at branch!
> - The primary change record will be pull requests (not the current mix
> of JIRA and PR). No more need for extra issues just for this purpose.
> There will be a maintainers only issue category for task / meta issue
> tracking.
> - We will have similar forms to Airflow ( see
> https://github.com/apache/airflow/issues/new/choose ) with required
> fields, automatic labelling, links to other sources of help, etc.
> We'll use automation via workflows where useful.
> - We will triage aggressively. Only issues that are reproducible in
> the latest release, actionable, and not a won't-fix should remain
> open. Everything else will be closed or converted to discussions as
> and until an actionable issue can be created.
> - We will keep issue prioritization in our hands. We will also look to
> add labelling for regressions - realistically it's critical
> *regressions*, as well as blockers, we most need to prioritize for
> releases. And aside from this proposal, we really should revise the
> issue priority criteria we inherited.
> - We won't follow Airflow's model of a triage team (for now) - let's
> get everyone involved in this!
>
>
> This thread will be open for at least 72hrs under lazy consensus. As
> before, I'd summarize and expand that to don't make extra work for
> other people. ie. -1 any point here if you are offering an alternative
> that you can help implement OR if any point will cause major problems
> / extra work for you.
>
> Thanks,
>
> 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
>
>
>
---------------------------------------------------------------------
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
Awesome.
Gj
On Thu, Dec 30, 2021 at 1:53 PM Neil C Smith <ne...@apache.org> wrote:
> Hi,
>
> Theoretically this passed through about 10 days ago without any
> comment, but I also realise that it's holidays time. I'll close this
> and start work on porting Airflow's config sometime middle of next
> week, mostly via PR for review. Please speak up with full (-1) /
> partial (-0.?) concerns if you have them.
>
> Thanks and best wishes,
>
> Neil
>
> On Fri, 17 Dec 2021 at 17:07, Neil C Smith <ne...@apache.org> wrote:
> >
> > Following on from the recent email discussion on GitHub issues at
> > https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
> > the current lack of someone willing / able to address the concerns in
> > JIRA ..
> >
> > I'm seeking lazy consensus on enabling GitHub issues and discussions
> > on the NetBeans repository, and porting Apache Airflow's model process
> > / configuration to meet our requirements. The aim will be to use this
> > for tracking issues in release candidates starting from mid-January
> > when we branch off for NetBeans 13, with a full switch on release of
> > NetBeans 13.
> >
> > See the wiki page on the full details of Airflow's process and best
> > practice advice at
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
> >
> > From a release management perspective (frankly from any perspective!)
> > the current JIRA process is not working for us. Aside from the missing
> > synchronization of status, review, assignment, milestones, changes,
> > etc., we are meant to have a release process that prioritizes critical
> > and blocking issues after branching. That is not happening in any
> > viable way, and through each release I've been involved in RM'ing it's
> > got worse.
> >
> > Some key points or divergences from the wiki page linked -
> >
> > - We will not be migrating current JIRA issues en-masse. Do re-open
> > select criticals / blockers in 12.6 that still need addressing in 13
> > at branch!
> > - The primary change record will be pull requests (not the current mix
> > of JIRA and PR). No more need for extra issues just for this purpose.
> > There will be a maintainers only issue category for task / meta issue
> > tracking.
> > - We will have similar forms to Airflow ( see
> > https://github.com/apache/airflow/issues/new/choose ) with required
> > fields, automatic labelling, links to other sources of help, etc.
> > We'll use automation via workflows where useful.
> > - We will triage aggressively. Only issues that are reproducible in
> > the latest release, actionable, and not a won't-fix should remain
> > open. Everything else will be closed or converted to discussions as
> > and until an actionable issue can be created.
> > - We will keep issue prioritization in our hands. We will also look to
> > add labelling for regressions - realistically it's critical
> > *regressions*, as well as blockers, we most need to prioritize for
> > releases. And aside from this proposal, we really should revise the
> > issue priority criteria we inherited.
> > - We won't follow Airflow's model of a triage team (for now) - let's
> > get everyone involved in this!
> >
> >
> > This thread will be open for at least 72hrs under lazy consensus. As
> > before, I'd summarize and expand that to don't make extra work for
> > other people. ie. -1 any point here if you are offering an alternative
> > that you can help implement OR if any point will cause major problems
> > / extra work for you.
> >
> > Thanks,
> >
> > 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: [LAZY CONSENSUS] GitHub issues migration
Posted by Laszlo Kishalmi <la...@gmail.com>.
0
Well, I still see this as leaving a junkyard behind and open a new one.
Maybe moving the issues closer to the code would help to draw attention
to those issues.
Anyway I have mixed feelings. I just would have liked to express that
with this zero.
On 12/30/21 07:00, Eric Bresie wrote:
> 0
>
> I’m not against it but I’ve voiced my concerns (I know at length [1] [2]
> and at different times [3]) with no apparent traction on most of it.
>
> So go with it and see where it goes from there.
>
> [Here is my “short” rebuttal]
> I appreciate the value of GitHub issues and discussions, but I fear rather
> than learning to use the tools the way they were meant to be (I.e. Jira
> filters, reports, dashboards, and integration [2]) or have any improvements
> from lessons learned of past (i.e. resurrect a release ticket / checklist,
> with linked tickets [4]), not taking time to triage/manage issue, it will
> now be necessary to learn a new tool, a new way, (including adapting new
> process for Oracle folks who from the previous discussion will still have
> to use internally) and risk loosing a lot of history and possibly valid
> bugs in the process (like when migrating from Bugzilla to Jira).
>
> I’ve said my peace. Cheers
>
> Eric Bresie
>
> Reference
> (1) https://lists.apache.org/thread/mnm6zo5knzgzr90jkjm1vd8tgtqtz0o5
>
> (2)
> https://lists.apache.org/thread/ovc9zzmk80b17mhg0q0r6phc57kbmjsr
>
> (3)
> https://lists.apache.org/thread/qgmr1g3gvgbm08ls3bf72mm5k2yxktn1
>
> (4)
> https://www.mail-archive.com/dev@netbeans.apache.org/msg07020.html
>
> On Thu, Dec 30, 2021 at 7:57 AM Michael Bien <mb...@gmail.com> wrote:
>
>> i am all for it +1
>>
>> i just didn't speak up since I think I did in older threads already
>>
>> - liking the idea of having a simpler issue tracker etc
>> - your plan is great
>>
>> -michael
>>
>>
>> On 30.12.21 13:53, Neil C Smith wrote:
>>> Hi,
>>>
>>> Theoretically this passed through about 10 days ago without any
>>> comment, but I also realise that it's holidays time. I'll close this
>>> and start work on porting Airflow's config sometime middle of next
>>> week, mostly via PR for review. Please speak up with full (-1) /
>>> partial (-0.?) concerns if you have them.
>>>
>>> Thanks and best wishes,
>>>
>>> Neil
>>>
>>> On Fri, 17 Dec 2021 at 17:07, Neil C Smith <ne...@apache.org>
>> wrote:
>>>> Following on from the recent email discussion on GitHub issues at
>>>> https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
>>>> the current lack of someone willing / able to address the concerns in
>>>> JIRA ..
>>>>
>>>> I'm seeking lazy consensus on enabling GitHub issues and discussions
>>>> on the NetBeans repository, and porting Apache Airflow's model process
>>>> / configuration to meet our requirements. The aim will be to use this
>>>> for tracking issues in release candidates starting from mid-January
>>>> when we branch off for NetBeans 13, with a full switch on release of
>>>> NetBeans 13.
>>>>
>>>> See the wiki page on the full details of Airflow's process and best
>>>> practice advice at
>>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>>>> From a release management perspective (frankly from any perspective!)
>>>> the current JIRA process is not working for us. Aside from the missing
>>>> synchronization of status, review, assignment, milestones, changes,
>>>> etc., we are meant to have a release process that prioritizes critical
>>>> and blocking issues after branching. That is not happening in any
>>>> viable way, and through each release I've been involved in RM'ing it's
>>>> got worse.
>>>>
>>>> Some key points or divergences from the wiki page linked -
>>>>
>>>> - We will not be migrating current JIRA issues en-masse. Do re-open
>>>> select criticals / blockers in 12.6 that still need addressing in 13
>>>> at branch!
>>>> - The primary change record will be pull requests (not the current mix
>>>> of JIRA and PR). No more need for extra issues just for this purpose.
>>>> There will be a maintainers only issue category for task / meta issue
>>>> tracking.
>>>> - We will have similar forms to Airflow ( see
>>>> https://github.com/apache/airflow/issues/new/choose ) with required
>>>> fields, automatic labelling, links to other sources of help, etc.
>>>> We'll use automation via workflows where useful.
>>>> - We will triage aggressively. Only issues that are reproducible in
>>>> the latest release, actionable, and not a won't-fix should remain
>>>> open. Everything else will be closed or converted to discussions as
>>>> and until an actionable issue can be created.
>>>> - We will keep issue prioritization in our hands. We will also look to
>>>> add labelling for regressions - realistically it's critical
>>>> *regressions*, as well as blockers, we most need to prioritize for
>>>> releases. And aside from this proposal, we really should revise the
>>>> issue priority criteria we inherited.
>>>> - We won't follow Airflow's model of a triage team (for now) - let's
>>>> get everyone involved in this!
>>>>
>>>>
>>>> This thread will be open for at least 72hrs under lazy consensus. As
>>>> before, I'd summarize and expand that to don't make extra work for
>>>> other people. ie. -1 any point here if you are offering an alternative
>>>> that you can help implement OR if any point will cause major problems
>>>> / extra work for you.
>>>>
>>>> Thanks,
>>>>
>>>> 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
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>> --
> Eric Bresie
> ebresie@gmail.com
>
---------------------------------------------------------------------
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
AW: [LAZY CONSENSUS] GitHub issues migration
Posted by Christian Lenz <ch...@gmx.net>.
+1 for using Github issues. Thx for the upcoming work and effort.
Von: Neil C Smith
Gesendet: Donnerstag, 30. Dezember 2021 17:41
An: dev@netbeans.apache.org
Betreff: Re: [LAZY CONSENSUS] GitHub issues migration
On Thu, 30 Dec 2021 at 13:57, Michael Bien <mb...@gmail.com> wrote:
> i am all for it +1
>
> i just didn't speak up since I think I did in older threads already
Thanks. Absolutely no need (although always good!) for +1 on a lazy
consensus. More giving people more time to raise objections to all or
part ...
On Thu, 30 Dec 2021 at 15:01, Eric Bresie <eb...@gmail.com> wrote:
> 0
>
> I’m not against it but I’ve voiced my concerns (I know at length [1] [2]
> and at different times [3]) with no apparent traction on most of it.
Your concerns were definitely not ignored, but nor was there traction
from any PMC member / committer willing to take it forward. If there
is, they can consider -1 and a proposal here.
Right, let's leave discussion for the discussion thread, particularly
if there are specific concerns to address in the process.
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 30 Dec 2021 at 13:57, Michael Bien <mb...@gmail.com> wrote:
> i am all for it +1
>
> i just didn't speak up since I think I did in older threads already
Thanks. Absolutely no need (although always good!) for +1 on a lazy
consensus. More giving people more time to raise objections to all or
part ...
On Thu, 30 Dec 2021 at 15:01, Eric Bresie <eb...@gmail.com> wrote:
> 0
>
> I’m not against it but I’ve voiced my concerns (I know at length [1] [2]
> and at different times [3]) with no apparent traction on most of it.
Your concerns were definitely not ignored, but nor was there traction
from any PMC member / committer willing to take it forward. If there
is, they can consider -1 and a proposal here.
Right, let's leave discussion for the discussion thread, particularly
if there are specific concerns to address in the process.
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Eric Bresie <eb...@gmail.com>.
0
I’m not against it but I’ve voiced my concerns (I know at length [1] [2]
and at different times [3]) with no apparent traction on most of it.
So go with it and see where it goes from there.
[Here is my “short” rebuttal]
I appreciate the value of GitHub issues and discussions, but I fear rather
than learning to use the tools the way they were meant to be (I.e. Jira
filters, reports, dashboards, and integration [2]) or have any improvements
from lessons learned of past (i.e. resurrect a release ticket / checklist,
with linked tickets [4]), not taking time to triage/manage issue, it will
now be necessary to learn a new tool, a new way, (including adapting new
process for Oracle folks who from the previous discussion will still have
to use internally) and risk loosing a lot of history and possibly valid
bugs in the process (like when migrating from Bugzilla to Jira).
I’ve said my peace. Cheers
Eric Bresie
Reference
(1) https://lists.apache.org/thread/mnm6zo5knzgzr90jkjm1vd8tgtqtz0o5
(2)
https://lists.apache.org/thread/ovc9zzmk80b17mhg0q0r6phc57kbmjsr
(3)
https://lists.apache.org/thread/qgmr1g3gvgbm08ls3bf72mm5k2yxktn1
(4)
https://www.mail-archive.com/dev@netbeans.apache.org/msg07020.html
On Thu, Dec 30, 2021 at 7:57 AM Michael Bien <mb...@gmail.com> wrote:
> i am all for it +1
>
> i just didn't speak up since I think I did in older threads already
>
> - liking the idea of having a simpler issue tracker etc
> - your plan is great
>
> -michael
>
>
> On 30.12.21 13:53, Neil C Smith wrote:
> > Hi,
> >
> > Theoretically this passed through about 10 days ago without any
> > comment, but I also realise that it's holidays time. I'll close this
> > and start work on porting Airflow's config sometime middle of next
> > week, mostly via PR for review. Please speak up with full (-1) /
> > partial (-0.?) concerns if you have them.
> >
> > Thanks and best wishes,
> >
> > Neil
> >
> > On Fri, 17 Dec 2021 at 17:07, Neil C Smith <ne...@apache.org>
> wrote:
> >> Following on from the recent email discussion on GitHub issues at
> >> https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
> >> the current lack of someone willing / able to address the concerns in
> >> JIRA ..
> >>
> >> I'm seeking lazy consensus on enabling GitHub issues and discussions
> >> on the NetBeans repository, and porting Apache Airflow's model process
> >> / configuration to meet our requirements. The aim will be to use this
> >> for tracking issues in release candidates starting from mid-January
> >> when we branch off for NetBeans 13, with a full switch on release of
> >> NetBeans 13.
> >>
> >> See the wiki page on the full details of Airflow's process and best
> >> practice advice at
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
> >>
> >> From a release management perspective (frankly from any perspective!)
> >> the current JIRA process is not working for us. Aside from the missing
> >> synchronization of status, review, assignment, milestones, changes,
> >> etc., we are meant to have a release process that prioritizes critical
> >> and blocking issues after branching. That is not happening in any
> >> viable way, and through each release I've been involved in RM'ing it's
> >> got worse.
> >>
> >> Some key points or divergences from the wiki page linked -
> >>
> >> - We will not be migrating current JIRA issues en-masse. Do re-open
> >> select criticals / blockers in 12.6 that still need addressing in 13
> >> at branch!
> >> - The primary change record will be pull requests (not the current mix
> >> of JIRA and PR). No more need for extra issues just for this purpose.
> >> There will be a maintainers only issue category for task / meta issue
> >> tracking.
> >> - We will have similar forms to Airflow ( see
> >> https://github.com/apache/airflow/issues/new/choose ) with required
> >> fields, automatic labelling, links to other sources of help, etc.
> >> We'll use automation via workflows where useful.
> >> - We will triage aggressively. Only issues that are reproducible in
> >> the latest release, actionable, and not a won't-fix should remain
> >> open. Everything else will be closed or converted to discussions as
> >> and until an actionable issue can be created.
> >> - We will keep issue prioritization in our hands. We will also look to
> >> add labelling for regressions - realistically it's critical
> >> *regressions*, as well as blockers, we most need to prioritize for
> >> releases. And aside from this proposal, we really should revise the
> >> issue priority criteria we inherited.
> >> - We won't follow Airflow's model of a triage team (for now) - let's
> >> get everyone involved in this!
> >>
> >>
> >> This thread will be open for at least 72hrs under lazy consensus. As
> >> before, I'd summarize and expand that to don't make extra work for
> >> other people. ie. -1 any point here if you are offering an alternative
> >> that you can help implement OR if any point will cause major problems
> >> / extra work for you.
> >>
> >> Thanks,
> >>
> >> 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
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
> --
Eric Bresie
ebresie@gmail.com
Re: [LAZY CONSENSUS] GitHub issues migration
Posted by Michael Bien <mb...@gmail.com>.
i am all for it +1
i just didn't speak up since I think I did in older threads already
- liking the idea of having a simpler issue tracker etc
- your plan is great
-michael
On 30.12.21 13:53, Neil C Smith wrote:
> Hi,
>
> Theoretically this passed through about 10 days ago without any
> comment, but I also realise that it's holidays time. I'll close this
> and start work on porting Airflow's config sometime middle of next
> week, mostly via PR for review. Please speak up with full (-1) /
> partial (-0.?) concerns if you have them.
>
> Thanks and best wishes,
>
> Neil
>
> On Fri, 17 Dec 2021 at 17:07, Neil C Smith <ne...@apache.org> wrote:
>> Following on from the recent email discussion on GitHub issues at
>> https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
>> the current lack of someone willing / able to address the concerns in
>> JIRA ..
>>
>> I'm seeking lazy consensus on enabling GitHub issues and discussions
>> on the NetBeans repository, and porting Apache Airflow's model process
>> / configuration to meet our requirements. The aim will be to use this
>> for tracking issues in release candidates starting from mid-January
>> when we branch off for NetBeans 13, with a full switch on release of
>> NetBeans 13.
>>
>> See the wiki page on the full details of Airflow's process and best
>> practice advice at
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>>
>> From a release management perspective (frankly from any perspective!)
>> the current JIRA process is not working for us. Aside from the missing
>> synchronization of status, review, assignment, milestones, changes,
>> etc., we are meant to have a release process that prioritizes critical
>> and blocking issues after branching. That is not happening in any
>> viable way, and through each release I've been involved in RM'ing it's
>> got worse.
>>
>> Some key points or divergences from the wiki page linked -
>>
>> - We will not be migrating current JIRA issues en-masse. Do re-open
>> select criticals / blockers in 12.6 that still need addressing in 13
>> at branch!
>> - The primary change record will be pull requests (not the current mix
>> of JIRA and PR). No more need for extra issues just for this purpose.
>> There will be a maintainers only issue category for task / meta issue
>> tracking.
>> - We will have similar forms to Airflow ( see
>> https://github.com/apache/airflow/issues/new/choose ) with required
>> fields, automatic labelling, links to other sources of help, etc.
>> We'll use automation via workflows where useful.
>> - We will triage aggressively. Only issues that are reproducible in
>> the latest release, actionable, and not a won't-fix should remain
>> open. Everything else will be closed or converted to discussions as
>> and until an actionable issue can be created.
>> - We will keep issue prioritization in our hands. We will also look to
>> add labelling for regressions - realistically it's critical
>> *regressions*, as well as blockers, we most need to prioritize for
>> releases. And aside from this proposal, we really should revise the
>> issue priority criteria we inherited.
>> - We won't follow Airflow's model of a triage team (for now) - let's
>> get everyone involved in this!
>>
>>
>> This thread will be open for at least 72hrs under lazy consensus. As
>> before, I'd summarize and expand that to don't make extra work for
>> other people. ie. -1 any point here if you are offering an alternative
>> that you can help implement OR if any point will cause major problems
>> / extra work for you.
>>
>> Thanks,
>>
>> 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
>
>
>
---------------------------------------------------------------------
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: [LAZY CONSENSUS] GitHub issues migration
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Theoretically this passed through about 10 days ago without any
comment, but I also realise that it's holidays time. I'll close this
and start work on porting Airflow's config sometime middle of next
week, mostly via PR for review. Please speak up with full (-1) /
partial (-0.?) concerns if you have them.
Thanks and best wishes,
Neil
On Fri, 17 Dec 2021 at 17:07, Neil C Smith <ne...@apache.org> wrote:
>
> Following on from the recent email discussion on GitHub issues at
> https://lists.apache.org/thread/9m74s6xl2zqwnfoq2tn391fvy2kqwcpr and
> the current lack of someone willing / able to address the concerns in
> JIRA ..
>
> I'm seeking lazy consensus on enabling GitHub issues and discussions
> on the NetBeans repository, and porting Apache Airflow's model process
> / configuration to meet our requirements. The aim will be to use this
> for tracking issues in release candidates starting from mid-January
> when we branch off for NetBeans 13, with a full switch on release of
> NetBeans 13.
>
> See the wiki page on the full details of Airflow's process and best
> practice advice at
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
>
> From a release management perspective (frankly from any perspective!)
> the current JIRA process is not working for us. Aside from the missing
> synchronization of status, review, assignment, milestones, changes,
> etc., we are meant to have a release process that prioritizes critical
> and blocking issues after branching. That is not happening in any
> viable way, and through each release I've been involved in RM'ing it's
> got worse.
>
> Some key points or divergences from the wiki page linked -
>
> - We will not be migrating current JIRA issues en-masse. Do re-open
> select criticals / blockers in 12.6 that still need addressing in 13
> at branch!
> - The primary change record will be pull requests (not the current mix
> of JIRA and PR). No more need for extra issues just for this purpose.
> There will be a maintainers only issue category for task / meta issue
> tracking.
> - We will have similar forms to Airflow ( see
> https://github.com/apache/airflow/issues/new/choose ) with required
> fields, automatic labelling, links to other sources of help, etc.
> We'll use automation via workflows where useful.
> - We will triage aggressively. Only issues that are reproducible in
> the latest release, actionable, and not a won't-fix should remain
> open. Everything else will be closed or converted to discussions as
> and until an actionable issue can be created.
> - We will keep issue prioritization in our hands. We will also look to
> add labelling for regressions - realistically it's critical
> *regressions*, as well as blockers, we most need to prioritize for
> releases. And aside from this proposal, we really should revise the
> issue priority criteria we inherited.
> - We won't follow Airflow's model of a triage team (for now) - let's
> get everyone involved in this!
>
>
> This thread will be open for at least 72hrs under lazy consensus. As
> before, I'd summarize and expand that to don't make extra work for
> other people. ie. -1 any point here if you are offering an alternative
> that you can help implement OR if any point will cause major problems
> / extra work for you.
>
> Thanks,
>
> 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