-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Loren Wilton writes:
>Some random comments:
>
>> So the idea is that the source code for all rules (apart from the "legacy"
>> core and lang sets) remains in the sandbox dirs; in other words, there's
>> no need to cut and paste and move around rules when they're "promoted"
>> from testing status, to live core status.
>
>I'm not positive this is a good idea. Someone 'owning' a rule while it is
>in development is one thing. Someone owning a rule that is publishable is
>quite something else. What if 'someone' gets hit by a car or goes to work
>for MS and stops maintaining 'their' rules?
>
>What if (and this is very probable) someone *else* wants to modify a
>published rule to improve it, rename it for consistancy, or delete it
>because it is no longer useful? Or any of a number of reasons for
>collaborative software development rather than private contributions to a
>common cause?
doh. you're quite right, of course -- this is also the reason why the ASF
has guidelines against source files containing "this code written by..."
authorship notes.
We're going to have to revisit that.
I think it seems very likely that we will still wind up having to cut and
paste, and move around, rules from personal sandboxes into other
locations.
Hmm... there's no need for the "sandbox name" to be a person's name; it
can also be e.g. for classes of rules, I think. In that case, the
sandbox dir would become a place for both
- user sandboxes ("jm", "felicity" etc.)
- rule-type sandboxes
I'm not sure if that makes sense though :(
Maybe we should just reconsider the role of "core". *Currently*, it
is considered the place where the old legacy ruleset lives, and
it's not anticipated that new rules would go in there.
We instead could consider it a place where rules can be published to,
once they're considered publishable (by the sandbox criteria);
when a rule is publishable, it's cut and pasted into a file in that
dir.
Comments? (Daniel especially, since I think this is closer to your
original sandbox concept.)
>I think in my ideal world, there would be some number of 'published rules
>files' with known names (perhaps that reflect the contents as SARE does),
>and published rules get directed to one of these files. Or a new file gets
>created for some new rules, and possibly some old rulles get moved into it
>from previous files, if that gives a better organization a month down the
>line.
>
>That should make make happy, since things would seldom change, and the rules
>could be expected to be valid and stable.
Agreed. +1
>For testing, it should come from sandboxes, and ideally
>a) the file names would be [nn_]arbitrary_name.cf
+1
>b) duplicate names from various sandboxes would NOT step on each other in
>testing
duplicate filenames, or rule names? the latter is already implemented,
but the former, not yet (they wind up combined into one file anyway
during testing).
>c) they can get tested when the owner believes they are ready for testing
hmm. right now, if it's:
- checked in to SVN
- in a sandbox dir
- named "NN_foo.cf"
- not commented
it will be tested. this can be changed, however, but I'm not
entirely convinced it'd need to be...
>d) they can get promoted to published status when some number of
>people/criteria agree
+1
>If "arbitrary name.cf" is too hard fixed names could be used for testing.
>But there is a lot of advantage to arbitrary and disposable names here.
yep, agreed.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS
iD4DBQFDVX4fMJF5cimLx9ARArY/AJYxGOC5iN05vFEf+B7FpBeRIGRLAKCMXEU2
dsSZTckVs//HxGGu2Y62Pw==
=NXOY
-----END PGP SIGNATURE-----
