Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Spell quality checking

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andraž 'ruskie' Levstik <ruskie AT codemages.net>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Spell quality checking
  • Date: Thu, 1 Oct 2009 07:30:23 +0200 (CEST)

:2009-09-30T20:36:David Kowis:

> I believe this is a good thing too, however we need to define a
> methodology for determining, preferably automatically, what "running" is.

Agreed

> with need to be automated so that we can say "Go test!" and it happens,
> and we get results. For the programmers out there, think unit tests. We
> pick functionality we want to test for spells, and we write unit tests
> for it. We may not cover it all on the first go, we may not cover it on
> the second go. But we'll cover some, and that's better than what we've
> got right now.
>

Agreed

> B and C should be part of any update, although I'm sure I'm guilty of
> not doing it all the time. I know I'm guilty of deliberately ignoring
> some of the new optional dependencies with bugzilla, because building

Well I know I've seen updates that had a lot of changes but still no
updated setup.

> I don't think this is the appropriate solution, I think the appropriate
> solution is to be able to cast a config-set. I would love to be able to
> store an option set and reuse it again later. Better yet, it'd be great
> to be able to create an option set and share it with others. "Dave's KDE
> Konfig" etc.

Erm so basically pre-defined config that you can already do just need a
bit of work to overlay it on top of the existing setup. Anyway OT in
this case. For me this is a quality thing in spells. We claim to offer
choice so spells should have all options available to them. I know some
people recommend not adding various config options because of query
spam.

> If you couldn't tell, I'm big on automating this testing process.
> Anything we can automate, even if it takes a bit more work initially,
> saves us time in the long run. And it makes it verifyable and
> repeatable. If we really want to improve the quality, we need to do
> this. Then we can easily catch regressions in versions due to dependency
> changes and other such evil things.

I'm all for automating. But how would you test everything? Like how do
you test if a browser functions as it should? And do so in an automated
manner.

> I don't think a QA file in the grimoire is the right solution. We will
> add significant levels of data to the grimoire that end users don't
> need. Unless, as part of the release process, we remove them from the
> stable grimoire. I think having a QA grimoire (or some other repository
> for the scripts) is the solution. I don't have an RFC or anything for
> how to handle the testing and the verifying yet either. I've been busy
> making something to make my perl-cpan spells (automatically even ;) ).

Since there's a few other things also generated at that time it would
probably be a low-overhead thing.

--
Andraž ruskie Levstik
Source Mage GNU/Linux Games/Xorg grimoire guru
Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/
Geek/Hacker/Tinker

Quis custodiet ipsos custodes?


Archive powered by MHonArc 2.6.24.

Top of Page