Re: [VOTE] release 3.0.1

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon Aug 16 2010 - 17:41:53 UTC

  • Next message: Mike Kienenberger: "Buildable source packages"

    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