[Bf-committers] Release scenario

Ton Roosendaal bf-committers@blender.org
Tue, 18 May 2004 15:26:53 +0200


One of the topics here on mailinglist, and in last weeks IRC session  
(yes, minutes follow!) was the testing/release scheduling.

-------------- 1. Platform management ----------

Proposal is to assign small teams now to do the 'platform management',  
especially in assisting with testing builds, makefiles/scons/mscv, and  
do releases.
The roles in such teams can be sorted out later, below you find what I  
think is possible:

Windows team:
- Simon C: MSVC6 / installer
- Nathan L: MSVC7 / Scons
- Martin P: Cygwin
- Chris B: beta tests, testing builds

Linux team:
- Michel S: Scons / release builds
- Brecht v L: testing builds
- Juan P M: beta tests
- (I think we can use another coder here for platform issues...)

OSX team:
- Jean Luc P: 10.3, Scons, release builds
- Ton R: 10.2, makefiles, release builds
- (Looking for an OSX artist for beta tests)

Irix now is only by Chris W... Solaris by Kent M, FreeBSD by Hans L,  
who also still does makefile support. For Irix to remain a viable  
Blender platform we need help!

------------- 2. Regression suite ----------------

Main purpose of regression files:
- quick tests for fitness of a binary
- reference files for testers (users) to base bug reports on

Proposal is to expand the current 'suite' with testing samples  
created/maintained by everyone who's working on a specific part in  
Blender, organized by the 'module owners'.
To keep the test manageable, we can provide separate downloads for it,  
per module.

The 'official' test suite then should be have a very well balanced set  
of tests; which is possible to do in very short time (less than 15  
minutes), this because long tests will just not be done!

I will cleanup the current set, and move most of the render files to a  
separate 'rendermodule test' download. Inside of the files, I'll pack  
the images too, as reference.

What I also like to see is someone gathering a 'basic UI test', with  
themes, menu actions, buttons, pulldowns, area splitting, etc.

It is also relevant to promote this prominent on our site, so everyone  
can load and help testing.

---------- 3. Release scenario ---------------------

Looking at how we work now, I can see a couple of phases which we could  
formalize more. I have a suggestion for it, based on DefCon alert as  
USA uses. :-)

B-Con 1: Relaxed, after release, gather energy and ideas
B-Con 2: Release targets and projects defined, release date might be  
unknown though
B-Con 3: Release scheduled, CVS frozen except for commits in approved  
          make testing builds
B-Con 4: CVS frozen, test builds are on release level, commits only  
possible on test results
B-Con 5: Release, webpages up, slashdot attack! Upgrade needed?

Naming is of course just an idea. But what could help really well is  
clearly posting this on our site for everyone. So users interested to  
help out know what's expected.

When we go for a release to (level 3) we can define how much time is  
needed for it. I still think one or two weeks for '3' and one week for  
'4' can work well, provided the tests go not too bad. It's important to  
have the 'frozen cvs' period as short as possible.

----------- 4. Installation issues -----------------


I would still love someone going over all the details we have now, and  
fix this diagram to perfectly match what we want for 2.34.

Before going into long debates on what's required or not, please remind  
that we don't so much need a 'desired' system, but a system that's easy  
and simple to maintain cross platform.

My preference still is for *minimum* install, with optional choices for  
(in docs or scripts):
- installing desktop icons and filetype assignments
- installing default scripts/modules in your home dir or system

If possible, for files that hardly ever change (like the bfont.ttf) we  
could just choose to compile it in, as for .b.blend, .Bfont, splash,  


Ton Roosendaal  Blender Foundation ton@blender.org