| Re: [jakarta.ee-wg] Approval announcemens |
Thanks everyone for chiming in. So I understand that apparently – nobody seems to know when or where exactly – a decision has been made. A decision that should've been guarded by dedicated requirements if we had followed the self-implied JakartaEE process. Shouldn't that decision then not be formally documented visible to everyone interested? I'm not sure the JakartaEE community does itself a favor if the very first new spec added to the umbrella is incepted this way. Shouldn't the JakartaEE leadership have interest to avoid that kind of impression? Another question I have is why the spec is not routed through Microprofile in the first place. MP seems to be a very decent place to experiment with new features to be standardized eventually and gain feedback from production deployments. With Jakarta NoSQL you start with a spec that's already designed in a way that contradicts design approaches in a competitive library (disclaimer: which I led for almost a decade) in very significant areas. It doesn't feel like a start from an open playground but with pretty significant decisions aleady having been made in a way that they're the complete opposite of what production deployments have seen working well over almost a decade. Why not build something, make sure it sees enough developer projects, gather feedback, learn from that, tweak the design and eventually end up standardizing. In short: what would be wrong with a MP-driven NoSQL module *first* before standardizing an API (of course assuming that a discussion whether the MP community would want to do that happens beforehand)? I deliberately posted to this list instead of the JNoSQL one as this boils down to a general question on how JakartaEE standards will come to be besides the formal process requirements. I can see that an immediate standardization makes sense for problem spaces for already established libraries. Creating one that actively takes different design decisions than the most prominently used one (and which already nicely works in a CDI environment btw.) and not putting that into extensive real world practice before standardizing it feels like a really risky way to approach that topic. Cheers, Ollie > Am 14.06.2019 um 22:03 schrieb David Blevins <dblevins@xxxxxxxxxxxxx>: > > Signierter PGP-Teil > You are correct on many levels. I write not to debunk your points, but to support them and give some of my perspective on where we are. > > First, the post [1] should never have happened via our blog and I consider that an oversight on my part and not a pattern I'd want to see us continue as a community. NoSQL is an oddball in that it was an attempt by the Jakarta EE Working Group to show interim progress -- the official Jakarta EE Specification Process was still being created. > > Going forward, here's the process that should be used: > > - https://www.eclipse.org/projects/efsp/#efsp-version-lifecycle > > My expectation is that this process will be carried out at least as openly as the JCP. Specifically proposals will be public as will vote results, including who voted what and any comments they may have with their vote. In the JCP results are not published until voting is over, which I think is fine. As long as they do get published that's what's important, IMO. > > In terms of NoSQL, I recall Bill Shannon strongly advocating "when we finish the Jakarta EE Specification Process we will need to come back and officially put NoSQL through it." There were nods at the time, but I don't know if that decision was officially made. I don't believe we went back and put it through an official creation review -- if we did, I missed it and the process is too subtle for even me to notice and I'm on the Specification Committee. > > If it is now an official project and we did not formally go through the Creation Review, maybe we want to do that just so our first project has some public record that represents what we expect from all future projects. > > Either way, your note is great. Macro-level, I think we're still pretty far from where we want to be, but getting closer. That doesn't mean everyone should stop sending feedback like yours, it means more should. It's ok to talk about where we want to be. > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Jun 14, 2019, at 9:34 AM, Oliver Drotbohm <ogierke@xxxxxxxxxx> wrote: >> >> Signed PGP part >> Hi all, >> >> can someone clarify how announcements like this [0] come to be? I've read up in the minutes of the committee meetings, been following all JNoSQL related mailing lists, gave feedback and tried to follow the project as close as possible. Still I haven't seen any public discussion about this and am surprised to see projects announced as "approved". Given the name of "Jakarta NoSQL" does that mean it's going to be come a spec? >> >> This kind of development has had precedence in September last year [1] when again the project was announced as first JakartaEE specification without any formal backing of this. Is the new mode of operation we have to expect for JakartaEE? Vendors announcing projects by them being a standard without any kind of public trail in the first place? >> >> I've brought this up in a smaller round before and am surprised to see that MO being used again. This makes a very bad impression on the process in the first place as – no matter how much the new openness is praised publicly – it's fundamentally subverted by the actual decisions either not being made in the way documented or the decision process not being documented as proposed. Why am I supposed to get involved in the public channels if decisions like those are made at will? >> >> Maybe I just got lost in the amount of mailing lists and missed the communication around this. Any insights appreciated. >> >> Cheers, >> Ollie >> >> [0] https://dzone.com/articles/moving-jakarta-forward-jakarta-nosql-has-approved >> [1] https://www.tomitribe.com/blog/jnosql-and-jakarta-ee/ >> >> > > >
Attachment:
signature.asc
Description: Message signed with OpenPGP