Re: Towards Jena 3.11.0

[Aaron Coburn]

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  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  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 changes due to
> > > BSD-binaries in the combined jars mean some L 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
> >
>

Re: Sonar?

[Aaron Coburn]

It is possible to exclude specific modules from Sonar's analysis (I do this
with some of my own projects). The documentation for this is here:
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven#AnalyzingwithSonarQubeScannerforMaven-ExcludingamodulefromSonarQubeanalysis

Basically, you define this property in the module you want to skip:
true

Aaron


On Tue, Apr 16, 2019 at 8:49 AM Rob Vesse  wrote:

> Yep
>
> A lot of the bigger projects (often those with commercial backers) that
> have a much higher rate of change are often very nit-picky about things
> like code style e.g. Apache Spark.  I've on occasion spent weeks going back
> and forth on style nits in the past with PRs for Spark!
>
> I can see where those projects are coming from, if you have a high rate of
> PRs and changes a consistent code style reduces the unnecessary noise in
> code reviews but it tends to be very unwelcoming to new contributors.
>
> So yes I'd never want us to implement that for Jena
>
> Rob
>
> On 16/04/2019, 13:10, "ajs6f"  wrote:
>
> Whoa, wait what?! Are there Apache projects that do that? (Require
> some certain score on this kind of analysis for a contribution?) I
> sincerely hope not, and I'd be the first -1 here at Jena against any such
> suggestion. That would be literally thoughtless.
>
>
>
>
>

[GitHub] [jena] ajs6f commented on issue #534: Prometheus endpoint

[GitBox]

ajs6f commented on issue #534: Prometheus endpoint
URL: https://github.com/apache/jena/pull/534#issuecomment-484128825
 
 
   @Claudenw It can be a little tricky, but you can send a PR to @seaninryan's 
PR. You would do that by pulling his branch into your local Github repo, and 
starting a new branch from that. Add the appropriate commits, then send a a PR 
via Github, selecting his branch as the base branch and your new branch as the 
comparison branch. He can then accept your PR into his branch, which will 
automatically incorporate it here, where that branch is being used for a PR to 
Jena.
   
   That might or might not be easier for you, just throwing it out there in 
case it's useful.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] Claudenw commented on issue #534: Prometheus endpoint

[GitBox]

Claudenw commented on issue #534: Prometheus endpoint
URL: https://github.com/apache/jena/pull/534#issuecomment-484127705
 
 
   I hope to do that in the next few days / evenings
   
   
   On Wed, Apr 17, 2019 at 3:59 PM Andy Seaborne 
   wrote:
   
   > @Claudenw  Would it be possible for you to
   > work with Sean to get it in the PR?
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > , or mute
   > the thread
   > 

   > .
   >
   
   
   -- 
   I like: Like Like - The likeliest place on the web
   
   LinkedIn: http://www.linkedin.com/in/claudewarren
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs commented on issue #534: Prometheus endpoint

[GitBox]

afs commented on issue #534: Prometheus endpoint
URL: https://github.com/apache/jena/pull/534#issuecomment-484127012
 
 
   @Claudenw Would it be possible for you to work with Sean to get it in the PR?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] Claudenw commented on issue #534: Prometheus endpoint

[GitBox]

Claudenw commented on issue #534: Prometheus endpoint
URL: https://github.com/apache/jena/pull/534#issuecomment-484040611
 
 
   What is the process for me (3rd party) to add licenses to PR?
   
   On Mon, Apr 15, 2019 at 7:35 AM Claude Warren  wrote:
   >
   > The two modules in question come under dual licenses: CC0 or
   > BSD-2-clause.  My understanding from the legal-discuss thread is that
   > the CC0 does not require notification because it is public domain but
   > it also does not confer patent rights, so we elected to use
   > BSD-2-Clause and need to add the BSD-2-Clause license file and a the
   > notation that it applies to the  HdrHistogram and LatencyUtils
   > packages.
   >
   > I assume the notation will be in the Notice files for the fuseki
   > bundles that include the libraries mentioned..
   >
   > Claude
   >
   > On Sun, Apr 14, 2019 at 1:56 PM Andy Seaborne  
wrote:
   > >
   > > From the legal-discuss@ emailing list, the decision seems to be we are 
using 2 clause BSD. Please confirm that here or dev@ so it is in public, on a 
jena list/forum.
   > >
   > > Then we need to execute on that for the two dependencies that will be 
bundled into shared jars because we unpack and repack them.
   > >
   > > —
   > > You are receiving this because you were mentioned.
   > > Reply to this email directly, view it on GitHub, or mute the thread.
   >
   >
   >
   > --
   > I like: Like Like - The likeliest place on the web
   > LinkedIn: http://www.linkedin.com/in/claudewarren
   
   
   
   -- 
   I like: Like Like - The likeliest place on the web
   LinkedIn: http://www.linkedin.com/in/claudewarren
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Towards Jena 3.11.0

[ajs6f]

+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  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 changes due to
> > BSD-binaries in the combined jars mean some L 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
>

Re: Towards Jena 3.11.0

[Andy Seaborne]

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 changes due to 
BSD-binaries in the combined jars mean some L 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