From an end-user perspective, I also would like to see the 2nd choice merged and released. These may seem minor changes, but will improve the factual contents of the release.
I looked over the changes provided in PR
298. These do not appear to materially alter the
specification from what was proposed in the Nov. 22 ballot but
they do clean up many inconsistencies. Had the original ballot
passed, these might have been implemented in a bug-fix update.
Furthermore, many of the changes are to documents that are only
supportive to the specification (at least in my opinion).
Based on that, from the alternative steps Jan provides below, I
concur with the proposal he has put forward -- First choice would
be a re-ballot of the specification including the changes of PR
298 {option 2 from his bullet list). My second choice would be to
simply re-run the ballot again with the membership as it stands,
today (option 1 of the bullet list).
Thank you,
-- Ed Bratt
On 12/12/2022 2:42 PM, Jan Westerkamp
wrote:
Hi MicroProfilers,
To create a new release that can pass
the 2nd ballot of MP 6.0 hopefully, I created this issue (https://github.com/eclipse/microprofile/issues/299)
and added the introduction text here for simplicity:
We have the following options:
- Regarding the email from Wayne today, we can just restart the
ballot with all current members eligible to vote
- We can create a new MP 6.0 version with fixes for my findings
on the review (I created a PR for it: https://github.com/eclipse/microprofile/pull/298)
- We can add an updated version of MP Metrics 5.0 with having
dependencies to Jakarta EE 10 component specs (Jakarta REST and
CDI especially) again instead of the whole Jakarta EE 10 Core
Profile - which would make it easier for vendors to fulfil the
requirements to be compatible
- We can restart the Plan Review with an updated plan,
especially regarding MP Metrics and it's dependencies from other
MP component specs
The first option is the simplest one, but with potentially a
"even good enough" result.
The second one could fix my concerns, at least the ones I can
see as a quick fix. Both two options would make it possible to
get a MP 6.0 release this year as Xmas present potentially.
To make it simpler to be compatible with MP Metrics 5.0 and if
included in MP 6.0 (as Service Release) that could help
implementations, that are now not compatible to Jakarta EE 10
Core Profile. This will take us to somewhere in Q1 2023.
When we want to make everybody happy - we need to plan a
complete new release with major changes regarding MP Metrics
(i.e. make it optional, remove it from the MP Platform, replace
it by OpenTelemetry Metrics in a new MP Telemetry release,
update all dependent specs and TCKs etc.). This can take a while
(i.e. OpenTelemetry is not stable regarding telemetry data yet)
and would prevent us and the users to have a MP Platform release
available that aligns with Jakarta EE 10 - the worst outcome
from my perspective, especially with respect to the current
discussion about MP JWT and Jakarta Security!
We better do plan a new, additional release later to go into
this direction, when there is a replacement available - like we
did with MP OpenTracing and MP Telemetry (Tracing).
So @Emily-Jiang and me prefer heading towards option two soon
and work on three and four then.
What do you think about it?
Best,
Jan
Am 12.12.22 um 19:40 schrieb Wayne
Beaton:
The Eclipse Foundation staff do not proactively monitor every vote in every working group. What we do is retroactively make sure that we think each vote has been undertaken correctly. This MicroProfile 6.0 vote was the first close vote under the EFSP and it forced us to examine the question of exactly who gets to vote in such a ballot. As others have quite rightly pointed out, this is inadequately documented. We intend to remedy that ASAP.
History is littered with lawsuits around standards processes that were perceived as unfair or improperly followed. The ballot in question locks in royalty-free licenses of our members’ patent portfolios to all users and implementers of MicroProfile 6.0. Some of those members have very large patent portfolios and take these licensing matters extremely seriously. So our perspective is that the vote can only pass if it is unassailably correct. In other words, the vote can only pass if it is absolutely crystal clear that it complies with every one of our rules.
As mentioned above, this instance is the first time in the history of the EFSP where the vote was even close. We were therefore obligated to scrutinize it very carefully. Our determination was ultimately based on statements in the Bylaws that quorum is determined at the beginning of each meeting, and – by extension – the beginning of each electronic vote. We acknowledge this is subtle and open to other interpretations, but we are basing this on long discussions related to the nuances of this topic when we formed the Belgian organization; and again, we admit to being conservative for the reasons stated above.
Which leads to a question: to date we have not actually consulted a lawyer on this specific scenario. It is possible that they would tell us that we’re wrong. But I am not sure whether that would actually be quicker or more definitive than re-running the ballot with Primeton’s representative’s vote unambiguously counting this time. While we think that generally it’s bad practice to rerun a ballot without a change, there is enough uncertainty here, given the good intentions of all involved, that rerunning the ballot makes the most sense. And in this case, Primeton’s representative will be eligible to vote and will count towards quorum.
Where was your explanation regarding whether to count
a particular vote documented? I have been searching for
the voting criteria from the relevant docs but did not
find anything. If it is not specified, different
interpretations likely occur like this. Besides, the
vote on Telemetry counted the vote from
Primeton on 28th November. Why wasn't the problem
spotted then? This is not consistent.
I am following up on Paul Buck’s note that we wanted to review the result of this ballot.
Upon review, we deem that this ballot did not pass and thus the MicroProfile 6.0 Release Review was not passed.
The short version is that it is because Primeton had not appointed their representative at the start of the vote.
Before elaborating, I want to inform everyone that we are being deliberate about the interpretation of the rules and the outcome as there are significant intellectual property implications that are dependent on whether the ballot has passed. Further, I'd like to acknowledge that we believe that everybody was operating in good faith and that our interpretation of the rules is in no way intended to suggest otherwise.
The determination of who is eligible to vote is determined at the onset of any vote. In this case, the vote began on November 22/2022. At that time, Primeton had not yet appointed their representative to the Steering Committee, and as such she was not eligible to have her ballot count, either to determine quorum or the outcome of the vote. As a reminder, all members of the MicroProfile working group are eligible to appoint an individual to serve on the Steering Committee; however, there is no obligation to do so. As a result, until such time as an individual is appointed, there is no consideration of that member’s potential representation in the computation of quorum or being eligible to vote on any matter.
As a result, there were only nine eligible voters for this particular election. Of those nine, as shown in the results, five voted in favor, three against, and one abstained. In accordance with our Bylaws, the abstention is not counted in either the numerator or denominator, and thus the computation is based on the five in favor of eight non-abstentions total, for a result of 62.5%. Given this is less than the 2/3 majority required, this means the ballot did not pass.
Note the EFSP defines a super-majority to be two-thirds of the eligible voters and that specification ballots require a super-majority to pass. Working group charters for specification based working groups including MicroProfile list the EFSP as a governing document.
We are reviewing whether this ballot should be
deemed as having passed. We will provide as
quickly as possible a detailed explanation of why
this is the case, and to provide our
determination, but nonetheless we wanted to note
this on the mailing list immediately to ensure
that no committers begin to take actions based on
the assumption it has passed.
As I am going on PTO on Thursday, it will be
another member of the Eclipse team who will
provide the further detail.