Skip to Content.
Sympa Menu

sm-grimoire - Re: [SM-Grimoire] prolifering *-cvs spells

sm-grimoire AT lists.ibiblio.org

Subject: Discussion of Spells and Grimoire items

List archive

Chronological Thread  
  • From: "Ricardo Izquierdo" <odracir_redwolf AT linuxmail.org>
  • To: "SourceMage GNU/Linux Grimoire" <sm-grimoire AT lists.ibiblio.org>
  • Subject: Re: [SM-Grimoire] prolifering *-cvs spells
  • Date: Tue, 09 Dec 2003 23:53:59 +0800


----- Original Message -----
From: Ladislav Hagara <hgr AT vabo.cz>
Date: Tue, 09 Dec 2003 15:15:32 +0100
To:
Subject: Re: [SM-Grimoire] prolifering *-cvs spells

> > Also will reduce the four grimoires of the
> > CODEX in only TWO (including z-rejected spells).
>
> Do you think devel/test version of software or devel/test version of
> grimoire?
> It is a big difference.
> I think devel version of software so we will always need devel/test
> grimoire.

I know that the devel/test version of software is very important, and
always is going to be there, and is the reason for the devel/test
grimoires,
I know that and is clear to me. But what about CVS, also is a "devel
version"
of software. Maybe another solution, using composite spells, is this one:
A CVS, TEST, STABLE for current spells. I think every prroject has a CVS.
And another Devel/Test for new spell submissions, but this will involve
more work
than in the first way.

I like to keep my idea clear.
- CVS (devel versions of current spells)
- Devel (new spell submissions)
- Test (the betas or rc versions of current spells and new submissions
that pass the devel scripting)
- Bin (stable binaries of all the collection of spells) "I thought Duane's
idea
with binaries is for the stable version of the spell"

The devel/test grimoires are in and never had the intention to take them ok
is to risky, maybe only the basic concept had changed.

> > Duane's idea is excelent.
> > +-DETAILS
> > +-DEPENDS
> > +-BUILD
> > +-cvs
> > +-DETAILS
> > +-BUILD
> > +-DEPENDS
> > +-devel
> > +-DETAILS
> > +-BUILD
> > +-DEPENDS
> > +-test
> > +-DETAILS
> > +-BUILD
> > +-DEPENDS
> > +-bin or stable
> > +-DETAILS
> > +-DEPENDS
> > +-BUILD
>
> bin or stable ?
>
> > Alternatively, the top-level files (BUILD,DEPENDS,DETAILS)
> > could be in a "default" subdirectory.
>
> DETAILS in subdirectory could contain only changes, for example VERSION
> nad MD5.
>
> > Also, working with composite spells. Not only will reduce the
> > grimoires in the CODEX, allowing a user (mage) to cast the
> > preffered version of the spell.
>
> A lot of work and only a few of developers. :-((
> We can go furthermore.
> Subdirectories could be named by version: 1.2.3, 1.3.4, 1.9.2 (for
> example GnuPG has three branches) and "stable" could be only a link to
> 1.2.3.
> DETAILS need not contain "SPELL", it is name of main directory.
> We can more strictly define syntax of files to the future (XML).
> ...
Yes and taking your example with GnuPG, casting GnuPG will load
version 1.2.3 (default because is the stable), casting GnuPG.test
will load version 1.3.4 (beta test) and casting GnuPG.cvs will
load version 1.9.2 (devel or cvs). As you see there's no GnuPG.devel
casting, because this spell has been aproveed. But now think in a project
that is actually out of SMGL grimoires, submiting it will start in:
new_spell_name.devel (because the spell is in devel scripting) and in this
way further for cvs, test, and bin or stable.
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze




Archive powered by MHonArc 2.6.24.

Top of Page