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: <4EEE26BE.5040209@apache.org>
Date: Sun, 18 Dec 2011 17:45:34 +0000
From: Andy Seaborne <andy@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: [] Release Jena 2.7.0
References: <4EE8E0C1.7030608@apache.org> <4EECF24F.20009@googlemail.com>
In-Reply-To: <4EECF24F.20009@googlemail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> Comments and rationale (longer version):
>
>
> The dist area is used by people and reducing choices there, in future releases,
> would be a great improvement. For example, I was not sure about the difference
> between:
>
>    apache-jena-2.7.0-incubating.tar.bz2      14-Dec-2011 15:50   14M
>    apache-jena-2.7.0-incubating.tar.gz       14-Dec-2011 15:44   16M
>
> I did not find a difference, so is apache-jena-2.7.0-incubating.tar.bz2
> necessary?

See
http://incubator.apache.org/guides/releasemanagement.html

and as an example:
http://www.apache.org/dist/ant/binaries/

These are the same set of files, packaged differently.  bzip2 is 
sometimes significantly smaller.

> The instruction to recreate the release in the BUILD file found in
> apache-jena-2.7.0-incubating-source-release.zip involve a lot of manual
> steps (fortunately it's something most of the people will not need to go
> through). Ideally, it could be: download, uncompress and run a command.
> Easier to document, less likely something goes wrong.

I thought we'd agreed this long ago.
This release is to get something out of the door now.

1/ This could easily be scripted

2/ Doing the build of the modules isn't the time consuming part. 
Checking and fixing is.  I built the entire cycle twice - one script 
saves a little time and effort but there are far bigger cost in doing a 
release, like writing all the emails.

3/ This is at-odds with not putting the download zip in maven.


I've suggested a change to a single-trunk multi-module build already so 
I'm not sure what point you are making here.

For a single-trunk multi-module, like all the project you keep pointing 
to, we can have a single build.  Multi-trunk, multi-module is a 
non-starter because of RAT, version tags and mvn release plugin 
assumptions.  But we will loose the ability to branch modules as we do 
at the moment.

JenaDist replaces the a replacement source-release artifact creator.  It 
does not create a complete image of the development systems at the point 
of release to match the SVN tag; it creates a special composite that 
isn't tested. The point of RAT is to capture common practice.

> This is an example of ideal 'dist' area which I would be more happy with:

Why are you unhappy?  You use Jena from maven - this does not affect you.

The statement
jena.staging.apache.org/jena/download/index.html

"""
You can download official Apache releases from here:

     www.apache.org/dist/incubator/jena/
"""

will lead as directly as possible to the latest version.

Building version numbers into documentation is to be strongly avoided 
IMHO.  (I'd remove them from that page - they don't get maintained 
especially at the point of release when there is enough to do already - 
but "thank you" to Ian for making sure it's ready to go).

>    http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/

Have you checked what is proposed?

http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/apache-jena-2.7.0-incubating/

Those files are all there exactly as you have them.  +bz2 (separate issue).

In addition, the latest download is top level as explained to make it 
easy for people, especially non-maven, novice users.

>    apache-jena-x.y.z-incubating.tar.gz
>    apache-jena-x.y.z-incubating.tar.gz.asc
>    apache-jena-x.y.z-incubating.tar.gz.md5
>    apache-jena-x.y.z-incubating.tar.gz.sha1
>    apache-jena-x.y.z-incubating.zip
>    apache-jena-x.y.z-incubating.zip.asc
>    apache-jena-x.y.z-incubating.zip.md5
>    apache-jena-x.y.z-incubating.zip.sha1
>    apache-jena-x.y.z-incubating-source-release.tar.gz (*)
>    apache-jena-x.y.z-incubating-source-release.tar.gz.asc
>    apache-jena-x.y.z-incubating-source-release.tar.gz.md5
>    apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>
> ... or, if people on Windows can uncompress a .tar.gz,

They can't, without additional, non-standard programs.  Support for zip 
files is built-in to Windows.

For more, see
http://incubator.apache.org/guides/releasemanagement.html

> and there is no
> difference between the content of:
>    apache-jena-x.y.z-incubating.tar.gz
>    apache-jena-x.y.z-incubating.zip
>
> Then, the 'dist' are could have even less choices (even better):
>
>    http://w.a.o/dist/incubator/jena/apache-jena-x.y.z-incubating/
>
>    apache-jena-x.y.z-incubating.tar.gz
>    apache-jena-x.y.z-incubating.tar.gz.asc
>    apache-jena-x.y.z-incubating.tar.gz.md5
>    apache-jena-x.y.z-incubating.tar.gz.sha1
>    apache-jena-x.y.z-incubating-source-release.tar.gz (*)
>    apache-jena-x.y.z-incubating-source-release.tar.gz.asc
>    apache-jena-x.y.z-incubating-source-release.tar.gz.md5
>    apache-jena-x.y.z-incubating-source-release.tar.gz.sha1
>
> (*) this file should (if future) contain all the sources necessary to rebuild
> the binary release (i.e. apache-jena-x.y.z-incubating.tar.gz). People who
> want to recreate the binary release can download (*), uncompress and run a
> command.

And we have discussed this several times.  Release something now, create 
space for a reorg.  What is the problem with what was in the pre-release 
trial run and the current release proposal?

If, as it should be, (*) is everything, then we need a single-trunk 
multi-module layout to work with RAT.  It has pros and cons; downside - 
branching per module is changed; releasing just a module needs tagging. 
  I have no idea how the release plugin deals with it and want to test 
it out first.  I do know from experience that misconfiguring the release 
plugin will attempt to tag junk in the wrong place, not generate an 
warning or error in a dry run.

> With the dist area above, users are presented with just one choice:
> binary or sources?

"users" is a vague and broad label.

What sort of user might be looking in dist/?
novice? redistributor?

How is each of those classes of user served?

Why add an additional level of directory naming?
The file names have versions in them.  What is gained and for whom?

> An example of an Apache multi-module project which keep a 'dist' area very
> clean and usable for people is Apache Whirr:
> http://www.apache.org/dist/incubator/whirr/whirr-0.6.0-incubating/

Does whirr serve the same community Jena does?
Does it serve its community in the same way?
Who is being served from thir dist/?
Why is it called "src"?  And what does that mean?
What is the history of its community and the expectations on 
distribution, naming and layout?

Please can you explain how it applies to Jena?
Whirr does not produce a zip, yet its best practice to do so.

"Apache Whirr is a set of libraries for running cloud services."

Jena is not just a set of libraries.  You yourself keep asking about 
Fuseki which is not a library.

You continually tell users to use maven - that's your personal opinion.

I see the complete download as useful to a class of users.

> In relation to the artifacts in the Maven repo, we currently have:
>
>    https://repository.apache.org/content/repositories/orgapachejena-334/org/apache/jena/
>
>    apache-jena/
>    jena-arq/
>    jena-core/
>    jena-iri/
>    jena-top/
>
> My suggestion here, if possible, is not to publish the 'apache-jena' artifact.

And you want a single build command?

It is the maven way to publish artifacts.

Where would not-an-artifact go?
How would it get there?
What constitutes the formal release artifacts if it's split between 
maven repo and somewhere else?

If you look on incubator-general@, most maven-based projects don't even 
mention dist/.  No idea why - it seems important to me. I put it in 
because this is our first release and because I think that it should be 
mentioned in the vote.  I explained that in the message on 1/Dec about 
the pre-release trial run.

> Rationale: the files of the distribution are all available in the 'dist' area
> and apache-jena is not something people can use as their dependencies.

The dist/ area is the official release bytes.

> Right now, you cannot have:
>
>      <dependency>
>        <groupId>org.apache.jena</groupId>
>        <artifactId>apache-jena</artifactId>
>        <version>2.7.0-incubating</version>
>      </dependency>
>
> While an artifact repository is supposed to be used by programs rather than
> people, people often browse artifact repositories to find their dependencies
> or the latest version for a dependency they already have.

This is contradictory to me.  People can browse and find apache-jena.zip.

We could now add making it using Jenkins at low cost.  I don't know 
another way to do that.

>
> The principle of less choices is still valid here. More importantly,
> apache-jena would be the wrong choice and probably cause frustration
> and questions as result.
>
> Paolo
>

	Andy