| Re: [microprofile-wg] [External] : [BALLOT] MicroProfile TCK Process |
I can create one or more PR(s) to fix the simple points mentioned above soon.
The Maven setup might need some discussions before it makes sense to create a PR (i.e. when knowing at which repo).
_______________________________________________Thank you Emily for leaving this open for a moment.
Form my point of view there are a few things open here, that need to be solved somehow:
I fixed the diagram issue with the wrong email address with a BPNM diagram and a SVG export of it as a draft (I used https://demo.bpmn.io/ for this) - and introduced a new typo.Emily fixed it with PR #124 in the source BPMN diagram - but the export was not updated, so it remains in the output document.
There are some issues left in the process diagram, like I makes no sense to me closing the (challenge/appeal) issue before the related work is done - it should be closed when it's done.Some cosmetic thing is, the document does not use clean AsciiDoc, it uses he Markdown compatibility notation instead - that should be cleaned up (simple change).More general, the AsciiDoc setup is not made yet, that prevents issues like the one above with generating the final document diagram from the source automatically. A solution might be to have a proper Maven structure and configuration to achieve this. When there is more than one document, than a multi module setup could help maintaining the version in Maven too. Another option would be separate repos per document.
While pushing things forward is a very good thing and the ballot forces WG members to review (including me ;-) ), on my opinion releasing something that has known issues that prevent proper usage (category error), is not helpful at all. A solution might be release this as a draft only, which gives some time to even improve the quality of the MP TCK process.But on the other hand, the ballot comes to the end now - which might formally require a new version if the majority wants to keep it as it is.
Not mentioned in detail here, but in the new issue (thanks again, Emily) will focus on, there are some (legal) issues found at Jakarta EE currently, which are waiting for EF input and might affect us here too, because we are based our process on that source. Here these JEE issues occur during our MP ballot.
I the future, requiring one component spec to follow the process (as draft) in detail to prove it is working well on all aspects (before releasing a final version) could help out on this (the same pattern like we do with the spec/API and at minimum one implementation fulfilling the TCK requirements successfully).
The question is now, how to proceed at best:I can create one or more PR(s) to fix the simple points mentioned above soon.The Maven setup might need some discussions before it makes sense to create a PR (i.e. when knowing at which repo).The derived legal issues will take some time (but not too long, as they need to be solved within Jakarta EE soon to some degree).
All these changes would need a short review because they change the ballot base - usually this is solved from the formal aspect by requiring a restart of the ballot itself.
What are your thoughts on this?
Best, Jan
PS: Additionally we should consider to give feedback to the Jakarta TCK Process too...
Am 17.02.22 um 10:57 schrieb Emily Jiang via microprofile-wg:
Thank Jan for spotting the email address typo! I have reviewed and merged your PR. In order to address Ed's and your suggestions regarding improving the tck process, I have opened this issue so that we can discuss further for our 2nd version. The important bit is to get the first version out of the door so that we have something to rely on.
I will leave this ballot open for one more day so that you can all take a look at the doc again with the typos and formats fixed. I will conclude this ballot tomorrow (super-majority +1 received) unless I hear otherwise.
Thank you all for your review and support on this matter!
Emily
On Wed, Feb 16, 2022 at 5:00 PM Jan Westerkamp <jan.westerkamp@xxxxxxx> wrote:
_______________________________________________I created a PR to update the process diagram:
Am 16.02.22 um 15:18 schrieb Jan Westerkamp:
-1 (iJUG)
Why:
We are referencing the wrong Email address in the graph (jakarta.ee-spec@xxxxxxxxxxx instead of microprofile-wg@xxxxxxxxxxx)!
Additionally, following Ed's concerns I think we should wait for the results of the ongoing discussions in Jakarta EE which might affect us in MicroProfile too.Even when there are significant differences as we have one version and one namespace for all relevant artefacts (spec document, API, TCK) of a component spec and they all stored in Maven already.
I think we need some of the results (including open legal questions) to have a final version here - and we have the time to do it.
Of course, an update could solve this aspect in the future too...But the wrong email address need to be fixed at least now on my opinion.
Does anybody has the source of that file, which can be edited?Otherwise I can offer to redraw it using BPMN and convert it to SVG to be included (but editable in the future).
Best, Jan
Am 15.02.22 um 20:54 schrieb Ed Bratt:
+1 (Oracle)
For the next review/update of this process, I'd like to make the following observations:
Packaging requirements: Jakarta EE is struggling with the requirement that forcing the ancillary (supporting documentation, guides, coverage, and assertion documents) into the TCK binary is problematic for publication to central repositories such as Maven central. We are currently working on an effort to update the packaging aspect of these requirements. MicroProfile may want to consider updates along these lines itself, or perhaps wait until after Jakarta EE determines what changes it will allow and then follow suit.
Test changes in Service Releases
The very final clause of the document (that service releases '... may have test changes...') might be considered for update in a future revision
In the past, we tried to adhere to the rule -- Once a test is formally adopted, it cannot change -- If the Spec. dev. team receives a challenge and it feels that a specific test must remain but the test must be altered, we allowed that an Alternative test could be provided in the TCK. If an alternative is offered the vendor could choose to run the original test, or the alternative test and they are considered equivalent for the purposes of compatibility verification. The goal was existing tests cannot be changed in anything less than a minor release. Successfully challenged tests may be excluded OR, they may remain and either the original or the alternative may be chosen by the vendor.
Alternative tests were rarely utilized. The decision to provide an alternative test or simply exclude that test would be at the discretion of the Spec. development group. Allowing a general assertion like this seems difficult to manage, in my opinion. I would discourage groups from attempting to change the TCK tests themselves in service releases.
Thank you,
-- Ed Bratt
On 2/9/2022 3:10 PM, Emily Jiang via microprofile-wg wrote:
As agreed on yesterday's MicroProfile Technical call, I have now merged the PR of MicroProfile TCK Process from David and myself. The TCK process can be viewed from here.
To approve and ratify the MicroProfile TCK Process, the Steering Committee Representatives' vote is requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.
According to MicroProfile Specification Process, This ballot runs for seven days and ends on February 16th. The ballot requires a Super-majority positive vote of the Steering Committee members. There is no veto. Community input and Community votes are welcomed. However, only the votes delivered by Steering Committee Representatives will be counted.
--
Thanks
Emily Jiang on behalf of MicroProfile Steering Committee
_______________________________________________ microprofile-wg mailing list microprofile-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/microprofile-wg__;!!ACWV5N9M2RV99hQ!dYvjMIdjy9BqGFF1e13xlIoJDKgVt4G1YrFZWY-wg2e93BYHsdQduQJZ7feTKl0$
_______________________________________________ microprofile-wg mailing list microprofile-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/microprofile-wg
_______________________________________________ microprofile-wg mailing list microprofile-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/microprofile-wg
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
--
Thanks
Emily
_______________________________________________ microprofile-wg mailing list microprofile-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/microprofile-wg
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg