Return-Path: Delivered-To: apmail-cayenne-dev-archive@www.apache.org Received: (qmail 412 invoked from network); 16 Aug 2010 19:19:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Aug 2010 19:19:10 -0000 Received: (qmail 17451 invoked by uid 500); 16 Aug 2010 19:19:10 -0000 Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org Received: (qmail 17432 invoked by uid 500); 16 Aug 2010 19:19:10 -0000 Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cayenne.apache.org Delivered-To: mailing list dev@cayenne.apache.org Received: (qmail 17424 invoked by uid 99); 16 Aug 2010 19:19:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Aug 2010 19:19:10 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.78.103.231] (HELO vorsha.objectstyle.org) (208.78.103.231) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 16 Aug 2010 19:19:05 +0000 Received: (qmail 27452 invoked from network); 16 Aug 2010 19:18:43 -0000 Received: from unknown (HELO ?IPv6:::1?) (127.0.0.1) by localhost with SMTP; 16 Aug 2010 19:18:43 -0000 Message-Id: From: Andrus Adamchik To: dev@cayenne.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [VOTE] release 3.0.1 Date: Mon, 16 Aug 2010 22:18:41 +0300 References: <533042FC-AD2D-4C7C-BCF9-F96B075F33B7@objectstyle.org> <09F01896-09E5-4EFB-82D6-DC2BA2D45EEE@objectstyle.org> <71155D38-6F08-452C-8B47-6246CC46541C@objectstyle.org> <076AB47D-3F26-4C7B-8901-2AAFB040E084@objectstyle.org> X-Mailer: Apple Mail (2.936) 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 > 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 >>> > >>>> 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 >>> > >>>> 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 >>>>> >>>>> >>>> >>> >>> >> >> >