[RFC] Proposal to change the structure of the website view/download areas and handling of "testing" releases

Kevin P. Fleming kpfleming at linuxfromscratch.org
Mon May 17 07:40:29 PDT 2004

Jeroen Coumans wrote:

> - testing = relatively stable book development (eg. minor package 
> updates, text improvements etc.)

But this is exactly what _I_ said! :-)

> - unstable = experimental stuff (major package upgrades, changed book 
> structure, new/changed chapters, etc.)
> The testing branch is relatively stable, just as previously CVS HEAD 
> always was relatively stable. The unstable branch is specifically meant 
> (and also used) as sandbox for developers.


> In terms of workflow for the editor, here's what happens:
> * an editor commits an upgraded package to unstable
> * if the upgrade is minor (eg. only bugfix), testing is also upgrade
> * if the upgrade is major (eg. new/changed functionality), it will first 
> stay in unstable to receive initial testing. Moving to testing will 
> require discussion on lfs-dev.


> Now, when working towards a release, the testing branch will be tagged. 
> We can call this pre-X or rc-X, whatever. These are the releases that 
> we'll ask the community to test. But development may still continue in 
> testing; testing will incorporate bug reports as soon as they're 
> received. Unstable is free to move on to bigger upgrades and isn't held 
> back by the release proces. That isn't possible with your model, 
> unstable would then also be affected by the release proces.

I don't see how unstable is affected by what I proposed in the least; I 
never even mentioned unstable at all. Please explain :-)

> That's a non-existing problem. The testing branch isn't intended for 
> user testing, the tagged releases are.

Agreed, so now I am asking what the point of rendering the "testing" 
branch on a daily basis is, if it's not for testing? If it's just for 
the editors to be able to see the results of their work then fine, but I 
don't think it should be visible to the general LFS community then, 
otherwise we _will_ get people trying to do builds from it.

More information about the lfs-dev mailing list