On Apr 19, 2013, at 6:44 PM, Michael McCandless <luc...@mikemccandless.com> 
wrote:
> On Fri, Apr 19, 2013 at 6:36 PM, Chris Hostetter
> <hossman_luc...@fucit.org> wrote:
>> 
>> : OK I think a WARNING in smokeTester makes sense ...
>> :
>> : But as Hoss said ... figuring out the release branch from smokeTester
>> : ... isn't easy.  Hmm.
>> 
>> At a certain point, too much automation is "too much".  I already think
>> the snoke tester is too complicated -- what tests the tester?
>> 
>> It's great to automate any sanity checks thta can be reliably automated,
>> but we have to remeber that each of us has to take resonsibiliity for hte
>> fact that we are *personally* voting for hte release, and the smoke test
>> scripts are just tools to help save us time doing verifying trivial
>> things.  We still need to be concious of what exactly is in the release,
>> and wether it works, and wether the smoke testers "SUCCESS" was really a
>> false positive, etc...
>> 
>> "smokeTestRelease.py don't vote to release; People vote to release."
> 
> Yeah I agree ... I think we should leave this out of the snoke tester.
> 
> buildAndPushRelease already svn ups for you …

But not every RM will use that.

I think another smoke test might be useful: compare the claimed svn revision 
against the revision in the manifest of each archive to be released, e.g. from 
the RC2 lucene-core-4.3.0.jar:

Implementation-Version: 4.3.0 1470054 - simonw - 2013-04-19 23:43:33

We would have to supply the revision on the cmdline to the smoke tester, for 
the case when the revision is not included in the base URL, and the RM would 
have to supply this info in the VOTE thread.  Supplying an RC's source is a 
good idea anyway: "here's an RC, it's built from svn rXXXXXXX" (no need to 
supply rel branch since this is established convention).  RMs can easily get 
this by running "svn info" from where they build the release.

About automation: Yes, things slip through the cracks.  So we learn and add 
more checks.  Not continuing this process is IMHO a mistake.

Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to