Skip to Content.
Sympa Menu

sm-discuss - [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: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] detailed QA stable grimoire and ISO proposal
  • Date: Mon, 2 May 2005 18:51:15 -0700

=== 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:

* 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".

* 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.

=== ISO release process ===

To better follow ISO development, the ISO process itself will be
recreated for each stable grimoire release. If there are any major
issues with the ISO after one week of testing, it will continue with -rc
status. So all ISOs will have -rc designation at first. When no known
bugs exist for the ISO, it will be released as -rc still and aliased as
a major stable ISO after one week of community testing with no
additional bug reports and a release notes list of issues that are
acceptable to the QA TL, the ISO TL, and the PL, the PL of course able
to override any decision here.

Lately I've been working on trying to get the ISO build process
documented and somewhat usable by filing an enormous amount of bugs
against the proj3 branch (which is our current devel branch). When
that's sane enough, I'll integrate it into the grimoire release process
as I mention in the paragraph above. (I spent all weekend on this, so I
apologize for not jumping on the stable grimoire release process like I
should have that warranted the questions to the grimoire in a previous
thread). FYI, the build process is distinct from future work on the
next-generation installer, of course (being worked on somewhat
separately).

So again, any comments?

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org

Attachment: pgpdHQYgRF6d8.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page