Changes

All packages we know about are checked.  If a developer adds a new dependency that we haven't seen before, then the developer will need to manually scp the file into smetest on first use for it to be processed and added to the distro. After that the script will check for newer/updated versions and drop them automatically in smetest whenever a new version is available. To build a package (the buildsys will choose itself where it goes) simply send the build command from your environement (see the wiki page for package build).

All packages we know about are checked.  If a developer adds a new dependency that we haven't seen before, then the developer will need to manually scp the file into smetest on first use for it to be processed and added to the distro. After that the script will check for newer/updated versions and drop them automatically in smetest whenever a new version is available. To build a package (the buildsys will choose itself where it goes) simply send the build command from your environement (see the wiki page for package build).

Smetest can have multiple versions of a package, maybe the three newest. I am not aware whether they are archived <span style="color: red;">To be clarified</span>. As they are built from CVS it should be possible to recreate one if really needed.

Each repository has a max number of versions and releases that it can contain.  Most by default are set to 1 for both values. The exceptions are smetest that has versions = 2 and release = 3 and smeupdates-testing which has version = 1 and release = 3. It means that the test repo can have two different version streams (devel and prod) as well as several releases on each version.

 

When the developer is satisfied that a package won't break the system and wants wider testing without actually releasing things, the package should be moved manually into smeupdates-testing.  This is a semi-stable testing area that shouldn't break a system but hasn't been verified yet.  This repo is also included in Shad's staging area (stage) for the purpose of building the next ISO.  All verifications should be done on packages in smeupdates-testing. Once the package is verified, and agreement reached on the Go/NoGo for releasing, the package should be copied manually to smeupdates and released.

When the developer is satisfied that a package won't break the system and wants wider testing without actually releasing things, the package should be moved manually into smeupdates-testing.  This is a semi-stable testing area that shouldn't break a system but hasn't been verified yet.  This repo is also included in Shad's staging area (stage) for the purpose of building the next ISO.  All verifications should be done on packages in smeupdates-testing. Once the package is verified, and agreement reached on the Go/NoGo for releasing, the package should be copied manually to smeupdates and released.