Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] detailed QA stable grimoire and ISO proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] detailed QA stable grimoire and ISO proposal
  • Date: Tue, 3 May 2005 11:04:12 +0200

On Mon, May 02, 2005 at 06:51:15PM -0700, Seth Alan Woolley wrote:
> === stable grimoire updating process ===
>
> We have three main grimoires, devel, test, and stable:
>
> * devel contains all spells plus works-in-progress, identified by a
> WIP file in them.
>
> * test contains all spells that should work but haven't had gauranteed
> testing. The guru's intent is that, yes, this spell, to the best of
> my knowledge, will work as well as the previous versions. If not,
> it goes in devel with a WIP.
>
> * stable should have been well-tested.
>
> For our purposes, those are our axiomatic definitions of each grimoire.
> To resolve debates about what should be in whatever grimoire, those are
> our definitions. I have final say, of course, besides GL and PL, who
> out-rank me in this matter.
>
> To get between devel and test grimoire, we have gurus, each guru is
> responsible for their own decisions here. Final call goes to the
> grimoire team lead (I have no place here) if there is any debate.
>
> To get between test and stable grimoire, immediately after each stable
> release, the test grimoire shall be immediately forked off into a
> "stable-rc" grimoire. RC means "Release Candidate". Prometheus and
> other testers should be testing stable-rc grimoire to make sure one can
> update from stable to stable-rc safely and relatively painlessly. What
> I mean about "painlessly" follows:

Sounds good with the addition of the "integrate to stable" flag for
bugzilla.

>
> * Version updates that break apis shouldn't do too much damage here, but
> there's only so much we can do about that. This should be documented.
>
> * Any known issues about updating should be documented prior to the
> stable release and packages as "release notes".

How and where should gurus put that information?

> * All bugs that exist in stable-rc grimoire but not stable grimoire
> should be fixed before release. If they show up afterwards, we must
> either wait until the next release to fix that or if it is of a high
> enough priority, they should be integrated into stable.
>
> * Disputes about what goes into stable are decided by any person I
> delegate, myself, GL, and PL, in that order.
>
> If that's good enough, I'd like comments and volunteers for people to
> run on prometheus on stable-rc grimoire when I've fixed it up a bit.
>
> === stable grimoire versioning ===
>
> To better track issues, the stable grimoire should have versions. They
> will be done like so:
>
> There will be three parts to the stable grimoire version:
>
> * MAJOR VERSION: This shall be "0" at first, and changed only for
> major ISO releases.
>
> * MINOR VERSION: This shall be incremented, starting at "0", for each
> stable release between ISO releases.
>
> * REVISION: This shall be incremented whenever security updates or
> major bugfixes are integrated into stable grimoire between QA declares
> the release official. It starts at zero.
>
> Each version number shall reset all inferior version numbers when they
> are incremented.
>
> We will start at 0.0.0 stable release (I know, cool). When a security
> update is applied, it shall be 0.0.1. When a stable-rc is made stable,
> it will be 0.1.0, and a security update on that would be 0.1.1, and so
> on, until the next ISO is released, which will make it 1.0.0.
I like the idea of versioning the stable grimoire. Should we add those
versions to bugzilla for the codex component so people can file bugs
against specific releases?

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page