Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

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