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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
