Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B169010F02 for ; Thu, 15 Aug 2013 21:22:55 +0000 (UTC) Received: (qmail 71310 invoked by uid 500); 15 Aug 2013 21:22:26 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 71231 invoked by uid 500); 15 Aug 2013 21:22:16 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 71039 invoked by uid 99); 15 Aug 2013 21:22:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 21:22:11 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dennisl.apache@gmail.com designates 209.85.192.172 as permitted sender) Received: from [209.85.192.172] (HELO mail-pd0-f172.google.com) (209.85.192.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 21:21:57 +0000 Received: by mail-pd0-f172.google.com with SMTP id z10so1285682pdj.31 for ; Thu, 15 Aug 2013 14:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=28aVNJNo2jcIrGm+YWiDC8/Vbsdy+DZXRUkrkdN8rp0=; b=vVnz7cKMXemv4xOcqewKpwhjcfnFykcrOCBwnthhsrirv1/OwUgCdx1r6x4Wg1GadS +/1gxUrJ4uzu+bGNEhdhAGF9aqeGcP/LbZORnWKWcqfGZJevHdz0pfIOr+/k9V9m+Tt2 UGCOkm90M6NpiQ1+P0wObaUefQ31vaHk17FqTY/gCwQmQaw9TZZynIReWTK71+8HE7Pw gzp/ZfkWgQPKJ49vls5RyoC8R/mqbUKJIRGUfZeTZ7rd7MC1K84s/ZXkgeF1u2cT1bAk 260dYJUAWdPVmbdeeAbZTFBNZ3LSas3BThIuq4NeN+OTLw0lmvYm6fv9iFr0rEqdjNRw i2/g== MIME-Version: 1.0 X-Received: by 10.66.25.70 with SMTP id a6mr17461942pag.68.1376601695921; Thu, 15 Aug 2013 14:21:35 -0700 (PDT) Sender: dennisl.apache@gmail.com Received: by 10.70.77.230 with HTTP; Thu, 15 Aug 2013 14:21:35 -0700 (PDT) In-Reply-To: References: <5D944B21-31EF-435E-B3FE-41D5035B6E5A@gmail.com> <2D24A6F4-D904-483B-9643-76FE2A81690C@tesla.io> Date: Thu, 15 Aug 2013 23:21:35 +0200 X-Google-Sender-Auth: 4nnuwV48stGmSOqGiZVuUCmXqc0 Message-ID: Subject: Re: [VOTE] Release Apache Maven Model Converter version 2.3 From: Dennis Lundberg To: Maven Developers List Content-Type: multipart/alternative; boundary=bcaec529928315360504e4030fb9 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec529928315360504e4030fb9 Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke wrote: > Actually, I missed exactly nothing!!! > > Your process could be flawed. Human errors do happen. > The process is not flawed, but people make mistakes. > The entire point of any review is to not trust process or people, and to > check everything. You're effectively advocating not doing that, and this > *IS* unhealthy. > Why on earth would you think that I advocate not checking everything? I have just agreed that Sebb has a point in that we *should* check the source bundle against the SCM. Nobody is disputing that. That is not what this disussion is about. > I know that with your process on a primary vote the tag should exist once, > and only once. Someone could screw up. It happens. Your promise of "we > never make mistakes" holds no water with me. > I have never promised such a thing. People make mistakes. That is why we have review. To catch those errors. > > The most disturbing part of all is Sebb being persecuted and attacked and > labeled a *troll* of all things for advocating due diligence. :-/ > I am not attacking anyone and have not called anyone a troll. Just trying to understand the problem at hand. May I suggest that you cool down a bit. > > Fred. > > On Thu, Aug 15, 2013 at 10:33 PM, Dennis Lundberg >wrote: > > > On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke > wrote: > > > > > > > > > > Right so far? > > > > > > > > > > No, you're not. Step three, in SVN, requires reviewing history to > confirm > > > no changes were made to that URL *ever*. In Git, step 3 involves > knowing > > > the hash, as spurious tags have already been known to circulate. > > > > > > > I don't know Git that well yet, so I won't go into a discussion about > that. > > > > As for Subversion, you missed a few bits of what I wrote. I was talking > > about a release that is *not* respun. With our process that means that > > there has never been such a tag before and, if the vote passes, there > will > > never be another one again *ever*. If someone doesn't follow our process > > that will become apparent during the review. > > > > > > > Even if all of the details were in the POM, the question still remains, > > is > > > this the revision you *intended* to release? Or not? ONLY you can > answer > > > this. > > > > > > > With our process - yes it is. *always* > > > > > > > > > > Fred. > > > > > > On Thu, Aug 15, 2013 at 9:57 PM, Dennis Lundberg > > > wrote: > > > > > > > On Thu, Aug 15, 2013 at 9:27 PM, sebb wrote: > > > > > > > > > On 15 August 2013 14:16, Jason van Zyl wrote: > > > > > > What Sebb is doing is perfectly reasonable. > > > > > > > > > > > > > I agree. Checking that the source bundle is correct is good release > > > review > > > > practice. > > > > > > > > Thank you! > > > > > > > > > > > He's trying to assert that everything in the source ball actually > > > comes > > > > > from source control and that no errant files have made their way > into > > > the > > > > > distribution. Right now we cannot assert that the assembly plugin > has > > > not > > > > > wandered outside the checkout and pulled something else in, or that > > > > someone > > > > > didn't accidentally put something else in the distribution. I think > > > this > > > > > unlikely but we can't assert otherwise right now which I believe is > > > > Sebb's > > > > > point. > > > > > > > > > > It *has* already happened several times that I am aware of. > > > > > > > > > > The last few releases of the War plugin (various RMs & voters) > > > > > included at least one spurious file. > > > > > So it was not just a one-off packaging - and review - failure. > > > > > [See separate thread(s) for all the details; they are not germane > > > here.] > > > > > > > > > > The message is that mistakes happen even in automated processes. > > > > > Which is why independent comparison of input and output is > valuable. > > > > > > > > > > > If we can embed the revision from which the assembly was made in > > the > > > > > assembly itself (and maybe the build number plugin is doing this > > > > already), > > > > > then a tool can be made to unpack the assembly, checkout the > revision > > > and > > > > > assert that everything in the source distribution comes from source > > > > control. > > > > > > > > > > > > If we can also assert that as part of each build all the license > > > files > > > > > are intact and headers are in place then I believe we're done with > > > > > provenance. > > > > > > Licenses are present, all files have valid license headers, all > > files > > > > > present in the source distribution come from source control, all > > > > > contributions to source control are from bonafide CLA carrying > Apache > > > > > committers because you don't get access to commit until the CLA is > on > > > > file. > > > > > > > > > > > > Sebb, reasonably accurate? > > > > > > > > > > Yes. > > > > > > > > > > One other point I made already is that I think the vote e-mail > needs > > > > > to be transparent to all, not just those on the PMC. > > > > > Links to the output from the release process are obviously already > in > > > > > the mail; what is missing is the input to the process, e.g.. SCM > > > > > coords. > > > > > Yes, it may be possible to dig out the details from the archive, > but > > > > > that's not trivial. > > > > > > > > > > > > > I disagree. > > > > > > > > If we focus first on a "normal" release, one that succeeds on the > first > > > > attempt, without a respin or deleting of tags. > > > > To check provenance you would do this: > > > > > > > > 1. download the source bundle > > > > 2. unpack the source bundle > > > > 3. checkout the corresponding source code from the SCM > > > > 4. compare the two trees > > > > > > > > Right so far? > > > > > > > > What you want, if I understand you correctly, is to have the SCM URL > in > > > the > > > > vote email. So that you can give that to your SCM client in step 3. > > > > > > > > With the process we use here at the Maven project, the SCM URL is in > > the > > > > pom.xml file that sits in the root directory of the unpacked source > > > bundle. > > > > All you need to do is open the file and copy the URL from there. I > > still > > > > fail to see how that is so much harder than to copy the URL from an > > > email. > > > > > > > > That is if you don't know the conventions that we use, by way of the > > > > Release Plugin. The tag will always be in the format > > > > ${project.artifactId}-${project.version} > > > > > > > > Now, for a respun release thing are trickier. Here it might be a good > > > idea > > > > to include the revision number or hash, or whatever is unique in the > > SCM > > > > being used. Even though the code under review will always be under > the > > > > latest tag in the above format (at least for Subversion). > > > > > > > > > > > > > Publishing the SCM coordinates in the mail is trivial to do, and > > shows > > > > > that the input is an important part of the review process. > > > > > Having the information in the mail thread is also useful for the > > > > archives. > > > > > > > > > > > > > As others have said before, we aim to automate the release process as > > > much > > > > as possible. Therefor even a seemingly minor addition will be > > questioned, > > > > as you have noticed, before it is included in our process. > > > > > > > > Can you explain why the information is useful for the archives? I've > > seen > > > > you mentioned that before. Isn't that moot once the release is > > approved? > > > > The tag will be in Subversion for the forseable future and noone will > > > touch > > > > it. What am I missing? > > > > > > > > > > > > > > > > > > > On Aug 15, 2013, at 9:01 AM, Chris Graham > > > > wrote: > > > > > > > > > > > >> > > > > > >> > > > > > >> Sent from my iPhone > > > > > >> > > > > > >> On 15/08/2013, at 10:05 PM, sebb wrote: > > > > > >> > > > > > >>> On 15 August 2013 10:08, Chris Graham > > > wrote: > > > > > >>>> What sebb does not appear to have understood or accepted, as > > > Stephen > > > > > has > > > > > >>>> endlessly pointed out, is that we vote on the source bundle, > > not a > > > > scm > > > > > >>>> revision, and that, strictly speaking a SCM is not even > required > > > > > (however > > > > > >>>> sensible it is to use one). > > > > > >>>> > > > > > >>>> He wants a tree and a revision so that we can compare between > > > > > releases, > > > > > >>>> where what he should be doing, strictly speaking, is comparing > > > > source > > > > > tar > > > > > >>>> balls, as that is what we really are voting on. > > > > > >>> > > > > > >>> I agree that what is released (and voted on) are the source > > > tarballs. > > > > > >>> And any such tarballs should be identical (barring possibly > > > different > > > > > >>> EOL settings for text files). > > > > > >>> > > > > > >>> However, that is only one of the checks that need to be made. > > > > > >>> > > > > > >>> The PMC also needs to ensure that the files are being released > > > under > > > > > >>> the correct license. > > > > > >> > > > > > >> Are not the licenses in the source that is in the source > tarball? > > > > > >> > > > > > >> If so, can not the rat plugin or similar be used to check the > > > > > compliance? > > > > > >> > > > > > >>> I contend that the only practical way to check the licences is > to > > > > > >>> compare the source tarball(s) with the files in SCM. > > > > > >>> > > > > > >>> [The files should only be added to SCM if the license is OK, so > > the > > > > > >>> SCM tag acts as a database of validated source files.] > > > > > >>> > > > > > >>> The SVN revision / Git hash are needed to ensure uniqueness. > > > > > >>> > > > > > >>> > > > --------------------------------------------------------------------- > > > > > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > > > > >>> For additional commands, e-mail: dev-help@maven.apache.org > > > > > >>> > > > > > >> > > > > > >> > > > --------------------------------------------------------------------- > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org > > > > > >> > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jason > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > Jason van Zyl > > > > > > Founder, Apache Maven > > > > > > http://twitter.com/jvanzyl > > > > > > --------------------------------------------------------- > > > > > > > > > > > > There's no sense in being precise when you don't even know what > > > you're > > > > > talking about. > > > > > > > > > > > > -- John von Neumann > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > > > > > For additional commands, e-mail: dev-help@maven.apache.org > > > > > > > > > > -- > > > > > Dennis Lundberg > > > > > > > > > > > > > > > -- > > > Dennis Lundberg > > > > -- > Dennis Lundberg > --bcaec529928315360504e4030fb9--