Theo Van Dinter writes: > On Wed, Feb 22, 2006 at 09:59:44AM +0000, Justin Mason wrote: > > Theo Van Dinter writes: > > > I'd like to see us start publishing rule updates for 3.1 sometime here > > > in the near future. This got me to wondering what our policy should be > > > about it, specifically 3.1 code is in R-T-C so should the rules be also? > > > Based on history, I don't think we'll be able to get reviews fast enough. > > > > I think we need to fix the review problems in general, otherwise > > we'll never get a 3.1.1 out *anyway*. :( > > Yeah, reviews have generally been slow to happen in the past, though the past > couple of days has been pretty good. I moved a bunch of stuff out of the > 3.1.1 queue, and we've gotten through a number of tickets/patches recently. > There's still 14 tickets in the queue, though iirc, a bunch of them are > inter-related. > > As for the rule updates... Here's my thought. I propose we have the > rule updates be C-T-R to start. If that doesn't work out, we can change > to R-T-C easily. If no one vetos this proposal by 00:00 GMT on 2/28, > we'll take it as the initial policy for the rulesrc area.
+1. There's no way Dan will notice this, since I don't think he reads the dev list anymore ;) > PS: I was reminded of a question... The rulesrc stuff, automatic publishing, > etc, all happens for the current development version. What happens when we > release 3.2 and go onto 3.3? Do we want to keep going with automatic updates, > or shift to the manual method? Can the code handle doing automatic updates > for multiple versions? Since it uses results for the previous nightly run, > and that run will only be for the dev version, is it possible to do > auto-updates for released versions? yes, this is a complicated situation ;) "rulesrc" is version-independent. Therefore we can assume that freqs for 3.2.x for rulesrc rules are valid for 3.3.x too, and then the backend scripts can use those freqs when building an active.list for that version. in other words the run_nightly and run_part2 scripts will be duplicated for each version. It should work, I think; a few minor script changes may be required but nothing serious. I don't think it'd scale to require nightly mass-checks for more than one version of the tree. --j.
