Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

(Sorry for the double-mail for you, Remko. I'm a bit out of it this
morning it seems.)

In general, a very strong +1 (I've basically argued for the same thing
before, but you wrote it out much more clearly, and with a few added
twists).

Others are already discussing various points, so I'll only add very
specific comments.

Remko van der Vossen (wich AT yuugen.jp) wrote [11.08.31 08:03]:
<snip>
> I'd like for us to have a core grimoire, which contains the spells
> from basesystem and the spells we include on our ISO. These spells
> need to work *at all times*, we need to have these spells working
> properly to make sure that ISO generation can be maintained without
> cauldron having to fix stupid problems everywhere, they need to be
> able to concentrate on actually generating the ISO.
</snip>

Who is the "they"? Cauldron is dead.

<snip>
> I propose we reinstate the UPDATED field in DETAILS and add a CHECKED
> field as well. The UPDATED field should be updated as the spell is
> updated. The CHECKED field should be updated when the maintainer has
> performed a proper check of the spell, that is, checked the spell can
> be properly cast, preferably from both stable as well as ISO, and that
> the software works properly. If both UPDATED and CHECKED are more than
> a year ago the software will be nominted to be bumped from the
> maintained grimoire in three months. If either UPDATED or CHECKED is
> more than three years ago, the software should also be nominated to be
> bumped in three months. Of course we should automate this checking and
> bumping.
</snip>

I don't think UPDATED is needed, for two reasons. First, the information
can easily be gotten both from git itself and from inspecting the
HISTORY file. Second, I don't think it should be used as a measure of
whether a spell should be moved out of the stable/tested (see below)
branch/grimoire. What if we have perfect support for a spell that hasn't
been updated upstream for the given time period? Note that any length of
time we choose is purely arbitrary, and in theory you could always find
a spell that would violate the time period for being updated but would
still actually work perfectly well, unless of course it failed for being
CHECKED, which is my point. If CHECKED is updated regularly by having
people repeatedly check that a spell builds/installs/runs OK, then
we don't need to force version updates. The only case where enforced
pure version updates would make sense would be if there were a third
dimension for grimoire generation based on newness of spells (a
"bleeding-edge" branch/grimoire), and even then it could still be
problematic with upstreams that don't update as often.

> That leaves the grimoire of unmaintained spells, which is simply
> everything else. This gives us four grimoires, the names of which we can
> make properly magical in due time;
> 
>   1. core
>   2. tested
>   3. maintained
>   4. unmaintaied
> 

I believe that these would be analogous to what we already have as
follows (correct me if I'm wrong):

   1. core
   2. stable
   3. test
   4. unmaintained

If this is accurate, then Bor raised a good point of how we would
transition current users to the new scheme, as they would have spells
installed from "stable" and/or "test" that might not remain in the same
branch/grimoire. As the higher-order branches/grimoires would just be
add-on overlays, simply adding them would solve the problem, but we'd
need to notify the user of the need for this and/or automate the process
somehow. If they'd align in a different way, we'd need to know what that
would be before discussing whether updating would be problematic, and
then discuss how to resolve it if so.

<snip>
> Now, what needs to be done to realize all of this. Firstly we need to
> determine how we want to add grimoire dimensions to the spells. I see
> two possibilities for this, the cleaner is bash associative arrays,
> however this is a bash 4 specific feature and requires a declare
> command, e.g.:
> 
>            SPELL=kdebase
>          VERSION=4.6.5
> declare -A GRIMOIRE
>     GRIMOIRE[QA]=maintained
>  GRIMOIRE[topic]=KDE
>              ...
>          UPDATED=20110711
>          CHECKED=20110806
> 
> Alternatively we could go for something like
> 
>            SPELL=kdebase
>          VERSION=4.6.5
>      GRIMOIRE_QA=maintained
>   GRIMOIRE_topic=KDE
>              ...
>          UPDATED=20110711
>          CHECKED=20110806
> 
> which would get rid of the ugly declare statement, but would cause us to
> need nasty string concats in eval statements in the scripting.
</snip>

Why complicate it more than it needs to be? None of the other variables
are namespaced except for those which really need to be (like
SOURCE_URL, where a single source can have multiple urls). QA will not
have multiple levels (and even if it did they could be simply listed as
a space-separated string, especially since we control what/how the
levels are named). Certainly neither of these will not need multiple
"GRIMOIRE"s, since whatever "grimoires" it belongs to are actually
specified via "topic" (would you have a GRIMOIRE[spell] or
GRIMOIRE[version]?). Thus, simply doing the following solves the whole
problem:

            SPELL=kdebase
          VERSION=4.6.5
               QA=maintained
            TOPIC=KDE
              ...
          UPDATED=20110711
          CHECKED=20110806
 
 -- or --
 
            SPELL=kdebase
          VERSION=4.6.5
               QA=maintained
            TOPIC="KDE KDE-4.7 KDE-foo bar"
              ...
          UPDATED=20110711
          CHECKED=20110806

Also, why suddenly call it "topic" when up to this point you've been
calling it "branch" or "grimoire"? I understand that the name is
arbitrary, we can change it to whatever we want, and this was just an
example, but having the example be inconsistent made reading the email
more difficult/confusing.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org
Remko van der Vossen (wich AT yuugen.jp) wrote [11.08.31 08:03]:

Attachment: pgpgqdZut7Rbe.pgp
Description: PGP signature