Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] feature creep. WAS: splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Mon, 9 Oct 2006 08:12:54 -0700

On Mon, Oct 09, 2006 at 03:23:48PM +0300, Juuso Alasuutari wrote:
>
> Luckily, there is also progress being made in the right direction. When the
> smgl-filesystem (castfs) work is finished and we finally have a proper way
> to
> do staged installs, we can wave good-bye to $INSTALL_ROOT and $TRACK_ROOT
> in
> spells. I hope the future will bring more such positive changes.

Actually TRACK_ROOT remains, as its only a build configuration parameter
and obviously sorcery has little power over that.

>
> This would make casting somewhat slower, but personally I'd happily pay the
> price for not having to do so many full-house cleanses and hunting for
> missing check_self triggers.
>

Theres an issue with this, which is that cast needs to know everything
its going to build ahead of time because figuring it out later implies
user interaction.

- foo rebuilds
- check_self on bar (dependee of foo)
- check_self fails, have to rebuild bar
- to rebuild bar sorcery has to do depends resolution on it
- to do dependency resolution cast has to run PREPARE/CONFIGURE/DEPENDS
on the spell
- but its too late, we're in the middle of compilation and can't do
something that might prompt the user :-(

It might be possible to use the tablet'd spell, where all the answers
are known. But then we have to support building from the tablet (which
is an eventual goal if enough things need it).

A counterpoint to using the tablet might be "but the old version of
bar in the tablet might not work with the latest foo" in which case a
cast_self up_trigger should exist anyway.

---

Of course doesnt this seem kind of silly talking about a new feature request
immediatly after someone mentions feature creep. Just a little?

One has to wonder how often this sort of thing actually happens on a
properly updated box.

Personally I favor automation at "build-time" (working on the code
before distribution to users machines) to extra work at "run-time"
on the user's box.

Also, I think theres far too many other unresolved issues discovered by
prometheus that need attention. Our grimoire QA process could stand to
be *much* more active. We can work on that without effecting feature
creep at all, and deliver a better product to the end users.

-Andrew


--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page