OK - I'll prepare Jena 3.11.0.
Given the national holidays around this time, be better to have the vote
run into next week.
Andy
On 17/04/2019 21:29, Aaron Coburn wrote:
Also +1 to releasing 3.11 soon and addressing these other issues in 3.12.
(But either way is fine with me)
Aaron
On Wed, Apr 17, 2019 at 6:47 AM <aj...@apache.org> wrote:
+1 to releasing 3.11.0 as described and not loading it up any further.
ajs6f
On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne <a...@apache.org> wrote:
We seem to be trying to do too much in one release. As ever, people get
busy.
https://s.apache.org/jena-3.11.0-jira
36 JIRA
including fixes like JENA-1657 "Close response stream of http
connections".
While not a major problem at the moment, it can start to cause blockage
for other work.
We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and
immediately start on 3.12.0. I can RM 3.11.0 and have some time to help
with a 3.12 ... hoping to get it all done during May.
Or we could just accept a delay to 3.11.0.
It is the usual tension between perfect and timely with volunteer time!
While my preference is release 3.11.0 now and start 3.12.0, either is OK
for me.
Thoughts?
Andy
On 03/04/2019 21:16, Andy Seaborne wrote:
We have three major streams outstanding.
Have I missed anything?
1/ GeoSPARQL
2/ Prometheus metrics
3/ ​SurroundQueryParser
== GeoSPARQL
Greg - apologies for being tardy on this one. It looks in good shape.
Did you hear from anyone after the request for feedback?
This is two modules: geosparql-jena and geosparql-fuseki
A suggestion for how to proceed if you have the time for 3.11.0 is that
we include these basically as-is and remove jena-spatial from Fuseki
which we have been signalling for a while.
Suggestion:
jena-geosparql
jena-fuseki/jena-fuseki-geospatial
and under org.apache.jena.geosparql and
org.apache.jena.fuseki.geosparql
It would have to be maven.
Documentation:
This does not have to timed with the release though desirable to have
some instructions on the website.
Looking the modules, it has its own specialised Fuseki incarnation with
command line arguments and also internally a system wide configuration.
maybe, later, we might want to merge the Fuseki setup but exactly how
and whether separate is better for users due to the specialised nature
can wait. Release should get feedback after it is incorporated -
"release early, release often".
Greg - how does that sound?
PMC - having more eyes on this would be helpful.
If the timing is OK, we can work on details on the ticket JENA-664 (or
email on dev@).
== JENA-1691 : Prometheus metrics
This is getting there. We have the code worked out, the packaging needs
a bit of discussion; importantly it is missing L&N changes due to
BSD-binaries in the combined jars mean some L&N changes.
== JENA-1690 : ​SurroundQueryParser
Looks like this is ready and waiting for someone to merge it.
With all that, it looks like some things to sort out.
We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with
whatever is ready, including getting things in and expect to further
refine, then advance the timing on 3.12.0.
Thoughts?
Andy
