Firstly, I'm not heated up, so I can not cool down, without going into
hypothermia.
Secondly, I never said that *you* were doing that, just that it was being
done.
Thirdly, I'm super glad that you agree SCM and bundles should be compared.
Fourthly, let's get on with the discussion about what it takes to do that.
No, wait. Sebb and Jason already have that nailed the **** down.
Good men, those two.
Fred.
On Thu, Aug 15, 2013 at 11:21 PM, Dennis Lundberg <denn...@apache.org>wrote:
> Hi Fred,
>
> On Thu, Aug 15, 2013 at 10:48 PM, Fred Cooke <fred.co...@gmail.com> 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 <denn...@apache.org
> > >wrote:
> >
> > > 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
> > >
> >
> > --
> > Dennis Lundberg
> >
>
