Le 4/24/12 1:27 PM, Francesco Chicchiriccò a écrit :
On 24/04/2012 12:55, Emmanuel Lécharny wrote:
Le 4/24/12 12:20 PM, Francesco Chicchiriccò a écrit :
On 24/04/2012 12:04, Emmanuel Lécharny wrote:
Sorry guys, but atm, I will -1 this release. (keep in mind that a
-1 is *not* a veto when it comes to releases)
I'd like to have a way to download a package containing all tghe
sources, being able to tar xzpf it, and build it to obtain the bin.
So far, either I svn co the sourcs fro SVN, or I have to grab the
signed jars in
https://repository.apache.org/content/repositories/orgapachesyncope-083/,
but then I'm facing many sub directories with signed source jars
which don't allow me to build the project.
Hi Emmanuel,
would it be enough to:
1. svn export of the release tag
2. tar zcvf
3. generate needed signatures (asc, md5, sha1, ...)
4. put these files somewhere (where?)
What we usually do is that we have a distribution sub-module that
gather everything (sources, etc), and this is what we distribute on
the web site (see
http://directory.apache.org/apacheds/2.0/downloads.html for instance,
the binaries are provided for convenience, what is important is the
last package,
http://directory.apache.org/apacheds/2.0/download/download-sources.html)
Unfortunately the provided link does not seem to be working (also
mirror change does not): when going directly to
http://www.apache.org/dist/directory/apacheds/stable/2.0/2.0.0-M6/, I
cannot find any sources package.
The only one I was able to find by browsing that repo is
http://www.apache.org/dist/directory/apacheds/unstable/1.5/1.5.7/apacheds-sources-1.5.7.zip.
Holly sh*t ! We have voted bad releases since M2 :/ Rahhhh...
Anyway, I've also taken a look at
http://openjpa.apache.org/downloads.html (source).
or http://mina.apache.org/downloads.html
In the long run, that would help you by avoiding those manual steps.
In any case, the packages have to be stored in
/www/www.apache.org/dist/incubator/syncope (see other incubator
projects). You will have to copy them by hand (atm).
You can copy the sources tarballs on your public apache directory
(people.apache.org, public.html directory), and provide the link for
the vote.
Fine: so first I will store these files in
http://people.apache.org/~ilgrosso/ for the vote.
http://people.apache.org/~ilgrosso/public.html, otherwise we won't be
able to get them.
Once (and if) the vote has passed, someone will move such files to
/www/www.apache.org/dist/incubator/syncope.
Someone = the RM.
"Before voting +1 PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that
the package contains the required contents
<http://www.apache.org/dev/release.html#what-must-every-release-contain>."
From
http://www.apache.org/dev/release.html#what-must-every-release-contain
:
"Every ASF release *must* contain a source package, which must be
sufficient for a user to build and test the release provided they
have access to the appropriate platform and tools."
Also the NOTICE file (which IMO should be found in the root of
every package, but maybe having it in META-INF is enough) should
contain references to third party components, such as activiti.org,
SpringFramework, AspectJ (with the associated license, as it has 3
diffrerent licenses for this project, depending on the version -
MPL1.1 for 1.0, CPL1.0 for 1.1 to 1.5.1, EPL1.0 for 1.5.22),
XStream (as requested by their license, you must include it),
Quartz, Groovy, SLF4J, LogBack, connid (even if it's a Tirasa
product, unless you find out a way to make it ASL 2.0 instead of
CDDL...), junit, h2 (which requires a few files to be added),
Javassist with the selected license, as it's available under MPL,
LGPL or ASL (wtf javassist guys? Can't you pick ASL2.0 and get rid
of the others ? ;), plus a mention of the other ASF project you are
using, but this is not required.
NOTICE file is included, alongside with LICENSE, in all artifacts
(see SYNCOPE-3).
Yes, I saw. I was wondering if we should not provide them at the top
level, instead of having them in META_INF
Apache parent POM 10 puts such files under META-INF, because of
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-remote-resources-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<resourceBundles>
<resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
</resourceBundles>
</configuration>
</execution>
</executions>
</plugin>
ok, not a big deal. As I said, it's probably just me. Maybe the
distrbution packages, containing the sources, should have the NOTICES
and LICENSE files at the top level.
About non ASL-2.0 dependencies, we already went through the process
of "reducing to ASL 2.0" as much as possible (the biggest move was
from Hibernate to OpenJPA), so I don't think there is room for more
replacement.
This is not an issue. Every ASL 2.0 compatible licenses are fine (ie,
MPL, CDDL, BSD, EPL,...) as soon as you mention their origin. If you
use a third party software which is released under a ASL 2.0 license,
then adding a mention in the NOTICE that you are using "Blah
Software, released under an ASL 2.0 License" just helps the potential
users, who won't have to dig the web for the third part license.
Anyway, it seems that SYNCOPE-2 should be re-opened, since NOTICE
file was not filled - as you report above: I'll do this right away.
Sorry that I waited for the release to be done to check the result.
As I said, I was off for the week-end, otherwise I would have gave a
hand...
Yes, yes, I know, I'm a PITA...
Eh eh eh, I felt like it was too much easy to jump to the first
incubating release... ;-)
Actually, you did a good job. I'm pretty sure that beside the few
remaining points, the release is correct.
In any case, be sure to read carefully
http://www.apache.org/dev/release.html. If you have any question,
feel free to ask.
A last question: what about the current vote / svn tag / staging
repository? What's the best practice in such cases?
I mean, should we simply remove svn tag, drop staging repository, fix
these release issues and then start from scratch with a new RC1 or
should we instead go with RC2?
It's up to you. But keeping a RC1 make people think that a release has
been issued and voted. I'd rather kill -9 RC1 and start again.
In any case, even if you think you are wasting your time, you are
investing in the long term.
And never forget that whatever you do, at some point, you'll miss
something if the process is not fully automated. Like missing to copy
the sources package on dist, like what we did on Directory :)
Many thanks for your patience !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
