Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

I agree (mostly) with Jeremy. I will be very unhappy if grimoire
sectioning becomes (essentially) meaningless if spell sections are just
named after their maintainer. So, heres 'my' suggestion.

Many of the current sections share code with section level libraries,
kde and php-pear for example have common BUILD and/or DETAILS files.
If we go jumble up all the sections based on our latest and greatest
taxonomy, then those libraries have to move around, the eventual
result is that all section level libraries will roll downhill into
the grimoire. Theres also section level API_VERSION files for setting
BUILD_API for an entire section, by moving spells around you start
loosing that functionality and have to re-insert the BUILD_API value
into the spells. In other words, we start loosing inheritence, this is
bad and will add more work and confusion to the process.

theres two (broad) ways to look at grimoires, you either see it as
something the user accesses, or something spells and sorcery access. The
above perspective is based on that of spells and sorcery. Most of this
discussion is based on the user appearance to solve some particular
problem or another.

I think the best solution for us is to use the file system primarily
to organize into categories where it makes sense to share code between
spells. We can add keywords and maintainers on top of that and have,
then on top of that we can have tools to organize a symlinked fs tree
based on user defined taxonomy in a seperate location. So you could
organize spells based on maintainer or whatever, then still wander around
with filesystem tools.

Also, ive been fiddling with the idea of 'self-contained' spells
[0], spells with their own psuedo grimoire and section dirs built in
(which would have 'copies' of the various section/grimoire libs), this
is necessary for scribbler to properly scribble spells to arbitrary
grimoires and preserve their disposition. Since we're making a symlink
forest grimoire for user access, all the spells could be in this
scribbled format inside the symlink forest grimoires to make it easy
for guru's to work on spells in different sections.

So, in summary, the 'real' grimoire format could be organized based on
code inheritence, then we can apply keywords to the spell DETAILS and
have tools to quickly browse based on keyword, as already suggested,
or to re-organize the grimoire into seperate locations based on the
users choice of taxonomy. Since the pre-existing format is mostly
already sorted on code-inheritence we can keep it mostly the same and
still relatively obvious for new users accessing it, but for an added
level of re-arrangement the symlink forest tool can be used.

Now, respond with why that idea sucks and lets continue talking about this
for another few weeks until we eventually all get tired and do nothing,
ready? go!

-Andrew

[0] http://bugs.sourcemage.org/show_bug.cgi?id=8430

On Tue, Apr 05, 2005 at 01:03:42PM -0500, Jeremy Blosser (emrys) wrote:
> On Apr 05, Arwed von Merkatz [v.merkatz AT gmx.net] wrote:
> > The one drawback I see with this solution is that we lose the option to 
> > browse
> > the grimoire easily with the shell/filemanagers, but a fast keyword search
> > makes up for that.
> 
> A rant first, then an actual proposal for a solution...
> 
> <rant>
> As I said in IRC, I do not see this as a minor problem or an acceptable
> solution.  I cannot even count the number of these "it's no big deal to
> take away the filesystem tools and make people use our own tools"
> conversations I've seen over the years.  There are always good reasons for
> the tools approach, it offers something the filesystem approach doesn't,
> but always at the cost of breaking the most common interface everyone
> knows.  Linus has a great quote on why dropping the Unix file+standard file
> tools approach is always a bad idea but I can't find it at the moment.
> 
> Inevitably the tools approach wins because the people suggesting it are
> very familiar with their own system and don't much remember what it's like
> to be a newbie in that environment or to deal with the bar to entry.  And
> then this always does result in fewer users, because users who are already
> switching distros want to have to relearn as few things as possible, just
> for practical reasons.  The project in question either realizes this and
> backtracks or just goes on without realizing the potential it had.
> 
> A somewhat recent example of this is subversion, which started out all
> about using "the best tools", with a bdb-only backend and webdav-only
> repository access.  There were plenty of requests early on for more simple
> access, but the devs always responded that "it's easy to use bdb tools, and
> databases are fast!" and "webdav lets us do so much more stuff and
> everything will use it soon anyway!".  So they lost users, and kept losing
> users, and eventually added other backends (including fsfs) and access
> methods (including local and ssh).  And now major projects that have been
> content with CVS (svn's target audience) are finally making a move to use
> subversion instead.
> 
> A primary reason I decided to switch to sourcemage was because it didn't
> seem to be on a kick of adding all its own tools except where they were
> needed for core functionality.  This goes completely the other direction.
> </rant>
> 
> Anyway, I understand totally the goal to make it easier for maintainers to
> maintain the small group of spells they use, though I agree with others
> that this will mostly result in several people that want to maintain the
> same core spells with other spells that only have some users sitting around
> in unmaintained.  It will also result in a lot of turnover, since changing
> maintainers means moving the spell, not just updating a file entry.
> 
> But there are still a couple of ways to achieve it along with the best of
> what we have now:
> 
> 1) As already suggested, continue to sort the grimoire by a taxonomy, but
>    add a MAINTAINER back to individual spells.  The section maintainer wins
>    if the spell doesn't have one, but if the spell has one it wins.  Then
>    go a step farther and create som guru-tools that make iit easy for
>    maintainers to grab just their own spells into a work area and go from
>    there.  This is the right place for new tools, stuff that just
>    maintainers have to worry about.  This avoids the turnover problem as
>    well and is probably the right way to do it if we can figure out what
>    tools we need for the maintainers.
> 
> OR
> 
> 2) We could go ahead and sort the grimoire by maintainer, but do it like
>    this:
> 
>    jeremy_blosser/mail-daemons/
>    jeremy_blosser/mail-clients/
>    jeremy_blosser/shell-utils/
> 
>    So each maintainer has their own area, but under that area it's still
>    sorted a globally-defined way.  People who maintain a ton of spells are
>    going to want that kind of organization eventually anyway.
> 
>    Then we add an extra layer of logic to the tarball-building scripts or
>    sorcery so that when users grab grimoires or web indexes are created,
>    the maintainer part of the path gets stripped.  They still just end up
>    with mail-daemons/, shell-utils/, etc.  If we needed we could have
>    scripts stuff the maintainer path info back into each spell as a
>    MAINTAINER variable as well so userspace can tell who maintains what.
>    Regardless, the point is that the maintainer-based sectioning is *only*
>    useful to maintainers and the backends, and is directly *not* useful to
>    users, so it should only be visible to maintainers and the backend.
>    That requires some work, but we're clever people here.  Again, this is
>    the right kind of place to spend the time creating new tools.  This
>    would still have a lot of turnover, though.
> 
> Neither of these precludes adding KEYWORDS and improving gaze's search
> abilities as well.  Of course the completely messianic way of doing this
> would be to store things by something like maintainer only and then let
> each user set their own sorting taxonomy based on keywords and have sorcery
> automatically sort their local copy of the grimoires this way, but I doubt
> any of us are that insane.



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


-- 
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
|Sorcery Team Lead                         | ftp://t.armory.com/         |
--------------------------------------------------------------------------

Attachment: pgp1jIfAcl5dq.pgp
Description: PGP signature