Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] splitting cvs spells
  • Date: Sat, 7 Oct 2006 13:22:11 +0300

Hi again. I've put together a more detailed collection of arguments to
demonstrate my point. I've tried to take into account all that's been said so
far, please tell me if I've missed anything.

Unjoy! ;)


Arguments against my opinion I think are valid:

* Grimoire size.
- More spells equals a bigger grimoire. Can't get around this one. (On the
other hand, having a cvs spell for each program shouldn't be the norm. Also,
shrinking the grimoire can and should be achieved by other means, too, like
setting up the deprecated grimoire and doing general pruning.)


Arguments against my opinion I disagree with:

* "Only split if non-compatible, otherwise put cvs in main spell."
- The rationale for dual-versioned spells goes that cvs should be separated
from stable only if it's not compatible as a dependency, but this is a line
drawn in water. Cvs is volatile, and the devel version may at any time change
its behavior enough to cause compatibility issues. A spell is a static entity
when compared against a cvs repository, and unless it's declared cvs in its
entirety, it can't rely on a repository to not change its contents.


My arguments so far:

* Separated stable and cvs spells are easier to parse.
- It's much easier to parse e.g. VERSION and SOURCE_URL when they aren't
nested inside conditionals. Not long ago we had to change the SOURCE_URLs in
all sourceforge-hosted cvs spells, which would've been _much_ easier to
script had all cvs spells been separate entities. This issue is also visible
in how 'gaze versions' doesn't really work properly with dual-versioned
spells.

* Separating cvs from stable makes spells less volatile.
- First you have a spell with both stable and cvs. Then something happens -
the cvs's options change dramatically, or some other spell specifically
requires the cvs version - and you need to split them. Then some time passes,
and eventually the stable version is updated so that it again shares its
features with the cvs code. Now you're supposed to merge them again, right?
Ad infinitum... You could've just had 'em separate from start.

* Dual-versioned spells are more work.
- A dual-versioned spell effectively forces the updater of a stable version
to spend more energy and time, because leaving the cvs options untested for
new/changed stuff when updating the stable portion isn't good practice (or at
least not very polite). We should really focus on getting stable stuff to
work before anything else, and this shouldn't get slowed down because of
dual-versioned spells.

* A spell should simply work.
- Deriving from the previous point: A spell is expected to work, period. We
can't say: "It'll work unless you press that button there, then we can't
really say" - not even if the button says "cvs". But on the other hand,
because we _do_ want to provide cvs versions, and because we _can't_ vouch
for cvs's stability, we should always separate cvs from stable spells. That
way the normal spells are stable all the way, and the cvs spells are
semantically declared unstable by their very naming.


--
Juuso Alasuutari
[[ Source Mage GNU/Linux ]]

Attachment: pgpdZgDK5gk0R.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page