[Bf-committers] Proposal for 2.36 release
trip at spymac.com
Mon Nov 22 20:22:15 CET 2004
What happened to that python script that copied everything you did and
then could play it back ? Or was that just a mix up from me. Either way
that would be something to look at for the tester program.
The regression tester files are not enough they are neat but something
else is missing to make them a real test tool.
> Or we need to spawn 2 CVS, stable and devel, which is possible with
> like subversion, but a pain with CVS to keep in sync.
I welcome a new better method of source code retrieving or whatnot if
it makes the coders happier. All I can do is test and compile but I
have heard good things about subversion, and OSX xtools has it built in
Shorter release cycles would seam very friendly in the users area to.
It would feel more like developers are in a caring mood as this is not
pay for software and is not needed to have perfect new features
constantly just a little something keeps us happy.
Lastly, D-O-C-U-M-E-N-T the new scripts and provide test files and
document all of the scripts. Half of the scripts have nothing just a
random script in a menu.
Now input on the scripts, they are great to have, but the method in
which they are presented and use is awful. When I go the script window
I am presented with a blank screen and a button at the bottom that
opens to a huge list of menus in menus. We need a button for each that
or a list that quickly illustrates the purpose. This would a- give a
quick visual indicator and b- provide a fast method of implementation
of the tool, menus in menus are tedious and slow.
Lastly, why do I have to load a script in the text view? Why not load
them in the script view ? My view is that the text view is for script
coders and the script view is for users. Why not make it so ? Oh and
where is the button for play in text view? Why is it trapped in another
menu? Less mouse movement equals less blender fatigue for scripts that
have no interface and are just hit play kinda scripts.
> On Nov 22, 2004, at 1:48 PM, Matthew H Plough (mplough at Princeton.EDU)
>> After watching two releases go not as well as we had
>> hoped, I'm beginning to think that the problem lies
>> just where it always does with code I write for
>> classes -- insufficient testing. A CVS freeze is a
>> possible solution, but I don't think it's the whole
>> solution. We need to come up with a way to test
>> code more completely; I'll try to outline this.
>> A couple bugs slipped through that we should have
>> caught immediately -- stuff like tapers crashing,
>> but the vast majority of the code performs very,
>> very well in most cases. Curve tapering is a new
>> feature that, if I recall correctly, is not included
>> in the regression suite. Thus, the first part of
>> better testing is to make sure that our test tools
>> keep up with new features. Every feature needs to
>> be tested as if someone were trying to use it.
>> However, that's not the whole deal. I feel like I'm
>> spouting debugging mantras from my algorithms and
>> data structures class, but we need to thoroughly
>> test boundary conditions. No vertices, lots of
>> vertices, odd scales, etc. all need to be tested.
>> Now that I've said that, I'll try to make something
>> of it. I've been doing horrible things to Blender
>> lately, so I'll do my best to flesh them out into
>> .blends that could go in the regression suite.
>> I don't know what to do about people not running the
>> regression suite, though -- any ideas about how to
>> get more people to perform the tests? I'll gladly
>> perform them, but our current testers + 1 really
>> doesn't help a whole lot.
More information about the Bf-committers