Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Thomas Orgis (thomas-forum AT orgis.org) wrote [11.05.17 15:55]:
> > I agree on splitting grimoire, though it is practically difficult to
> > define which spells are `core' spells, and the split process may not be
> > smooth. It does lower the burden of testing
> 
> It raises the burden of hacking the grimoires ... all those depends on 
> differing grimoires. And when a spell moves grimoires (since there are 
> always reasons to put it here or there), you have to carefully make sure 
> that all spells depending on it get the new location right. And mind: Since 
> our spell scripts are indeed fully-capable turing-complete programs (as I 
> had to discuss with Andrew in length;-), you cannot just parse stuff.

This depends largely on how restrictive the definition of "core" is from
the beginning. If "core" is defined to be only that which is in
basesystem, this will change very infrequently indeed.

> Of course, we can introduce a system that keeps track of spells' location 
> in differing grimoires, shipping indices of the other split grimoires with 
> each one ... but it does add complexity, doesn't it?

Why not just keep simple text lists, but actually make sure they are
up-to-date? You can set a policy that the corresponding lists must be
updated every time a grimoire move happens (like adding to ChangeLog
every time a new spell is committed, etc.). It works for our other
operations, so I don't think the level of complexity you are envisioning
is required (though would certainly be a possible implementation).

Also, if the split grimoires are properly stacked, you'd never get a
spell in one grimoire which would rely on a spell in a sister level
grimoire. They would only rely on spells in daughter levels, and we
could set it up such that having a parent level grimoire will
automatically require (pull in if not already on the system) a daughter
level grimoire.

> Why not use keywords to group spells and classify them based on that? You 
> can generate lists, nice web pages collecting the testing status ... 
> without splitting anything. Btw: Why, really, is the games grimoire 
> separate? I understand z-rejected, and I understand that it's a cool (but 
> not unique) feature to have a grimoire stack to work with, including 
> personal grimoires in there, but the distro doesn't need to split up its 
> offerings into many grimoires. More interesting would be rsync updating of 
> grimoires. Even the few MB of grimoire tarball can be big.

And how would this be any different than having actual separate
grimoires for the problem of complexity you mentioned above? Doing it
via keywords instead would still require updating the keywords (instead
of the grimoire lists) every time a spell got moved. We also have the
additional problem that people agree far less on keywords than they do
on the grimoires themselves or on the section names (which are known to
be highly arbitrary).

There are lots of possible ways to implement split grimoires. I feel
that a lot of people are getting hung up in the implementation, when
there hasn't even been a discussion of a planned implementation. Whether
we go with split grimoires or not, let's focus on the actual potential
pros and cons both of split grimoires and our current grimoire setup,
then after that we can propose implementations and pitfalls for each
such proposal.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpsguMvcdbZ9.pgp
Description: PGP signature