You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Simon Helsen <sh...@ca.ibm.com> on 2012/09/06 22:28:58 UTC
2.7.4 release?
hi everyone,
I was wondering if there is a chance to get a 2.7.4 release soon. There
have been numerous fixes since 2.7.3 and unfortunately, we are not allowed
to adopt a non-released snapshot. Basic internal testing seems to suggest
2.7.4 is pretty stable. Does not mean we would not find more bugs, but it
would fit the frequent small service releases. As a non-committer, I don't
think I can help the process (other than testing)
thanks
Simon
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks Claude, but yes, I am dealing with product development (see
jazz.net)
Simon
From:
Claude Warren <cl...@xenei.com>
To:
dev@jena.apache.org
Date:
09/14/2012 04:09 PM
Subject:
Re: 2.7.4 release?
Simon,
When I worked at IBM I worked on the internal architecture review
board one of the questions we had to deal with was the licensing
question (i.e. what license was any open source licensed under). The
upshot was that legal had to approve the license. Some were already
approved and variations need to be verified by legal via a self
reporting process. The net result is that if the license is approved
the software was approved for use on the IBM infrastructure. If you
are producing a product there may be other issues.
On Thu, Sep 13, 2012 at 4:37 PM, Simon Helsen <sh...@ca.ibm.com> wrote:
> Andy,
>
> I'll bring this back to our legal, but they told me that apparently,
when
> a project in Apache releases, Apache has done the appropriate internal
> legal review and makes certain guarantees. I do not know if that
"internal
> legal review" happens in practice, but for IBM that makes a big
> difference, probably in terms of liability. Perhaps you are trying to
say
> that each produced build, and by that, I mean the sources packaged in
that
> build (not some PGP-signed binaries), are implicitly "cleared". If that
is
> true, things would be easier for us.
>
> I'll follow-up on this
>
> Simon
>
>
>
> From:
> Andy Seaborne <an...@apache.org>
> To:
> Simon Helsen/Toronto/IBM@IBMCA
> Cc:
> dev@jena.apache.org
> Date:
> 09/13/2012 11:20 AM
> Subject:
> Re: 2.7.4 release?
>
>
>
>> I definitely agree that the concept of RC cycles is good in principle,
>> but I don't know if lightweight will do for us. As I explained before,
>> we can only get comprehensive testing done with versions of Jena which
I
>> can safely deliver in our main source control stream. Because we
publish
>> milestone builds publically (on jazz.net if you're interested), each
>> milestone needs legal approval for 3rd party libraries. I was told that
>> for Apache libraries we can only do this for releases because of
certain
>> IBM assumptions about Apache releases (don't ask me what, IBM just has
a
>> certain relation with Apache which makes this the way it is). And this
>> process fortunately does not take very long.
>>
>> In other words, if you introduce an RC, it would only help us if you
>> perform the same tasks as you do with a regular release, make it
>> available on the website like you do with a regular release, but just
>> use a different name to indicate that it may not be mature. It would be
>> a bit of a naming game, but it would take away the effect that you come
>> out with a possibly buggy release, yet you give your consumers a chance
>> to fully adopt and test the RC
>
> We use Continuous Integration - the nightly build runs all the tests
> every time. We also use have a "green line" policy (we haven't
> discussed this per se but it is how things run) whereby trunk always
> works. So, in that sense, every nightly build is a uniquely labelled
RC.
>
> As to releases - from Apache, only the source code has real status. The
> maven binaries are PGP-signed by the person doing the build and not
> Apache. "Open source" is both "open" (you can change it) and "source"
> (not binary). A formal release is a vote on a specific source-release
> artifact (which for Jena is a snapshot of SVN).
>
> A top level project has many degrees of freedom but this isn't one of
> them. Sometime in the future, formal binaries may happen - OpenOffice
> want to release ASF-signed binaries but it will involve getting
> authenticated build systems in place. It's quite complicated because of
> the implications and assurances that formal signing brings.
>
> Andy
>
>>
>> thoughts?
>>
>> Simon
>>
>>
>> From: Andy Seaborne <an...@apache.org>
>> To: dev@jena.apache.org
>> Date: 09/13/2012 07:27 AM
>> Subject: Re: 2.7.4 release?
>>
>>
>>
------------------------------------------------------------------------
>>
>> log.info("ABCDEFGHIJKLMNOP") ;
>
>>
>> On 12/09/12 20:49, Simon Helsen wrote:
>> > On the testing front, we just got one of our clients to run a
>> > scalability test (meaning they run with a large starting repository
> and
>> > fire up multiple users to perform read/write activities) and they
>> have not
>> > observed any regressions compared to 2.7.1 and a slight overall
speed
>> > improvement (something like 6%, not stellar, but most importantly
not
>> > slower)
>>
>> Good to know. The crash-restart is the thing that's hardest to test
for
>> in the development test suite so feedback on that would be particularly
>> useful. That's why a (lightweight) RC cycle struck me as important or
>> else we'll end up in some kind of odd/event minor release cycle (odds
>> are effectively RC's, evens are stable releases). Other people have
>> been picking up the dev release as well.
>>
>> Andy
>>
>>
>>
>
>
>
--
I like: Like Like - The likeliest place on the web
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: 2.7.4 release?
Posted by Claude Warren <cl...@xenei.com>.
Simon,
When I worked at IBM I worked on the internal architecture review
board one of the questions we had to deal with was the licensing
question (i.e. what license was any open source licensed under). The
upshot was that legal had to approve the license. Some were already
approved and variations need to be verified by legal via a self
reporting process. The net result is that if the license is approved
the software was approved for use on the IBM infrastructure. If you
are producing a product there may be other issues.
On Thu, Sep 13, 2012 at 4:37 PM, Simon Helsen <sh...@ca.ibm.com> wrote:
> Andy,
>
> I'll bring this back to our legal, but they told me that apparently, when
> a project in Apache releases, Apache has done the appropriate internal
> legal review and makes certain guarantees. I do not know if that "internal
> legal review" happens in practice, but for IBM that makes a big
> difference, probably in terms of liability. Perhaps you are trying to say
> that each produced build, and by that, I mean the sources packaged in that
> build (not some PGP-signed binaries), are implicitly "cleared". If that is
> true, things would be easier for us.
>
> I'll follow-up on this
>
> Simon
>
>
>
> From:
> Andy Seaborne <an...@apache.org>
> To:
> Simon Helsen/Toronto/IBM@IBMCA
> Cc:
> dev@jena.apache.org
> Date:
> 09/13/2012 11:20 AM
> Subject:
> Re: 2.7.4 release?
>
>
>
>> I definitely agree that the concept of RC cycles is good in principle,
>> but I don't know if lightweight will do for us. As I explained before,
>> we can only get comprehensive testing done with versions of Jena which I
>> can safely deliver in our main source control stream. Because we publish
>> milestone builds publically (on jazz.net if you're interested), each
>> milestone needs legal approval for 3rd party libraries. I was told that
>> for Apache libraries we can only do this for releases because of certain
>> IBM assumptions about Apache releases (don't ask me what, IBM just has a
>> certain relation with Apache which makes this the way it is). And this
>> process fortunately does not take very long.
>>
>> In other words, if you introduce an RC, it would only help us if you
>> perform the same tasks as you do with a regular release, make it
>> available on the website like you do with a regular release, but just
>> use a different name to indicate that it may not be mature. It would be
>> a bit of a naming game, but it would take away the effect that you come
>> out with a possibly buggy release, yet you give your consumers a chance
>> to fully adopt and test the RC
>
> We use Continuous Integration - the nightly build runs all the tests
> every time. We also use have a "green line" policy (we haven't
> discussed this per se but it is how things run) whereby trunk always
> works. So, in that sense, every nightly build is a uniquely labelled RC.
>
> As to releases - from Apache, only the source code has real status. The
> maven binaries are PGP-signed by the person doing the build and not
> Apache. "Open source" is both "open" (you can change it) and "source"
> (not binary). A formal release is a vote on a specific source-release
> artifact (which for Jena is a snapshot of SVN).
>
> A top level project has many degrees of freedom but this isn't one of
> them. Sometime in the future, formal binaries may happen - OpenOffice
> want to release ASF-signed binaries but it will involve getting
> authenticated build systems in place. It's quite complicated because of
> the implications and assurances that formal signing brings.
>
> Andy
>
>>
>> thoughts?
>>
>> Simon
>>
>>
>> From: Andy Seaborne <an...@apache.org>
>> To: dev@jena.apache.org
>> Date: 09/13/2012 07:27 AM
>> Subject: Re: 2.7.4 release?
>>
>>
>> ------------------------------------------------------------------------
>>
>> log.info("ABCDEFGHIJKLMNOP") ;
>
>>
>> On 12/09/12 20:49, Simon Helsen wrote:
>> > On the testing front, we just got one of our clients to run a
>> > scalability test (meaning they run with a large starting repository
> and
>> > fire up multiple users to perform read/write activities) and they
>> have not
>> > observed any regressions compared to 2.7.1 and a slight overall speed
>> > improvement (something like 6%, not stellar, but most importantly not
>> > slower)
>>
>> Good to know. The crash-restart is the thing that's hardest to test for
>> in the development test suite so feedback on that would be particularly
>> useful. That's why a (lightweight) RC cycle struck me as important or
>> else we'll end up in some kind of odd/event minor release cycle (odds
>> are effectively RC's, evens are stable releases). Other people have
>> been picking up the dev release as well.
>>
>> Andy
>>
>>
>>
>
>
>
--
I like: Like Like - The likeliest place on the web
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks Andy,
we are inquiring internally in our "open source approval" organization and
legal to get more clarification on this. Once I know more, I will get back
to you since it will affect whether we can use development builds for
integrated testing or not. The bottom line is that if I am not allowed to
deliver development snapshots to our source control, there will be a very
significant limitation on what kind of testing we can do.
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
09/14/2012 08:36 AM
Subject:
Re: 2.7.4 release?
There is no "Apache" doing an internal legal review. The project
conducts these and all contributions are public.
The release provides a point where the project is confirming the status
of the code as part of the vote.
For people downloading Jena that is significant.
For people, such as yourself, who follow the project in detail, then you
can see all new material being accepted as JIRA is the only route in
over and above the direct work of committers. Everything is open and
you have complete visibility to the status of the codebase. Every code
file is licensed in SVN as well as LICENSE and NOTICE files.
I'm not suggesting you base your own releases on development builds, but
for testing purposes, there is a good baseline.
Sections 8 of the license covers liability. Additional liability you may
wish to add is covered by section 9.
Andy
On 13/09/12 16:37, Simon Helsen wrote:
> Andy,
>
> I'll bring this back to our legal, but they told me that apparently,
> when a project in Apache releases, Apache has done the appropriate
> internal legal review and makes certain guarantees. I do not know if
> that "internal legal review" happens in practice, but for IBM that makes
> a big difference, probably in terms of liability. Perhaps you are trying
> to say that each produced build, and by that, I mean the sources
> packaged in that build (not some PGP-signed binaries), are implicitly
> "cleared". If that is true, things would be easier for us.
>
> I'll follow-up on this
>
> Simon
>
>
> From: Andy Seaborne <an...@apache.org>
> To: Simon Helsen/Toronto/IBM@IBMCA
> Cc: dev@jena.apache.org
> Date: 09/13/2012 11:20 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
>
>
> > I definitely agree that the concept of RC cycles is good in
principle,
> > but I don't know if lightweight will do for us. As I explained
before,
> > we can only get comprehensive testing done with versions of Jena
which I
> > can safely deliver in our main source control stream. Because we
publish
> > milestone builds publically (on jazz.net if you're interested), each
> > milestone needs legal approval for 3rd party libraries. I was told
that
> > for Apache libraries we can only do this for releases because of
certain
> > IBM assumptions about Apache releases (don't ask me what, IBM just
has a
> > certain relation with Apache which makes this the way it is). And
this
> > process fortunately does not take very long.
> >
> > In other words, if you introduce an RC, it would only help us if you
> > perform the same tasks as you do with a regular release, make it
> > available on the website like you do with a regular release, but just
> > use a different name to indicate that it may not be mature. It would
be
> > a bit of a naming game, but it would take away the effect that you
come
> > out with a possibly buggy release, yet you give your consumers a
chance
> > to fully adopt and test the RC
>
> We use Continuous Integration - the nightly build runs all the tests
> every time. We also use have a "green line" policy (we haven't
> discussed this per se but it is how things run) whereby trunk always
> works. So, in that sense, every nightly build is a uniquely labelled
RC.
>
> As to releases - from Apache, only the source code has real status. The
> maven binaries are PGP-signed by the person doing the build and not
> Apache. "Open source" is both "open" (you can change it) and "source"
> (not binary). A formal release is a vote on a specific source-release
> artifact (which for Jena is a snapshot of SVN).
>
> A top level project has many degrees of freedom but this isn't one of
> them. Sometime in the future, formal binaries may happen - OpenOffice
> want to release ASF-signed binaries but it will involve getting
> authenticated build systems in place. It's quite complicated because of
> the implications and assurances that formal signing brings.
>
> Andy
>
> >
> > thoughts?
> >
> > Simon
> >
> >
> > From: Andy Seaborne <an...@apache.org>
> > To: dev@jena.apache.org
> > Date: 09/13/2012 07:27 AM
> > Subject: Re: 2.7.4 release?
> >
> >
> >
------------------------------------------------------------------------
> >
> > log.info("ABCDEFGHIJKLMNOP") ;
>
> >
> > On 12/09/12 20:49, Simon Helsen wrote:
> > > On the testing front, we just got one of our clients to run a
> > > scalability test (meaning they run with a large starting
> repository and
> > > fire up multiple users to perform read/write activities) and they
> > have not
> > > observed any regressions compared to 2.7.1 and a slight overall
speed
> > > improvement (something like 6%, not stellar, but most importantly
not
> > > slower)
> >
> > Good to know. The crash-restart is the thing that's hardest to test
for
> > in the development test suite so feedback on that would be
particularly
> > useful. That's why a (lightweight) RC cycle struck me as important
or
> > else we'll end up in some kind of odd/event minor release cycle (odds
> > are effectively RC's, evens are stable releases). Other people have
> > been picking up the dev release as well.
> >
> > Andy
> >
> >
> >
>
>
>
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
There is no "Apache" doing an internal legal review. The project
conducts these and all contributions are public.
The release provides a point where the project is confirming the status
of the code as part of the vote.
For people downloading Jena that is significant.
For people, such as yourself, who follow the project in detail, then you
can see all new material being accepted as JIRA is the only route in
over and above the direct work of committers. Everything is open and
you have complete visibility to the status of the codebase. Every code
file is licensed in SVN as well as LICENSE and NOTICE files.
I'm not suggesting you base your own releases on development builds, but
for testing purposes, there is a good baseline.
Sections 8 of the license covers liability. Additional liability you may
wish to add is covered by section 9.
Andy
On 13/09/12 16:37, Simon Helsen wrote:
> Andy,
>
> I'll bring this back to our legal, but they told me that apparently,
> when a project in Apache releases, Apache has done the appropriate
> internal legal review and makes certain guarantees. I do not know if
> that "internal legal review" happens in practice, but for IBM that makes
> a big difference, probably in terms of liability. Perhaps you are trying
> to say that each produced build, and by that, I mean the sources
> packaged in that build (not some PGP-signed binaries), are implicitly
> "cleared". If that is true, things would be easier for us.
>
> I'll follow-up on this
>
> Simon
>
>
> From: Andy Seaborne <an...@apache.org>
> To: Simon Helsen/Toronto/IBM@IBMCA
> Cc: dev@jena.apache.org
> Date: 09/13/2012 11:20 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
>
>
> > I definitely agree that the concept of RC cycles is good in principle,
> > but I don't know if lightweight will do for us. As I explained before,
> > we can only get comprehensive testing done with versions of Jena which I
> > can safely deliver in our main source control stream. Because we publish
> > milestone builds publically (on jazz.net if you're interested), each
> > milestone needs legal approval for 3rd party libraries. I was told that
> > for Apache libraries we can only do this for releases because of certain
> > IBM assumptions about Apache releases (don't ask me what, IBM just has a
> > certain relation with Apache which makes this the way it is). And this
> > process fortunately does not take very long.
> >
> > In other words, if you introduce an RC, it would only help us if you
> > perform the same tasks as you do with a regular release, make it
> > available on the website like you do with a regular release, but just
> > use a different name to indicate that it may not be mature. It would be
> > a bit of a naming game, but it would take away the effect that you come
> > out with a possibly buggy release, yet you give your consumers a chance
> > to fully adopt and test the RC
>
> We use Continuous Integration - the nightly build runs all the tests
> every time. We also use have a "green line" policy (we haven't
> discussed this per se but it is how things run) whereby trunk always
> works. So, in that sense, every nightly build is a uniquely labelled RC.
>
> As to releases - from Apache, only the source code has real status. The
> maven binaries are PGP-signed by the person doing the build and not
> Apache. "Open source" is both "open" (you can change it) and "source"
> (not binary). A formal release is a vote on a specific source-release
> artifact (which for Jena is a snapshot of SVN).
>
> A top level project has many degrees of freedom but this isn't one of
> them. Sometime in the future, formal binaries may happen - OpenOffice
> want to release ASF-signed binaries but it will involve getting
> authenticated build systems in place. It's quite complicated because of
> the implications and assurances that formal signing brings.
>
> Andy
>
> >
> > thoughts?
> >
> > Simon
> >
> >
> > From: Andy Seaborne <an...@apache.org>
> > To: dev@jena.apache.org
> > Date: 09/13/2012 07:27 AM
> > Subject: Re: 2.7.4 release?
> >
> >
> > ------------------------------------------------------------------------
> >
> > log.info("ABCDEFGHIJKLMNOP") ;
>
> >
> > On 12/09/12 20:49, Simon Helsen wrote:
> > > On the testing front, we just got one of our clients to run a
> > > scalability test (meaning they run with a large starting
> repository and
> > > fire up multiple users to perform read/write activities) and they
> > have not
> > > observed any regressions compared to 2.7.1 and a slight overall speed
> > > improvement (something like 6%, not stellar, but most importantly not
> > > slower)
> >
> > Good to know. The crash-restart is the thing that's hardest to test for
> > in the development test suite so feedback on that would be particularly
> > useful. That's why a (lightweight) RC cycle struck me as important or
> > else we'll end up in some kind of odd/event minor release cycle (odds
> > are effectively RC's, evens are stable releases). Other people have
> > been picking up the dev release as well.
> >
> > Andy
> >
> >
> >
>
>
>
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Andy,
I'll bring this back to our legal, but they told me that apparently, when
a project in Apache releases, Apache has done the appropriate internal
legal review and makes certain guarantees. I do not know if that "internal
legal review" happens in practice, but for IBM that makes a big
difference, probably in terms of liability. Perhaps you are trying to say
that each produced build, and by that, I mean the sources packaged in that
build (not some PGP-signed binaries), are implicitly "cleared". If that is
true, things would be easier for us.
I'll follow-up on this
Simon
From:
Andy Seaborne <an...@apache.org>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org
Date:
09/13/2012 11:20 AM
Subject:
Re: 2.7.4 release?
> I definitely agree that the concept of RC cycles is good in principle,
> but I don't know if lightweight will do for us. As I explained before,
> we can only get comprehensive testing done with versions of Jena which I
> can safely deliver in our main source control stream. Because we publish
> milestone builds publically (on jazz.net if you're interested), each
> milestone needs legal approval for 3rd party libraries. I was told that
> for Apache libraries we can only do this for releases because of certain
> IBM assumptions about Apache releases (don't ask me what, IBM just has a
> certain relation with Apache which makes this the way it is). And this
> process fortunately does not take very long.
>
> In other words, if you introduce an RC, it would only help us if you
> perform the same tasks as you do with a regular release, make it
> available on the website like you do with a regular release, but just
> use a different name to indicate that it may not be mature. It would be
> a bit of a naming game, but it would take away the effect that you come
> out with a possibly buggy release, yet you give your consumers a chance
> to fully adopt and test the RC
We use Continuous Integration - the nightly build runs all the tests
every time. We also use have a "green line" policy (we haven't
discussed this per se but it is how things run) whereby trunk always
works. So, in that sense, every nightly build is a uniquely labelled RC.
As to releases - from Apache, only the source code has real status. The
maven binaries are PGP-signed by the person doing the build and not
Apache. "Open source" is both "open" (you can change it) and "source"
(not binary). A formal release is a vote on a specific source-release
artifact (which for Jena is a snapshot of SVN).
A top level project has many degrees of freedom but this isn't one of
them. Sometime in the future, formal binaries may happen - OpenOffice
want to release ASF-signed binaries but it will involve getting
authenticated build systems in place. It's quite complicated because of
the implications and assurances that formal signing brings.
Andy
>
> thoughts?
>
> Simon
>
>
> From: Andy Seaborne <an...@apache.org>
> To: dev@jena.apache.org
> Date: 09/13/2012 07:27 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
> log.info("ABCDEFGHIJKLMNOP") ;
>
> On 12/09/12 20:49, Simon Helsen wrote:
> > On the testing front, we just got one of our clients to run a
> > scalability test (meaning they run with a large starting repository
and
> > fire up multiple users to perform read/write activities) and they
> have not
> > observed any regressions compared to 2.7.1 and a slight overall speed
> > improvement (something like 6%, not stellar, but most importantly not
> > slower)
>
> Good to know. The crash-restart is the thing that's hardest to test for
> in the development test suite so feedback on that would be particularly
> useful. That's why a (lightweight) RC cycle struck me as important or
> else we'll end up in some kind of odd/event minor release cycle (odds
> are effectively RC's, evens are stable releases). Other people have
> been picking up the dev release as well.
>
> Andy
>
>
>
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
> I definitely agree that the concept of RC cycles is good in principle,
> but I don't know if lightweight will do for us. As I explained before,
> we can only get comprehensive testing done with versions of Jena which I
> can safely deliver in our main source control stream. Because we publish
> milestone builds publically (on jazz.net if you're interested), each
> milestone needs legal approval for 3rd party libraries. I was told that
> for Apache libraries we can only do this for releases because of certain
> IBM assumptions about Apache releases (don't ask me what, IBM just has a
> certain relation with Apache which makes this the way it is). And this
> process fortunately does not take very long.
>
> In other words, if you introduce an RC, it would only help us if you
> perform the same tasks as you do with a regular release, make it
> available on the website like you do with a regular release, but just
> use a different name to indicate that it may not be mature. It would be
> a bit of a naming game, but it would take away the effect that you come
> out with a possibly buggy release, yet you give your consumers a chance
> to fully adopt and test the RC
We use Continuous Integration - the nightly build runs all the tests
every time. We also use have a "green line" policy (we haven't
discussed this per se but it is how things run) whereby trunk always
works. So, in that sense, every nightly build is a uniquely labelled RC.
As to releases - from Apache, only the source code has real status. The
maven binaries are PGP-signed by the person doing the build and not
Apache. "Open source" is both "open" (you can change it) and "source"
(not binary). A formal release is a vote on a specific source-release
artifact (which for Jena is a snapshot of SVN).
A top level project has many degrees of freedom but this isn't one of
them. Sometime in the future, formal binaries may happen - OpenOffice
want to release ASF-signed binaries but it will involve getting
authenticated build systems in place. It's quite complicated because of
the implications and assurances that formal signing brings.
Andy
>
> thoughts?
>
> Simon
>
>
> From: Andy Seaborne <an...@apache.org>
> To: dev@jena.apache.org
> Date: 09/13/2012 07:27 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
> log.info("ABCDEFGHIJKLMNOP") ;
>
> On 12/09/12 20:49, Simon Helsen wrote:
> > On the testing front, we just got one of our clients to run a
> > scalability test (meaning they run with a large starting repository and
> > fire up multiple users to perform read/write activities) and they
> have not
> > observed any regressions compared to 2.7.1 and a slight overall speed
> > improvement (something like 6%, not stellar, but most importantly not
> > slower)
>
> Good to know. The crash-restart is the thing that's hardest to test for
> in the development test suite so feedback on that would be particularly
> useful. That's why a (lightweight) RC cycle struck me as important or
> else we'll end up in some kind of odd/event minor release cycle (odds
> are effectively RC's, evens are stable releases). Other people have
> been picking up the dev release as well.
>
> Andy
>
>
>
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks Andy.
So the overall response times were only a bit faster as I mentioned (about
6%), but overall write activities were significantly faster as was to be
expected given the changes made there, in some cases 40%
So yes, I definitely understand that there are aspects which cannot
possibly ever be captured by junits. Many of the bugs we find come from
system tests where servers gets killed, run into OOMEs, get beaten with a
hammer and things like that. The other thing we do at some point during
our verification testing is run the server for a longer time with lots of
activity to monitor long-term stability. I have no results on that yet
(not even for 2.7.1) as they require product stability itself (keep in
mind that Jena is one small wheel here - even if works fine, lots of other
things often don't)
I definitely agree that the concept of RC cycles is good in principle, but
I don't know if lightweight will do for us. As I explained before, we can
only get comprehensive testing done with versions of Jena which I can
safely deliver in our main source control stream. Because we publish
milestone builds publically (on jazz.net if you're interested), each
milestone needs legal approval for 3rd party libraries. I was told that
for Apache libraries we can only do this for releases because of certain
IBM assumptions about Apache releases (don't ask me what, IBM just has a
certain relation with Apache which makes this the way it is). And this
process fortunately does not take very long.
In other words, if you introduce an RC, it would only help us if you
perform the same tasks as you do with a regular release, make it available
on the website like you do with a regular release, but just use a
different name to indicate that it may not be mature. It would be a bit of
a naming game, but it would take away the effect that you come out with a
possibly buggy release, yet you give your consumers a chance to fully
adopt and test the RC
thoughts?
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
09/13/2012 07:27 AM
Subject:
Re: 2.7.4 release?
On 12/09/12 20:49, Simon Helsen wrote:
> On the testing front, we just got one of our clients to run a
> scalability test (meaning they run with a large starting repository and
> fire up multiple users to perform read/write activities) and they have
not
> observed any regressions compared to 2.7.1 and a slight overall speed
> improvement (something like 6%, not stellar, but most importantly not
> slower)
Good to know. The crash-restart is the thing that's hardest to test for
in the development test suite so feedback on that would be particularly
useful. That's why a (lightweight) RC cycle struck me as important or
else we'll end up in some kind of odd/event minor release cycle (odds
are effectively RC's, evens are stable releases). Other people have
been picking up the dev release as well.
Andy
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
On 12/09/12 20:49, Simon Helsen wrote:
> On the testing front, we just got one of our clients to run a
> scalability test (meaning they run with a large starting repository and
> fire up multiple users to perform read/write activities) and they have not
> observed any regressions compared to 2.7.1 and a slight overall speed
> improvement (something like 6%, not stellar, but most importantly not
> slower)
Good to know. The crash-restart is the thing that's hardest to test for
in the development test suite so feedback on that would be particularly
useful. That's why a (lightweight) RC cycle struck me as important or
else we'll end up in some kind of odd/event minor release cycle (odds
are effectively RC's, evens are stable releases). Other people have
been picking up the dev release as well.
Andy
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks for the update Rob. Yes, I understand it is mostly a question for
one of the committers to have time to put it all together, assuming
nothing goes wrong and people agree that a service increment is a good
idea. There are a significant number of fixes in the transactional code as
Andy points out and we feel more comfortable with that than what we have
in 2.7.1 although they mostly affect TDB's ability to recover during a
crash. On the testing front, we just got one of our clients to run a
scalability test (meaning they run with a large starting repository and
fire up multiple users to perform read/write activities) and they have not
observed any regressions compared to 2.7.1 and a slight overall speed
improvement (something like 6%, not stellar, but most importantly not
slower)
Simon
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
Date:
09/12/2012 02:19 PM
Subject:
Re: 2.7.4 release?
Any release should take in the region of a week assuming everyone is happy
with the state of the code and people have been testing continuously.
There's no reason a release should take much longer than that unless any
serious issues crop up during the process
It's mainly a question of someone having the free time to shepherd the
process through because it is somewhat time consuming in parts
Rob
On 9/12/12 11:04 AM, "Simon Helsen" <sh...@ca.ibm.com> wrote:
>Well, we had two timescales in mind:
>
>Either very quick, i.e. sometime next week :-) That would give our
>verification testers enough time to get decent coverage before release
>and
>would just be sufficient to get legal aspects out of the way. I realize
>that would have been ambitious either way, but in the past, I have
>observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a
>week from the intend of releasing to getting it cleared and voted on.
>Anyhow, I was kind of assuming that wouldn't be possible anymore, so the
>next window of opportunity for us would be December at which point our
>integration testers would probably be in a position to hammer the thing
>and there would be plenty of room for legal.
>
>I realize this is volunteer effort, so we are not demanding anything of
>course, but 2.7.3 was not good enough for us in terms of stability and
>2.7.1, well, we can live with it, but it is not as robust under crashes
>as
>2.7.4. Also, it seems slightly faster
>
>
>
>
>From:
>Andy Seaborne <an...@apache.org>
>To:
>Simon Helsen/Toronto/IBM@IBMCA
>Cc:
>dev@jena.apache.org, Philippe P Mulet <ph...@fr.ibm.com>
>Date:
>09/12/2012 01:41 PM
>Subject:
>Re: 2.7.4 release?
>
>
>
>Simon,
>
>What timescale are you working to?
>
> Andy
>
>On 12/09/12 15:26, Simon Helsen wrote:
>> Thanks Andy
>>
>> "The changes (post TDB 0.9.3) for optimized and correct transactions
are
>> new and really could do with bedding down. If you could go beyond
basic
>> testing that would be helpful so things get raised before a .4
release."
>>
>> we are in the process of getting more comprehensive tests done,but that
>> process is quite resource intensive as you can imagine. If there is no
>> prospect of having a .4 release on time, it is also more difficult to
>> justify. You have to see it this way: we can easily test snapshots
>> (pre-releases) with our own development automated tests and some
limited
>> scalability tests of some of our clients. Beyond that, it becomes
>> cumbersome to test snapshots because we can never get legal approval
for
>> these, meaning we can't bring the changes into our main development
>> stream etc. We are then forced to produce custom builds and equip our
>> testers with these. Nothing is impossible, but some things are more
>> difficult and more importantly, take more time.
>>
>> "The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed."
>>
>> Right, however, I assume that for a .4, these APIs would just be
>> deprecated and not removed, right?
>>
>> "The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success. We have
>> reports, and something has been reported that could do with
>investigation."
>>
>> Right, I understand that, although I am not sure if an SDB release has
>> to be a prereq for a .4 service release
>>
>> "It would be nice to release LARQ as a post-incubator."
>>
>> I agree, but here as well, is that really a prereq for a service
>release?
>>
>> "Things are busy."
>>
>> no doubt
>>
>>
>> From: Andy Seaborne <an...@apache.org>
>> To: dev@jena.apache.org, Philippe P Mulet
><ph...@fr.ibm.com>
>> Date: 09/12/2012 05:06 AM
>> Subject: Re: 2.7.4 release?
>>
>>
>>
------------------------------------------------------------------------
>>
>>
>>
>> On 06/09/12 21:28, Simon Helsen wrote:
>> > hi everyone,
>> >
>> > I was wondering if there is a chance to get a 2.7.4 release soon.
>There
>> > have been numerous fixes since 2.7.3 and unfortunately, we are not
>> allowed
>> > to adopt a non-released snapshot. Basic internal testing seems to
>suggest
>> > 2.7.4 is pretty stable. Does not mean we would not find more bugs,
>but it
>> > would fit the frequent small service releases. As a non-committer, I
>> don't
>> > think I can help the process (other than testing)
>> >
>> > thanks
>> >
>> > Simon
>> >
>>
>> The changes (post TDB 0.9.3) for optimized and correct transactions are
>> new and really could do with bedding down. If you could go beyond
basic
>> testing that would be helpful so things get raised before a .4 release.
>>
>> Quite a few JIRA have had input in the last week or so and I haven't
>> managed to get a picture of where we are. The Fuseki as a WAR file
>> (JENA-201) has lots of votes.
>>
>> The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed.
>>
>> The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success. We have
>> reports, and something has been reported that could do with
>investigation.
>>
>> It would be nice to release LARQ as a post-incubator.
>>
>> Things are busy.
>>
>> I wonder if an RC phase is the best way forward.
>>
>> (all) What things would ideally be done before a RC phase can start?
>>
>> Andy
>>
>>
>>
>
>
>
Re: 2.7.4 release?
Posted by Rob Vesse <rv...@yarcdata.com>.
Any release should take in the region of a week assuming everyone is happy
with the state of the code and people have been testing continuously.
There's no reason a release should take much longer than that unless any
serious issues crop up during the process
It's mainly a question of someone having the free time to shepherd the
process through because it is somewhat time consuming in parts
Rob
On 9/12/12 11:04 AM, "Simon Helsen" <sh...@ca.ibm.com> wrote:
>Well, we had two timescales in mind:
>
>Either very quick, i.e. sometime next week :-) That would give our
>verification testers enough time to get decent coverage before release
>and
>would just be sufficient to get legal aspects out of the way. I realize
>that would have been ambitious either way, but in the past, I have
>observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a
>week from the intend of releasing to getting it cleared and voted on.
>Anyhow, I was kind of assuming that wouldn't be possible anymore, so the
>next window of opportunity for us would be December at which point our
>integration testers would probably be in a position to hammer the thing
>and there would be plenty of room for legal.
>
>I realize this is volunteer effort, so we are not demanding anything of
>course, but 2.7.3 was not good enough for us in terms of stability and
>2.7.1, well, we can live with it, but it is not as robust under crashes
>as
>2.7.4. Also, it seems slightly faster
>
>
>
>
>From:
>Andy Seaborne <an...@apache.org>
>To:
>Simon Helsen/Toronto/IBM@IBMCA
>Cc:
>dev@jena.apache.org, Philippe P Mulet <ph...@fr.ibm.com>
>Date:
>09/12/2012 01:41 PM
>Subject:
>Re: 2.7.4 release?
>
>
>
>Simon,
>
>What timescale are you working to?
>
> Andy
>
>On 12/09/12 15:26, Simon Helsen wrote:
>> Thanks Andy
>>
>> "The changes (post TDB 0.9.3) for optimized and correct transactions are
>> new and really could do with bedding down. If you could go beyond basic
>> testing that would be helpful so things get raised before a .4 release."
>>
>> we are in the process of getting more comprehensive tests done,but that
>> process is quite resource intensive as you can imagine. If there is no
>> prospect of having a .4 release on time, it is also more difficult to
>> justify. You have to see it this way: we can easily test snapshots
>> (pre-releases) with our own development automated tests and some limited
>> scalability tests of some of our clients. Beyond that, it becomes
>> cumbersome to test snapshots because we can never get legal approval for
>> these, meaning we can't bring the changes into our main development
>> stream etc. We are then forced to produce custom builds and equip our
>> testers with these. Nothing is impossible, but some things are more
>> difficult and more importantly, take more time.
>>
>> "The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed."
>>
>> Right, however, I assume that for a .4, these APIs would just be
>> deprecated and not removed, right?
>>
>> "The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success. We have
>> reports, and something has been reported that could do with
>investigation."
>>
>> Right, I understand that, although I am not sure if an SDB release has
>> to be a prereq for a .4 service release
>>
>> "It would be nice to release LARQ as a post-incubator."
>>
>> I agree, but here as well, is that really a prereq for a service
>release?
>>
>> "Things are busy."
>>
>> no doubt
>>
>>
>> From: Andy Seaborne <an...@apache.org>
>> To: dev@jena.apache.org, Philippe P Mulet
><ph...@fr.ibm.com>
>> Date: 09/12/2012 05:06 AM
>> Subject: Re: 2.7.4 release?
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> On 06/09/12 21:28, Simon Helsen wrote:
>> > hi everyone,
>> >
>> > I was wondering if there is a chance to get a 2.7.4 release soon.
>There
>> > have been numerous fixes since 2.7.3 and unfortunately, we are not
>> allowed
>> > to adopt a non-released snapshot. Basic internal testing seems to
>suggest
>> > 2.7.4 is pretty stable. Does not mean we would not find more bugs,
>but it
>> > would fit the frequent small service releases. As a non-committer, I
>> don't
>> > think I can help the process (other than testing)
>> >
>> > thanks
>> >
>> > Simon
>> >
>>
>> The changes (post TDB 0.9.3) for optimized and correct transactions are
>> new and really could do with bedding down. If you could go beyond basic
>> testing that would be helpful so things get raised before a .4 release.
>>
>> Quite a few JIRA have had input in the last week or so and I haven't
>> managed to get a picture of where we are. The Fuseki as a WAR file
>> (JENA-201) has lots of votes.
>>
>> The deprecations in jena-core could do with some inspection before a
>> release because the point of deprecating them is that they can then get
>> removed.
>>
>> The SDB release cycle is going quite well - and doing a lightweight
>> community "Release Candidate" seems to have been a success. We have
>> reports, and something has been reported that could do with
>investigation.
>>
>> It would be nice to release LARQ as a post-incubator.
>>
>> Things are busy.
>>
>> I wonder if an RC phase is the best way forward.
>>
>> (all) What things would ideally be done before a RC phase can start?
>>
>> Andy
>>
>>
>>
>
>
>
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Well, we had two timescales in mind:
Either very quick, i.e. sometime next week :-) That would give our
verification testers enough time to get decent coverage before release and
would just be sufficient to get legal aspects out of the way. I realize
that would have been ambitious either way, but in the past, I have
observed with Jena 2.7.2 and Jena 2.7.3, it took you guys no more than a
week from the intend of releasing to getting it cleared and voted on.
Anyhow, I was kind of assuming that wouldn't be possible anymore, so the
next window of opportunity for us would be December at which point our
integration testers would probably be in a position to hammer the thing
and there would be plenty of room for legal.
I realize this is volunteer effort, so we are not demanding anything of
course, but 2.7.3 was not good enough for us in terms of stability and
2.7.1, well, we can live with it, but it is not as robust under crashes as
2.7.4. Also, it seems slightly faster
From:
Andy Seaborne <an...@apache.org>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org, Philippe P Mulet <ph...@fr.ibm.com>
Date:
09/12/2012 01:41 PM
Subject:
Re: 2.7.4 release?
Simon,
What timescale are you working to?
Andy
On 12/09/12 15:26, Simon Helsen wrote:
> Thanks Andy
>
> "The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down. If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release."
>
> we are in the process of getting more comprehensive tests done,but that
> process is quite resource intensive as you can imagine. If there is no
> prospect of having a .4 release on time, it is also more difficult to
> justify. You have to see it this way: we can easily test snapshots
> (pre-releases) with our own development automated tests and some limited
> scalability tests of some of our clients. Beyond that, it becomes
> cumbersome to test snapshots because we can never get legal approval for
> these, meaning we can't bring the changes into our main development
> stream etc. We are then forced to produce custom builds and equip our
> testers with these. Nothing is impossible, but some things are more
> difficult and more importantly, take more time.
>
> "The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed."
>
> Right, however, I assume that for a .4, these APIs would just be
> deprecated and not removed, right?
>
> "The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success. We have
> reports, and something has been reported that could do with
investigation."
>
> Right, I understand that, although I am not sure if an SDB release has
> to be a prereq for a .4 service release
>
> "It would be nice to release LARQ as a post-incubator."
>
> I agree, but here as well, is that really a prereq for a service
release?
>
> "Things are busy."
>
> no doubt
>
>
> From: Andy Seaborne <an...@apache.org>
> To: dev@jena.apache.org, Philippe P Mulet
<ph...@fr.ibm.com>
> Date: 09/12/2012 05:06 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
>
>
> On 06/09/12 21:28, Simon Helsen wrote:
> > hi everyone,
> >
> > I was wondering if there is a chance to get a 2.7.4 release soon.
There
> > have been numerous fixes since 2.7.3 and unfortunately, we are not
> allowed
> > to adopt a non-released snapshot. Basic internal testing seems to
suggest
> > 2.7.4 is pretty stable. Does not mean we would not find more bugs,
but it
> > would fit the frequent small service releases. As a non-committer, I
> don't
> > think I can help the process (other than testing)
> >
> > thanks
> >
> > Simon
> >
>
> The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down. If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release.
>
> Quite a few JIRA have had input in the last week or so and I haven't
> managed to get a picture of where we are. The Fuseki as a WAR file
> (JENA-201) has lots of votes.
>
> The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed.
>
> The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success. We have
> reports, and something has been reported that could do with
investigation.
>
> It would be nice to release LARQ as a post-incubator.
>
> Things are busy.
>
> I wonder if an RC phase is the best way forward.
>
> (all) What things would ideally be done before a RC phase can start?
>
> Andy
>
>
>
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
Simon,
What timescale are you working to?
Andy
On 12/09/12 15:26, Simon Helsen wrote:
> Thanks Andy
>
> "The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down. If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release."
>
> we are in the process of getting more comprehensive tests done,but that
> process is quite resource intensive as you can imagine. If there is no
> prospect of having a .4 release on time, it is also more difficult to
> justify. You have to see it this way: we can easily test snapshots
> (pre-releases) with our own development automated tests and some limited
> scalability tests of some of our clients. Beyond that, it becomes
> cumbersome to test snapshots because we can never get legal approval for
> these, meaning we can't bring the changes into our main development
> stream etc. We are then forced to produce custom builds and equip our
> testers with these. Nothing is impossible, but some things are more
> difficult and more importantly, take more time.
>
> "The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed."
>
> Right, however, I assume that for a .4, these APIs would just be
> deprecated and not removed, right?
>
> "The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success. We have
> reports, and something has been reported that could do with investigation."
>
> Right, I understand that, although I am not sure if an SDB release has
> to be a prereq for a .4 service release
>
> "It would be nice to release LARQ as a post-incubator."
>
> I agree, but here as well, is that really a prereq for a service release?
>
> "Things are busy."
>
> no doubt
>
>
> From: Andy Seaborne <an...@apache.org>
> To: dev@jena.apache.org, Philippe P Mulet <ph...@fr.ibm.com>
> Date: 09/12/2012 05:06 AM
> Subject: Re: 2.7.4 release?
>
>
> ------------------------------------------------------------------------
>
>
>
> On 06/09/12 21:28, Simon Helsen wrote:
> > hi everyone,
> >
> > I was wondering if there is a chance to get a 2.7.4 release soon. There
> > have been numerous fixes since 2.7.3 and unfortunately, we are not
> allowed
> > to adopt a non-released snapshot. Basic internal testing seems to suggest
> > 2.7.4 is pretty stable. Does not mean we would not find more bugs, but it
> > would fit the frequent small service releases. As a non-committer, I
> don't
> > think I can help the process (other than testing)
> >
> > thanks
> >
> > Simon
> >
>
> The changes (post TDB 0.9.3) for optimized and correct transactions are
> new and really could do with bedding down. If you could go beyond basic
> testing that would be helpful so things get raised before a .4 release.
>
> Quite a few JIRA have had input in the last week or so and I haven't
> managed to get a picture of where we are. The Fuseki as a WAR file
> (JENA-201) has lots of votes.
>
> The deprecations in jena-core could do with some inspection before a
> release because the point of deprecating them is that they can then get
> removed.
>
> The SDB release cycle is going quite well - and doing a lightweight
> community "Release Candidate" seems to have been a success. We have
> reports, and something has been reported that could do with investigation.
>
> It would be nice to release LARQ as a post-incubator.
>
> Things are busy.
>
> I wonder if an RC phase is the best way forward.
>
> (all) What things would ideally be done before a RC phase can start?
>
> Andy
>
>
>
Re: 2.7.4 release?
Posted by Simon Helsen <sh...@ca.ibm.com>.
Thanks Andy
"The changes (post TDB 0.9.3) for optimized and correct transactions are
new and really could do with bedding down. If you could go beyond basic
testing that would be helpful so things get raised before a .4 release."
we are in the process of getting more comprehensive tests done, but that
process is quite resource intensive as you can imagine. If there is no
prospect of having a .4 release on time, it is also more difficult to
justify. You have to see it this way: we can easily test snapshots
(pre-releases) with our own development automated tests and some limited
scalability tests of some of our clients. Beyond that, it becomes
cumbersome to test snapshots because we can never get legal approval for
these, meaning we can't bring the changes into our main development stream
etc. We are then forced to produce custom builds and equip our testers
with these. Nothing is impossible, but some things are more difficult and
more importantly, take more time.
"The deprecations in jena-core could do with some inspection before a
release because the point of deprecating them is that they can then get
removed."
Right, however, I assume that for a .4, these APIs would just be
deprecated and not removed, right?
"The SDB release cycle is going quite well - and doing a lightweight
community "Release Candidate" seems to have been a success. We have
reports, and something has been reported that could do with investigation.
"
Right, I understand that, although I am not sure if an SDB release has to
be a prereq for a .4 service release
"It would be nice to release LARQ as a post-incubator."
I agree, but here as well, is that really a prereq for a service release?
"Things are busy."
no doubt
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org, Philippe P Mulet <ph...@fr.ibm.com>
Date:
09/12/2012 05:06 AM
Subject:
Re: 2.7.4 release?
On 06/09/12 21:28, Simon Helsen wrote:
> hi everyone,
>
> I was wondering if there is a chance to get a 2.7.4 release soon. There
> have been numerous fixes since 2.7.3 and unfortunately, we are not
allowed
> to adopt a non-released snapshot. Basic internal testing seems to
suggest
> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but
it
> would fit the frequent small service releases. As a non-committer, I
don't
> think I can help the process (other than testing)
>
> thanks
>
> Simon
>
The changes (post TDB 0.9.3) for optimized and correct transactions are
new and really could do with bedding down. If you could go beyond basic
testing that would be helpful so things get raised before a .4 release.
Quite a few JIRA have had input in the last week or so and I haven't
managed to get a picture of where we are. The Fuseki as a WAR file
(JENA-201) has lots of votes.
The deprecations in jena-core could do with some inspection before a
release because the point of deprecating them is that they can then get
removed.
The SDB release cycle is going quite well - and doing a lightweight
community "Release Candidate" seems to have been a success. We have
reports, and something has been reported that could do with investigation.
It would be nice to release LARQ as a post-incubator.
Things are busy.
I wonder if an RC phase is the best way forward.
(all) What things would ideally be done before a RC phase can start?
Andy
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
On 12/09/12 17:58, Rob Vesse wrote:> I plan to take a look at the Fuseki
as a WAR again at some point but am
> fairly snowed under at the moment
You are not alone ...
> Also it's a non-trivial change which may also require some maven and
> svn shenanigans if we want to generate both a WAR and the existing
> runnable JAR packaging (possibly splitting the fuseki module into a
> fuseki-core and fuseki-war). Plus I have no idea if the provided
> patch is all that is needed or not.
I think we need to think this through before releasing anything because
a release is a commitment to the approach.
The patch puts fuseki-config.ttl in the webapp (in WEB-INF) but I'm
being in think that having the config and any TDB databases outside the
WAR is better long term. The WAR file is then fixed (there is only one)
and the user does not have build or edit it.
More discussion on the JENA-201 thread.
Andy
Re: 2.7.4 release?
Posted by Rob Vesse <rv...@yarcdata.com>.
I plan to take a look at the Fuseki as a WAR again at some point but am
fairly snowed under at the moment
Also it's a non-trivial change which may also require some maven and svn
shenanigans if we want to generate both a WAR and the existing runnable
JAR packaging (possibly splitting the fuseki module into a fuseki-core and
fuseki-war). Plus I have no idea if the provided patch is all that is
needed or not.
I would rather not do this in a rush or for a point release, this should
be at least a minor if not major release for Fuseki when we make that
change.
Just because something has lots of votes and is a good idea doesn't mean
we should rush it!
Rob
On 9/12/12 2:05 AM, "Andy Seaborne" <an...@apache.org> wrote:
>On 06/09/12 21:28, Simon Helsen wrote:
>> hi everyone,
>>
>> I was wondering if there is a chance to get a 2.7.4 release soon. There
>> have been numerous fixes since 2.7.3 and unfortunately, we are not
>>allowed
>> to adopt a non-released snapshot. Basic internal testing seems to
>>suggest
>> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but
>>it
>> would fit the frequent small service releases. As a non-committer, I
>>don't
>> think I can help the process (other than testing)
>>
>> thanks
>>
>> Simon
>>
>
>The changes (post TDB 0.9.3) for optimized and correct transactions are
>new and really could do with bedding down. If you could go beyond basic
>testing that would be helpful so things get raised before a .4 release.
>
>Quite a few JIRA have had input in the last week or so and I haven't
>managed to get a picture of where we are. The Fuseki as a WAR file
>(JENA-201) has lots of votes.
>
>The deprecations in jena-core could do with some inspection before a
>release because the point of deprecating them is that they can then get
>removed.
>
>The SDB release cycle is going quite well - and doing a lightweight
>community "Release Candidate" seems to have been a success. We have
>reports, and something has been reported that could do with investigation.
>
>It would be nice to release LARQ as a post-incubator.
>
>Things are busy.
>
>I wonder if an RC phase is the best way forward.
>
>(all) What things would ideally be done before a RC phase can start?
>
> Andy
>
Re: 2.7.4 release?
Posted by Andy Seaborne <an...@apache.org>.
On 06/09/12 21:28, Simon Helsen wrote:
> hi everyone,
>
> I was wondering if there is a chance to get a 2.7.4 release soon. There
> have been numerous fixes since 2.7.3 and unfortunately, we are not allowed
> to adopt a non-released snapshot. Basic internal testing seems to suggest
> 2.7.4 is pretty stable. Does not mean we would not find more bugs, but it
> would fit the frequent small service releases. As a non-committer, I don't
> think I can help the process (other than testing)
>
> thanks
>
> Simon
>
The changes (post TDB 0.9.3) for optimized and correct transactions are
new and really could do with bedding down. If you could go beyond basic
testing that would be helpful so things get raised before a .4 release.
Quite a few JIRA have had input in the last week or so and I haven't
managed to get a picture of where we are. The Fuseki as a WAR file
(JENA-201) has lots of votes.
The deprecations in jena-core could do with some inspection before a
release because the point of deprecating them is that they can then get
removed.
The SDB release cycle is going quite well - and doing a lightweight
community "Release Candidate" seems to have been a success. We have
reports, and something has been reported that could do with investigation.
It would be nice to release LARQ as a post-incubator.
Things are busy.
I wonder if an RC phase is the best way forward.
(all) What things would ideally be done before a RC phase can start?
Andy