Re: How to use sandboxes?

[Justin Mason <jm...@jmason.org>]

Theo Van Dinter writes:
> So I was prodding around the sandboxes bit, and noticed that mkrules doesn't
> copy "\d.+\.(?:cf|pm)$" to the rules dir...  So it seems that if I wanted some
> rules to be put in for testing, I have to name them "word.cf" or something,
> and then they get copied.  But if I wanted my own "70_testing.cf" then it
> won't be copied.
> 
> That's the general idea?
> 
> Currently I'm putting my test rules into the 70_testing.cf like we've always
> done, but I'd like to move them into my own sandbox area.  Just want to make
> sure I understand the idea about how things are supposed to be layed out (I've
> read the sandbox wiki doc and it didn't really address this issue).

Yeah, I still need to figure out this bit. ;)

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.

This implies that a sandbox area contains both "promoted" and "test"
rules, too, and the only thing differentiating them is the "publish"
directive being present for the promoted rules.  It also allows everyone
to take care of their own rules, allows the "compilation" step to do some
sanity-checking before publishing, and rename rules that would collide
with other rules.

Right now, though, only half of this is implemented -- the bit where the
core ruleset, and sandbox "publish"-tagged rules, is published.

I haven't quite fully fleshed out the rest of it -- using a sandbox
to hold "testing" rules -- but I think it'll work like this:

  - build/mkrules picks the rules that *aren't* tagged with "publish"
  - for each rule:
    - check to ensure its name starts with "T_", rename it otherwise
    - publish to 70_testing.cf

in other words the testing rules are turned into "T_" rules and
treated as T_ rules have always been treated to date.

I'll do this on monday if nobody complains ;)


BTW on a related note.  We're having all sorts of problems with the
contents of "rules", make install, etc.

Currently the sandbox rules and other files in "rulesrc" can create *new*
filenames in "rules".   I think this is becoming too complex, and it
appears that Makefile.PL can't support it.

I think if we just define a set of filenames in Makefile.PL, and then
"mkrules" is limited to only allow publishing to those filenames, we will
solve that problem -- since that way the filenames are known upfront,
and "make install", MANIFEST, "make tardist" et al can be pre-written
to use those filenames (and only those filenames).

--j.

Re: How to use sandboxes?

[Loren Wilton <lw...@earthlink.net>]

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?

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.

For testing, it should come from sandboxes, and ideally
a)    the file names would be [nn_]arbitrary_name.cf
b)    duplicate names from various sandboxes would NOT step on each other in
testing
c)    they can get tested when the owner believes they are ready for testing
d)    they can get promoted to published status when some number of
people/criteria agree

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.

        Loren