Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Tue, May 03, 2005 at 10:26:07AM +0200, Benoit PAPILLAULT wrote:
> Seth Alan Woolley a écrit :
> >=== 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.
> 
> This definition of stable is not quite clear, even if you describe it 
> later in more details.

If you have a better idea, I'm open for a short, distinct definition.

> 
> >=== 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 don't see the relationship between ISO release number and stable 
> grimoire release version. Is that a way to know which grimoire version 
> has been used for building the ISO?

It's merely a reference number for debugging purposes.

> 
> BTW, does this mean that we will be able to "scribe add stable-rc" ?

Yes.  

> 
> >=== 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.
> 
> I really like to have the ISO build process fully automated to be able 
> to run it once a week for instance. However, right now, we have not 
> reached this level yet :-(

We're getting there.  The hardest part is making the initial chroot when 
there are outstanding bugs in stable, but with a more stable stable, 
that should go away.  The second hardest part is making it past the 
aliens issue.  Your fixing up that part of the code and more of 
basesystem actually using "config" and "volatiles" files at the same 
time they actually track the files, and we can eliminate the problems 
there.

We will build it, and if there are problems, we will code around them as 
they come up.  I still want an ISO generated and bugs filed on _any_ 
errors we find (I could re-run it every day for the most part).

> 
> Two points:
> 
> * ISO already has a naming scheme. This currently does not include "-rc" 
> stuff. See http://wiki.sourcemage.org/index.php?page=ISO+numbering+scheme

I don't propose a change in iso naming.  I propose a change in the 
release process.  Call it -test if you want.  We need to have more 
generations so that natural selection can fix the problems faster.

> 
> * I don't like the "one week of testing" delay. One week can last and no 
> one would have tested the ISO. I would replace it by "one successfull 
> installation report (report yes, saying "it works" is not enought) + no 
> bug reported after one week".

The one week of testing implies that unit tests will be happening.  We 
already have a developer who wants to unit test the ISO.  They will 
largely be responsible for delegating and ensuring this part gets done.  
If he says it's broken, which he will know soon enough, we delay stable 
release.  Currently we have no testing process for stable isos except 
"hey, does it work for you?"  That leaves a lot of holes.  Testing, in 
my mind is going to work its way to full unit tests.  "create partitions 
in all filesystem types, mount them, and do a write and a read" for 
example.

> 
> Another question about stable grimoire bugs: you should add a rule in 
> your process where bugs reported on the stable grimoire should be fixed 
> in the stable grimoire as well. 

In the discussion with Andrew in the same thread, you'll find that we 
are working on this.

> This rule should be included in your QA 
> process because fixing stable grimoire bugs should not make the stable 
> grimoire worse.
> 
> With our current usage of bugzilla, the bug is marked FIXED whenever 
> it's fixed in devel and integrated into test, EVEN if the initial bug 
> has been reported on the stable grimoire. As our QA Lead, i'll let you 
> elaborate on that...

Bugs in stable grimoire will be marked FIXED when fixed in test.  Then 
they will have a request flag for integrating to stable.  Only certain 
people can approve them.  When they are approved a volunteer will go 
around every day (possibly more often) and integrate them.  When they 
are integrated, they will be closed.  At least, that's one way to do it.

That way a search for FIXED with an approved integrate to stable flag 
should be all the query they need to find them.

That's a draft right now, I'm open to somebody who knows bugzilla better 
to make the details saner if they can.

Seth

> 
> Benoit PAPILLAULT, ISO guru
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 

-- 
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: pgpVI4_NmMyJt.pgp
Description: PGP signature