Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-spec-project-leads] Consistent checkboxes for jakartaee/specifications PRs & review notes everyone should know

I think we should have consistency in where to host the certification issues.

Reading: https://docs.google.com/document/d/1Et3LtK-2SUuAoOV56t8R8fKnRWhbWqg9SLgm-VhbDPY/edit#heading=h.c86x9rk7bay9
Requests to be acknowledged as a certified implementation MUST be filed via the specification project’s TCK issue tracker using the label `certification` and include the following information:

I see I'm the only one who interpreted that as an issue against the TCK project. The other examples use spec project issues, not what I assumed was the intent in saying "TCK issue tracker".

So if we agree it's the spec project that should host these issues, I can go (re)create all the required labels for the TCK challenge workflow over in the batch-api (spec) project to support this.
Hopefully the doc can be updated to clarify (and maybe also add the comment: - "The TCK results should be hosted by the Compatible Implementation not by the Specification Project").

---

The wording comes up again related to "Improvement" - Requests for improvement to tests MUST simply be created as issues with a label of `enhancement` in the specification project’s TCK issue tracker.

IMHO, I do think it might not be helpful at this point to try to specify an "enhancement"-related workflow. Enhancements may be added for a variety of overlapping reasons: new features, increased coverage of old features, better automation, maybe even refactoring, and we're going to end up with some diverse approaches I'd think.

------------------------------------------------------
Scott Kurz
WebSphere Batch and Compute Grid
Development and Level 3 Team Lead
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544
skurz@xxxxxxxxxx
--------------------------------------------------------


Inactive hide details for David Blevins ---07/30/2019 10:57:12 PM---All, I went through all the Spec PRs and updated them so eaDavid Blevins ---07/30/2019 10:57:12 PM---All, I went through all the Spec PRs and updated them so each has the exact same 9 checkboxes. Some

From: David Blevins <dblevins@xxxxxxxxxxxxx>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Date: 07/30/2019 10:57 PM
Subject: [EXTERNAL] [jakartaee-spec-project-leads] Consistent checkboxes for jakartaee/specifications PRs & review notes everyone should know
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx





All,

I went through all the Spec PRs and updated them so each has the exact same 9 checkboxes. Some special notes below.

# JAVADOC CHECKBOX

Many of you now have a "PR# 2 JavaDoc" item that may or may not be checked appropriately.  Can you please review?

This is important as some specs have not yet created their Javadoc PR, such as the Jakarta EE Platform spec.  Everyone else has to get that one done first!


# TCK BINARY CHECKBOX

For those of you who have not yet found your TCK and completed that checkbox.  Your link is likely one of these:

-
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/

If your link references a "latest.zip", that is not the right binary.


# TCK RESULTS

There was a tck results checkbox, it was replaced by the new checkbox "The URL of the compatibility certification request issue:"


# CERTIFICATION REQUEST

The URL of the compatibility certification request issue must be something like these:

-
https://github.com/eclipse-ee4j/mail-spec/issues/1 
-
https://github.com/eclipse-ee4j/batch-tck/issues/1 
-
https://github.com/eclipse-ee4j/injection-spec/issues/3 

You need to use the exact TCK linked in PR, not a snapshot or "latest.zip"

The TCK results must be hosted by the Compatible Implementation, not the Specification Project.  Links to the Specification Project's CI (continuous integration, aka Jenkins job) are not valid.


# COMPATIBLE IMPLEMENTATION

The _index.md in your PR must list the Name and Version of the Compatible Implementation that filed the compatibility certification request.  Acceptable examples:

-
https://github.com/jakartaee/specifications/pull/3/files#diff-d72ca3f01299e61cc5b1fd90c8cc52e1R34 
-
https://github.com/jakartaee/specifications/pull/63/files#diff-74c859868fe2d9c9b5fc4558f9839493R28 
-
https://github.com/jakartaee/specifications/pull/14/files#diff-207016c01de902da42c71f133c360c1bR33 

It is not the name and version of your spec.

A PR cannot be put to vote without at least one Compatible Implementation.  One or more is required.

You cannot use a modified Compatible Implementation such as GlassFish 5.1 with modified API jars.




--
David Blevins
http://twitter.com/dblevins 
http://www.tomitribe.com 


_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads





Back to the top