Re: [VOTE] release 3.0.1

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Aug 16 2010 - 19:18:41 UTC

  • Next message: Mike Kienenberger: "Re: [VOTE] release 3.0.1"

    fixing for both 3.0 and 3.1 is the same amount of work as just fixing
    it for 3.1...

    2.0... I hope we won't be having any more releases of that (and that's
    Ant based!!)

    Andrus

    On Aug 16, 2010, at 10:14 PM, Mike Kienenberger wrote:

    > So what do we need to do?
    >
    > Fix it for this point release? Make an exception for old point
    > releases, and only fix it for 3.1?
    >
    > Fix our latest point releases for each currently maintained branch?
    >
    > My opinion is that we should fix all of the latest point releases, but
    > I personally won't be able to do the work -- as I mentioned a couple
    > months back, I'm in the middle of a go-live deployment of a three-year
    > project for the next month or two, and I'm maven-ignorant.
    >
    > Second best would be to fix the 3.x branches.
    >
    > Third best would be to fix only 3.1.
    >
    > On Mon, Aug 16, 2010 at 3:04 PM, Andrus Adamchik <andru..bjectstyle.org
    > > wrote:
    >> So again, I am convinced by your argument and the history trail of
    >> reasoning
    >> behind it. Just feels that the solution that we might use (and that
    >> others
    >> are using) and the desired ideal are pretty far apart from each
    >> other.
    >>
    >> Andrus
    >>
    >>
    >> On Aug 16, 2010, at 9:43 PM, Andrus Adamchik wrote:
    >>
    >>> Yeah I vaguely remember this discussion -
    >>> http://markmail.org/thread/njray5dbazwcdcts and I have to agree
    >>> with Roy's
    >>> logic, which convinces me better than a mention of "policy" :-)
    >>>
    >>> Ok, so say we have a Maven build system that exports buildable
    >>> source with
    >>> poms... which, considering the reliance on a public Maven repo for
    >>> dependencies may not be that "buildable" 6 months from now :-/ Even
    >>> open-source Apache-licensed (but not ASF-managed) packages may
    >>> disappear.
    >>> How far can we go with that? (a good experiment would be to take a
    >>> year old
    >>> existing ASF package and trying to build it, say Geronimo or
    >>> something of
    >>> that level of complexity..)
    >>>
    >>> Andrus
    >>>
    >>>
    >>> On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
    >>>>
    >>>> It's one thing to state that it may not be a requirement to provide
    >>>> buildable source, but it's quite a stretch to claim that we do
    >>>> provide
    >>>> buildable source immediately after a message stating "It is
    >>>> practically impossible to do that as the build system is ... well,
    >>>> complex" Taken to extremes, you could say that a jar file full of
    >>>> classes is buildable source, since, with the right tools, you can
    >>>> decompile the class files back to java code.
    >>>>
    >>>> 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. Because that's the only
    >>>> way an evaluator can be sure that the release has met the condition
    >>>> and the release manager hasn't accidentally left out some required
    >>>> piece of source. We wouldn't say that we know that the release
    >>>> has a
    >>>> valid checksum without checking it ourselves or that the release
    >>>> has a
    >>>> valid signature without checking it ourselves. Same goes for
    >>>> building it.
    >>>>
    >>>>
    >>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org
    >>>> >
    >>>> wrote:
    >>>>>
    >>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
    >>>>>
    >>>>>> 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.
    >>>>>
    >>>>> Actually, re-reading the above and it doesn't state a need of a
    >>>>> working
    >>>>> pom.xml or build.xml, just the source that is matching the
    >>>>> binaries. In
    >>>>> this
    >>>>> respect we don't violate this. We do not provide a buildfile,
    >>>>> but a Java
    >>>>> developer will be able to build the source regardless (e.g. by
    >>>>> writing
    >>>>> build.xml himself, or importing sources in Eclipse).
    >>>>>
    >>>>> Andrus
    >>>>>
    >>>>>
    >>>>
    >>>>
    >>>>
    >>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org
    >>>> >
    >>>> wrote:
    >>>>>
    >>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
    >>>>>
    >>>>>> 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.
    >>>>>
    >>>>> Actually, re-reading the above and it doesn't state a need of a
    >>>>> working
    >>>>> pom.xml or build.xml, just the source that is matching the
    >>>>> binaries. In
    >>>>> this
    >>>>> respect we don't violate this. We do not provide a buildfile,
    >>>>> but a Java
    >>>>> developer will be able to build the source regardless (e.g. by
    >>>>> writing
    >>>>> build.xml himself, or importing sources in Eclipse).
    >>>>>
    >>>>> Andrus
    >>>>>
    >>>>>
    >>>>
    >>>
    >>>
    >>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 19:19:12 UTC