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 > > >
