Ari,
There is a large difference in responsibilities between a PMC member
and a committer. The job of a PMC member is not to insure that the
release is bug-free. It's to do all of these things that you say
drive you crazy, .. and more :) Insure that there are no licensing
issues. Insure that the release is properly signed. Insure that the
release is what it says it is (builds, runs). And yes, on top of
that, build a healthy community to further project development. And
guide the direction of the project too.
And while you can have an opinion that the source is a formality,
according to the ASF, the source is the product, and everything else
is a convenient add-on.
I think sometimes we don't do a good enough job explaining what a PMC
member's responsibilities are before we offer the position to someone.
All of these automated systems are great, and we should continue to
automate as much as possible, but they are just tools, and in the end
we are still responsible to insure that the tools are working as
expected for every release.
We choose to release when certain milestones are met, and that's a
good way to do things, but from the PMC point of view, we can release
at any moment, even with buggy code, because it's not the functional
content of what we release, but the legal/procedural packaging of what
we release, which defines a release.
On Tue, Aug 17, 2010 at 3:52 AM, Aristedes Maniatis <ar..aniatis.org> wrote:
> 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 - 14:23:13 UTC