Accepted is actually overloaded at this point as it applies to both TCK challenges and certification requests. They are disjoint issues, so that is fine. Likewise invalid is overloaded as an existing default label that could be used for bugs, etc. I think we need to go with what we have defined for now and update it later if needed.
Hi,We recently discovered
the missing "certification" label for creating issues against
the spec projects. That's been resolved.I also just discovered
that many (most) of the spec/tck projects do not have the necessary labels
for creating TCK challenges. According to our TCK process, we should be
using the following labels:- challenge
- accepted
- invalid
- challenge-appeal
- appealed-challenge
TBH, shouldn't
"accepted" be "challenge-accepted" and the same for
"challenge-invalid"? The generic "accepted" and
"invalid" labels don't seem sufficient, unless we enforce the
rule to leave the "challenge" label as-is. But, then why
did we qualify the "appeal" process labels?I don't want to
add to our long checklist at this point, but maybe a note to the Spec leads
to ensure that these are available? Or, maybe their respective TCK
processes require additional or modified labels?FYI, we are finding
this since we are hitting a couple of challenges during our running of
the Jakarta EE TCK. These were reported when we did the Java EE 8
TCK run, but since they still exist, we wanted to ensure that they were
not lost.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
