On 17/08/10 4:28 AM, Mike Kienenberger wrote:
> But if you want to say that we're meeting the source build
> requirement, consider this. It would mean that everyone voting +1 on a
> release has somehow thrown a home-grown build-system on top of the
> source release and successfully built it.
I disagree that this level of diligence is required of PMC members, for several reasons:
1. I've been involved in a few not-for-profits over the years, and a common issue is volunteer burnout. We have to be careful from a purely practical point of view how much effort we are requiring from our volunteers to perform largely administrative tasks. There is a difference between QA and ensuring that Cayenne is being run as a proper Apache project.
2. There are systems and processes in place which can be invoked instead of a laborious check through every release. For example, we know the source builds because Hudson builds it and runs the tests. We know the source in the package matches what is in svn because we trust the maven script does what is intended.
That's not to say due diligence that you have performed isn't a good idea from time to time. But it will drive us insane to say that it is required of every PMC member for every release to take the source package, rebuild the jars and confirm that they match checksums, etc
Instead I've been focussing on taking the binary output and running it through tests in my own applications (in a real life use of the product). I've been looking at ensuring that no major build issues got through (like part of the package didn't get compiled in).
Your catches on the licenses are good. We should probably include RAT [1] in our automated Hudson tests. I'll do that as soon as I figure out the build issues I have right now in my upgrading of Clover within the project. In addition, we can check that infra have already got a script which verifies all the file hashes in the download directory. I suspect they do.
On 17/08/10 5:19 AM, Mike Kienenberger wrote:
> Ignoring the problem of 3rd party jar files, I think we can make a
> huge step forward by sticking the svn checkout contents into the src
> directory -- at that point, we have "buildable" (at least today)
> source.
Distributing the source in my opinion is always going to be more a formality (and an insurance against major catastrophe at the Apache Foundation). Someone actually wanting to develop Cayenne will be better off pulling down the source from svn. But I don't know that we need to ensure that it is *easy* for someone to take the downloaded source and set up a project in Eclipse. I just don't think that is going to happen.
If the source files get too big, we could distribute them separately. As you say, just a dump of the svn repository zipped up at the point in time.
Given all the above, I am currently +1 on releasing 3.0.1 exactly as it is. And of course, continuing to improve our release process and NOTICE files for the next releases. Releases that are less work to create/verify and made more often would be my preference.
Regards
Ari
[1] http://incubator.apache.org/rat/apache-rat-plugin/examples/basic.html
-- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Tue Aug 17 2010 - 07:53:16 UTC