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: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] detailed QA stable grimoire and ISO proposal
  • Date: Mon, 2 May 2005 19:41:24 -0700

Will the stable-rc grimoire branch be published? Or will it be available
on a by request only basis or only to those with access to the repository?

Will there be a schedule for grimoire and/or iso releases? Eg, a new
stable grimoire release about once a month. Test isos once a week
(autogenerated from stable-rc) and stable isos shortly after stable
grimoire releases (so also once a month).

You mentioned in the previous thread about a tag in bugs for needing to
be fixed in stable. I can easily add that if it will be helpful, (Eric
and Adam can too). You can query for it using the boolean charts at
the bottom, add the following to query for them.
"flag" "contains string" "<name of flag>" AND
"flag" "contains string" "+"
At least, that works for me with iso bugs that are using flags.

-Andrew


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



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
|Sorcery Team Lead | ftp://t.armory.com/ |
--------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page