Skip to Content.
Sympa Menu

sm-sorcery - Re: [SM-Sorcery] Sorcery quality assurance

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Paul <dufflebunk AT dufflebunk.homeip.net>
  • To: sm-sorcery <sm-sorcery AT lists.ibiblio.org>
  • Subject: Re: [SM-Sorcery] Sorcery quality assurance
  • Date: Tue, 27 Jan 2004 21:52:13 -0500

I really don't want to be messing with integrating stuff into stable. I
have no idea how to do it, and it looks like it'll make things more
difficult rather than better. When I put something into devel, I expect
it to work and not break stuff. I assume that when other people commit a
fix, they know it fixes the bug and hasn't broken anything obvious.

Unless there is a checklist that must be run through before a stable p4
gets published, I don't think it'll help much. Or unit testing, but unit
testing isn't going to happen. Some test could be automated in a similar
way as prometheus... that would be quite an undertaking though.

On Tue, 2004-01-27 at 21:27, Eric Sandall wrote:
> Due to some of the problems with stable Sorcery lately, I would like to
> propose
> that the Sorcery Team implement some type of verification process for
> releasing
> a stable version. Below I will provide my suggested template, but this is
> just
> to get the ball rolling, no need to follow it exactly (and I'm being
> pedantic,
> so don't take offense at the verbosity). ;)
>
> 1. Fix one bug on your local copy of Sorcery devel
> 2. Test that one bug to the full extent that the report specifies
> 3. Submit your fix for that bug to Sorcery devel
> 4. Integrate that fix /only/ to Sorcery stable
> 5. Repeat #2 as well as testing anything which is related to the bug
> 6. Submit the fix to Sorcery stable
> 7. Release a new version of Sorcery stable if the fix is major enough (such
> as
> it breaks machines, Sorcery is not usable, etc., but things such as "xterm
> title doesn't change" are okay to leave for a bit, though they shouldn't be
> there in the first place ;)).
> 8. Announce new version
> 9. Repeat 1-9
>
> This is just a general layout, but I would like to emphasise that /testing/
> is
> important. Also, only the tested fixes should be brought into a bugfix
> release
> of Sorcery (e.g. 1.7.1 -> 1.7.2) and not the whole devel Sorcery (though I
> believe it was all fixes anyways).
>
> I'm not sure what's been going on lately, but most people are not happy when
> software labeled "stable" comes fairly broken (especially something as
> essential as the package management).
>
> We do have a "test" module for Sorcery, perhaps we should use that to
> release a
> "testing" Sorcery (no relation to test grimoire) as an interim release?
>
> Thoughts? Comments?
>
> -sandalle
--
De mortuis nihil nisi bonum.

Attachment: signature.asc
Description: This is a digitally signed message part




Archive powered by MHonArc 2.6.24.

Top of Page