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
>
