On Wed, Mar 17, 2010 at 00:14, Daryl C. W. O'Shea <[email protected]> wrote: > 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.
Here's the scenario. Imagine that we have a tree that's nearing release, but which has a broken rule (cough URIBL_DBL cough ;). we've manually concocted scores for it, so the GA output is not relevant for that rule. We fix it, and within hours want to generate a new release tarball. If we don't have a way to push current SVN as the rules package, then we have to wait until the next day (possibly longer?) for the rescored sa-update package which includes the fixed rule, AFAICT. does that make sense? -- --j.
