On Apr 20, 2013, at 7:03 AM, Michael McCandless <[email protected]> wrote: > On Sat, Apr 20, 2013 at 2:43 AM, Steve Rowe <[email protected]> wrote: >> 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). > > +1, this is a great idea. Do you want to add this? Or I can …
(Looking back over this thread, I noticed that Uwe made the same suggestion - sorry Uwe, didn't mean to steal your thunder :) I'll work on it. >> RMs can easily get this by running "svn info" from where they build the >> release. > > buildAndPushRelease runs "svnversion" to get this. Hmm but it does > not pass -c ... should it? The svn revision identifies a static sub-tree. The way Subversion works, though, for any given sub-tree, there may be many revisions that refer to this same static sub-tree - these are effectively aliases. While we *could* use 'svnversion -c' to find the first revision that identifies the static sub-tree from which a release is cut, I don't see much benefit in doing so - the svn revision that the RM happens to use can be used later to find this revision if we ever need it. In fact, I think it's a potential source of error to be referring to multiple revisions (the checked out revision and the most recent changed revision), so I'd prefer for buildAndPushRelease to stay as-is, and not pass -c to svnversion. I guess alternatively, we could ask RMs to always check out the revision of the most recent change to the release branch that the RM wants to include, in which case there would only one be one revision being used, but this seems to me to be an all-cost-no-benefit change, so here's my vote not to do that. >> About automation: Yes, things slip through the cracks. So we learn and add >> more checks. Not continuing this process is IMHO a mistake. > > I completely agree in general: we patch each crack whenever we fall in > it. This is a powerful way to improve... > > But for this particular crack (verifying that the revision of the RC > is the latest revision on the release branch) I couldn't see a simple > way to do it, w/o having smokeTester make guesses about the name of > the release branch ... such guessing/enforced convention crosses the > line of what automation should be doing imo and the filled crack could > be worse than the unfilled one. +1 Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
