Thread-topic: [jakarta.ee-spec.committee] Ballot for plans (NoSQL for instance)
That does indeed help, thank you both.
Comparing it against those two yes NoSQL seems to be much further along since it seems to have a significant amount of a specification document written already rather than just a simple plan for one.
I'll give it another look in time for the ballot closure.
Apologies if this seemed obvious - I'm still very much a newb when it comes to the ins-and-outs of all these processes.
Thanks,
Andrew Pielage
Java Developer at Payara Services Ltd
Open Source Enterprise Software & Support
From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Sent: 09 October 2020 19:49 To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Cc: Andrew Pielage <andrew.pielage@xxxxxxxxxxx> Subject: Re: [jakarta.ee-spec.committee] Ballot for plans (NoSQL for instance)
When reviewing a plan, the question that you need to answer is whether or not you, as a member of the specification committee, would vote to approve the eventual completion of that plan when the project returns to you for a release review.
We haven't really had to face this yet. The committee has been mostly focused on the mechanics of pushing specs that don't really introduce any new essential claims or functional changes through the process.
As we move forward, you'll have to decide whether or not, for example, a plan item is something that you would actually want to see in an implementation of the specification.
It is possible that NoSQL is further along with the specification writing than many of the previous examples were, but the plan review ought to include some elements of the proposed plan.
Maybe this helps?
-- Ed
On 10/9/2020 8:33 AM, Andrew Pielage wrote:
Late to the party but adding my voice to this - I'm really struggling to give a review of this plan as I can't find any kind of guide or requirements for what constitutes an acceptable plan.
As Jean-Louis pointed out, trying to use the same requirements as a progress or release review has it fall short (e.g. EPL rather than EFTL in TCK), and it's not really the same kind of thing.
Is there some guidance I'm missing? Otherwise I'll have to abstain from voting (or -1).
We were not expecting a draft spec of what already exists in the JNoSQL implementation, but a plan to bring this to a top level specification in Jakarta.
Basically, what do we want?
Where do we want to go with this specification?
Why?
How to get at least another implementation (otherwise, there is no point if creating a specification right)?
We haven't got any chance to discuss this during the meeting yesterday, so maybe we can quickly come to some kind of agreement or at least at the same level.
The PR is using the same template as the actual specification PRs, but NoSQL is a plan and not really a specification.
Anyways, I tried to apply the same requirements, but it does not sound good.
We probably need to lower the bar for plans like this, isn't it?
