I'm not an ASF member, so I don't have access to the same information
resources you do. I know there's a lot of areas where there's a great
deal of latitude, but the page I was working through seems to be using
some pretty strong language (ie, an entire "must" section, the only
one on the page).
Just from a practical point of view, I can understand why the
requirement is stated this way -- the release packages are the only
static archived copies of the project. Revision control systems come
and go, and are not immutable and sometimes old branches get corrupted
-- I remember this happening in svn on the MyFaces project, leading to
the inability to rebuild old versions.
At minimum, I think we should be getting some clarification on the
topic. Either the strong language in the master release faq should be
changed, or we need to change our processes. I can only play by the
rules/guidelines I know about.
As a project, I think we should move toward having buildable source
releases, even if we find that this is not currently a mandated
requirement, but that would be a discussion for another time.
On Mon, Aug 16, 2010 at 1:12 PM, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Hi Mike,
>
> There is a periodic discussion at various levels of Apache of how much
> procedure is mandatory. As an ASF member, my firm belief (I think shared by
> most in those discussions) is that release *packaging* is within the realm
> of PMC responsibilities, if all *legal* requirements are otherwise met (to
> me legal requirements are: no code without CLA coverage; NOTICE and LICENSE
> files complete; 3 +1 votes from PMC).
>
> Case in point is recent iBatis meltdown. The community felt overly
> constrained by the Apache release rules (not the only, but one of the main
> gripes), so they decided to quit the ASF. When the Board and members heard
> of it, there was a collective disbelief ("What release rules? Ain't PMC the
> people who determine the rules?").
>
> There are often well-intentioned attempts at various places (mainly
> incubator) to formalize this or that process with the goal to provide
> guidance to people, and those unfortunately end up appearing as "rules". But
> ultimately there is nobody but ourselves (the Cayenne PMC) to determine what
> goes in the tar.gz (with the exception of license related issues). With this
> in mind I'll be happy to fix the NOTICE file, but the source build file is a
> non-issue.
>
> Not trying to dismiss your concerns (and very happy that you actually took
> the time to turn all the rocks looking at the distro), just giving my view
> of things. Also if you think it is worth following up, let's find some
> Foundation-wide avenue (infra? legal-discuss?) and move the discussion over
> there.
>
> Cheers,
> Andrus
>
>
> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>
>> On Mon, Aug 16, 2010 at 11:22 AM, Andrus Adamchik
>> <andru..bjectstyle.org> wrote:
>>>>
>>>> Does the code build: cayenne-3.0.1.tar.gz -- I found no instructions
>>>> on building the code from the source package we distribute. I don't
>>>> see any build files either.
>>>
>>> No it doesn't, and it has never been the goal (ok, not since 1.0 when we
>>> provided Ant buildfile). It is practically impossible to do that as the
>>> build system is ... well, complex. I am sure most non-C Apache projects
>>> won't let you build from sources in the distro.
>>
>> My understanding is that we are required to release source packages that
>> build:
>>
>> http://www.apache.org/dev/release.html#what
>> =========================================
>> What Must Every ASF 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. The source package must
>> be cryptographically signed by the Release Manager with a detached
>> signature; and that package together with its signature must be tested
>> prior to voting +1 for release. Folks who vote +1 for release may
>> offer their own cryptographic signature to be concatenated with the
>> detached signature file (at the Release Manager's discretion) prior to
>> release.
>> =========================================
>>
>> Sorry to be the bearer of bad news, but if we haven't been doing this,
>> then we are not releasing legitimate ASF releases.
>>
>> I know this is incredibly inconvenient and will probably require a
>> great deal of work to fix, but if we're going to be an apache project,
>> we have to follow the apache release rules.
>>
>> I have to vote -1.
>>
>> If I've somehow misinterpreted the release requirements, let me know.
>>
>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 17:42:42 UTC