First, I still agree that we need a way to generate a rule update using the latest svn versions of rules for *emergency updates*.
On 16/03/2010 8:52 AM, Justin Mason wrote: > On Tue, Mar 16, 2010 at 00:36, Daryl C. W. O'Shea >> Just grab a recent nightly update, rename it, and use that. The safest >> one to use would be a weekly one right after the net enabled mass-check >> results (Saturday night's update around 10:30 PM ET -- Sunday, 2:30 AM >> UTC). Although, any update should be safe, the differences should be >> minor. 922507 is the most recent. > > OK, I'll do that for 3.3.1. > > For long term use, though, we'll need some way to cut a rules tarball > using what's in SVN right now, rather than what was there on the previous > night. in my opinion it's unsafe to risk differences between what's > live in svn and what we're releasing, particularly if changes went in > during that window. Sorry, I don't follow. If the rule tarball lints on the proposed code release version, what sort of risks might we encounter that we wouldn't also encounter doing our day-to-day rule updates after the code release happens. I'm concerned about using generated scores from the day before on current rules when there are changes to rules since, well, the rules could hit different things after the change. If the active.list changes in this time period we'll also have the issue of extra or missing rule scores. > We can, of course, use the scores that were generated then (but with > changes since then included too). I think the safest, most paranoid, way is to schedule the code tarball cutting around our rule update schedule. Cut the tarball using the nightly mass-check code revision, then wait for the update tarball to be generated. This probably isn't necessary though, as long as the latest update tarball lints OK on a (any) proposed release. If there are other necessary sanity checks we should be doing them for all rule updates, not just for the release tarballs. Daryl
