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 <[email protected]> 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: [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
