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 <[email protected]> To: [email protected] 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 <[email protected]> > To: Simon Helsen/Toronto/IBM@IBMCA > Cc: [email protected] > 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 <[email protected]> > > To: [email protected] > > 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 > > > > > > > > >
