Could we refine/rewrite the criteria then?
Also as far as remember we had a bug/issue classifying table somewhere
on what is blocker, critical major, etc.
BTW, Thanks for your attention the number of critical issues are down to
16! Good progress!
On 06/24/2018 12:56 PM, Geertjan Wielenga wrote:
I think what we're trying to do is merge the NetCAT concept into the Apache
Way of doing things.
The way I imagine that working is that the PPMC vote can only begin once
NetCAT gives its 'go'.
I.e., NetCAT gives us a dedicated testing community, which is a plus.
However, I agree, only blockers should be blockers, not anything else,
e.g., critical bugs are not blockers.
Gj
On Sun, Jun 24, 2018 at 9:38 PM, Emilian Bold <
[email protected]> wrote:
I don't mind if we delay the release, but I have some remarks regarding
these new (to me) criteria
I guess they are probably a copy-paste of the NetCAT criteria we had under
Sun / Oracle?
The only voted policy we have under Apache is written here:
https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Policies
If we are to follow the NetCAT criteria for our releases, it would be nice
to have a discussion about this and a vote. (Maybe we had a discussion but
I don't remember. We certainly didn't have a vote).
The conditions seem to make sense, overall.
Still, I don't like the separation of a 'NetCAT team'; there is no
'development team'. (Secondarily, I also don't like that there's a
separated netcat@ mailing list to split the discussion).
Also, the NetCAT team seems to be split into sub-groups called 'tribes'
and they have a 'leader' which seems to be the only one that 'can label a
bug with WAIVER tag'.
This seems rather against the Apache way, as you either are a committer or
not (or part of the PMC or not). Although 'after reaching consensus within
his/her tribe' makes it sound like there's a vote going on, we cannot
restrict voting to a subgroup under Apache, afaik; everybody is allowed to
vote.
The 'Community Acceptance survey' is interesting as it seems to allow
non-binding votes to block a release. This sounds interesting, but it's
also not the Apache way. Of course, if many non-binding votes point toward
something bad, we can decide to take that into account, but it's not
automatic.
In conclusion:
1. I don't consider these release criteria something binding as they are
not voted policy.
2. As such, we should perhaps discuss it and have a vote about it.
3. We should merge netcat@ into dev@ as we are the same community.
4. We should clarify the notion of NetCAT tribe and tribe leader with
regard to the Apache terminology
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 24 June 2018 7:38 AM, Laszlo Kishalmi <[email protected]>
wrote:
Hi all!
In the heat of our RC-s, please do not forget that we have a release
criteria to fulfill:
https://cwiki.apache.org/confluence/display/NETBEANS/
NetBeans+9.0+Release+Criteria
We are pretty got with the BLOCKERS, but we have 21 CRITICAL bugs we
need to address.
Some of these issues are related to codedrop 2, some really need to be
checked if they are really critical.
I've tried my best so far but we need more involvement here, please!
The Release Criteria says:
Only the appropriate NetCAT tribe leader responsible for the affected
functionality can label a bug with WAIVER tag after reaching consensus
within his/her tribe.
---------------------------------------------------------------------
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
