On Thu, Aug 15, 2013 at 10:24 PM, Fred Cooke <fred.co...@gmail.com> 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 <denn...@apache.org>
> wrote:
>
> > On Thu, Aug 15, 2013 at 9:27 PM, sebb <seb...@gmail.com> wrote:
> >
> > > On 15 August 2013 14:16, Jason van Zyl <ja...@tesla.io> 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 <chrisgw...@gmail.com>
> > wrote:
> > > >
> > > >>
> > > >>
> > > >> Sent from my iPhone
> > > >>
> > > >> On 15/08/2013, at 10:05 PM, sebb <seb...@gmail.com> wrote:
> > > >>
> > > >>> On 15 August 2013 10:08, Chris Graham <chrisgw...@gmail.com>
> 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-unsubscr...@maven.apache.org
> > > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > > Dennis Lundberg <dev-h...@maven.apache.org>
> > >
> >
>
> --
> Dennis Lundberg
