[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/src header_view3d.c space.c

[Campbell Barton]

Ed Halley wrote:
>
> Martin Poirier wrote:
>> That's doesn't sound so astounding to me, just a
>> recuring barrier in all the stuff you do, one which
>> you seem very reluctant to fix.
>
> I find this attitude both obnoxious and elitist.  The
> Blender "insiders" have a serious problem with sniping
> at the freely offered patches, and at the people who
> attempt to make the product better with them.
>
> If there are VALID reasons to reject a patch, I think
> any developer wannabe will respect that authority.  If
> it's because there is additional work to be done to
> integrate useful functionality, it's time for someone
> in the "inner circle" to step up to the plate and get
> the useful functionality in there.
>
> Anything less is damaging to Blender as a product, and
> Blender as a community.
This is an area I have been trying to comprehend for a while-
Im new in some areas so might have got the wrong end of the stick.

Some of blenders internals are not pretty,
- From the developers standpoint- they dont want to have to maintain 
MORE badly designed code.
- And from the patch author, they cant see why they should have to 
conform to design constraints that some areas of blenders code doesn't 
adhere to.
... it can seem like double standards.

Intrr dosent like the current interface (partly because of personal 
taste and partly because its unfinished?) - (Intrr correct me if Im wrong)
But from also statements above, accepting more average patches dosent 
help the overall quality of blender.

Its also kind of a Users Vs Developers debate.
- Users want a feature because they would use it NOW and not having 
certain features can cripple their workflow, the design isnt important 
to them because they dont see it.
- Developers want features added in when the internal design supports it 
properly (the problem in many cases)

The problem is that there is a lot less people chan can re-design 
internals then can write usefull patches.

I have come from a user standpoint, where Id like features to be added 
because It would save me time right away, and have worked around 
blenders weak points by using python.
Intrr seems to come from the user side also, but he has been apart of 
the Blender team long enough to BE an insider, and needs to take on some 
of Blenders design decisions even if he dosent like them.


In this case I think Theeth is reasonable...

A Criticism of the patch/feature approval rationale currently used at times,
rather then postponing useful functionality for (sometimes years) 
because of the need for improved internals,
New features that do not effect Blenders DNA could be added in, Tagged 
for possible removel when the internals are changed.

On the flip side, it would be nice for patch writers to know what parts 
not to rely on. BEFORE they write a patch. (some comments in the code 
alredy hint at this)
Its never nice to have your patch rejected because "FooBar Will be 
rewritten anyhow", Especialy if your new and it took you ages to make 
the patch work. (Happened to me a few times)

- Cam

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241