[Bf-committers] Re: 64 bits Blender
Wouter van Heyst
larstiq at larstiq.dyndns.org
Sat Jan 20 01:41:16 CET 2007
On Fri, Jan 19, 2007 at 10:38:18PM +0100, Alexander Ewering wrote:
> On Fri, 19 Jan 2007, GSR wrote:
> >So now all code of past years have to be checked and as Alex mentioned
> >docs should be written (I would add that new contribs should only be
> >accepted after checking, even if that is a bit nasty, but better than
> >having another "cleanup needed" in the future).
> I actually wanted to suggest such a "test" for getting commit rights, but
> already being known as a total "coding fascist" and "he only mails when he
> wants to complain" guy, I refrained...
> However, the point probably is that such a test would be pointless, because
> already as-is, there are far less contributors than actually required, so
> such a test would probably only worsen the situation - even if it raised the
> quality a bit.
> On the whole, this is situations where the downsides of open source become
> appearent: Quality is more or less a random thing.
Seen over the entirety perhaps. There are enough projects keeping
quality tighter under control though, and peer review is one the tools
available to ensure that. Another option that might fit more into the
current Blender culture would be a test suite able to catch regressions,
especially when it comes to SDNA (padding changes, anyone?). I'm not
talking about test242.zip, but an automated suite that can (and dare I
say should) be run continyously. Wether that is on each commit or each
night, pointing directly at what change introduced the problem, and what
specific test is failing. Tinderbox did this in the past for
buildability, but you can test more than that.
Wouter van Heyst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 307 bytes
Desc: Digital signature
Url : http://projects.blender.org/pipermail/bf-committers/attachments/20070120/1b543a7b/attachment-0001.pgp
More information about the Bf-committers