Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 andy.seaborne.apache@gmail.com designates 74.125.82.43 as permitted sender)
Sender: Andy Seaborne <andy.seaborne.apache@gmail.com>
Message-ID: <4EC926AC.5040906@apache.org>
Date: Sun, 20 Nov 2011 16:11:24 +0000
From: Andy Seaborne <andy@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: Jena (i.e. jena-core): ARQ isn't included in the distribution
 zip file
References: <4EC44A4B.1090402@googlemail.com>
 <4EC45C10.7040507@googlemail.com> <4EC4F90D.9040105@apache.org>
 <4EC50A91.7080203@googlemail.com> <4EC90134.4010808@apache.org>
 <4EC912AB.6010907@googlemail.com>
In-Reply-To: <4EC912AB.6010907@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 20/11/11 14:46, Paolo Castagna wrote:
> I was just saying that a good practice it to use src/test/resources
> and load data files necessary for tests via classpath so that it's
> possible and trivial to ship a self contained and working test suite
> as a single jar. Apply this to what we have has a big cost for little
> or close to zero value. So, I aggree on no action on this.

This is the web!

Loading from the classpath does not work - some tests need a base URI 
and some test load files using relative URIs.

>> 0/ Make a top level module of Jena2
> JenaDist should have JenaTop as parent pom, but other than this I do not
> see what else we would need.

We need to have a proper SVN area for it.  We can't go with something 
tucked under /Scratch/PC/

Can you do that?

>> 4/ Needs the change logs from Jena and ARQ at least.
>>    I don't how to mechanism this - copy into JenaDist for now.
> Ok.
>
> JIRA has a "Change Log" tab which could help automating this (I often
> forget to update the CHANGELOG.txt files and I agree that is important).

Can we just concentrate on getting release done and not adding work to
the timeline? We have the ChangeLogs already (and the JIRA log is 
somewhat minimal).

We are not trying to detail every change (too much) - we're trying to 
tell people what they need to know, which isn't a detail dump of everything.

> A final comment. We will probably not get everything right with the first
> release, that's fine so long we are ready to quickly fix (via a bug fix
> release) problems as we discover them. I think "release early and often"
> applies here as we learn the release process in Apache and we try to fit
> what we used to do in a different context (with different constraints).

I don't see it like that; it's not about the code, it's the process.

We are trying to get through Apache process, including checking on 
incubator-general@  It's useful to read other incubator projects getting 
through that.

We will only get some much bandwidth from people there; it's a busy place.

While we can do dev builds, there isn't "quick" for releases.  My idea 
of "quick" is a few hours; loop time here is going to one week+ for a 
two sequential votes.  Getting it right is quite a good idea.

	Andy