[Bf-committers] About COLLADA im/export functionality situation

Arystanbek Dyussenov arystan.d at gmail.com
Mon Feb 6 22:17:38 CET 2012


I have looked through all COLLADA bugs in the bug tracker, both open and
closed, and divided them into two categories: bugs in the existing
functionality (I called them "core bugs", because I think they are the part
of the main functionality, which has to constantly work well) and features
not yet implemented.

The result you can see
https://docs.google.com/document/d/1BPNqt9j3lASpfqbi17JUQawNLeahpjAVrbor7eSV_N8/edit
.

On Tue, Feb 7, 2012 at 2:51 AM, Arystanbek Dyussenov <arystan.d at gmail.com>wrote:

>
> On Mon, Feb 6, 2012 at 1:42 PM, Campbell Barton <ideasman42 at gmail.com>wrote:
>
>>
>> These goals are too fuzzy for a GSOC project, the 3 main priorities
>> you list are speculative - designing new shiny architecture without
>> tangible results is a mistake.
>>
>> Further, I don't think finishing off Collada makes for a good GSOC
>> project. The current problematic compatibility issues make for too
>> much of an unpredictable project.
>>
>
> I purposely left out the details to make the whole picture clear to all.
> The suggested goals are based on my experience working on the project and
> on the real analysis that I conducted in order to understand the current
> situation.
>
>
>>
>> - Maybe there are a few main bugs that only need fixing before its
>> generally useful...
>> - Maybe its far more work then we can expect from a GSOC project
>> - Maybe we need to kick out opencollada (and use something else)...
>>
>
> The developers need good architecture to feel themselves comfortable with
> the code. But rewriting the architecture as well as introduction of
> automated testing requires considerable effort, so sponsoring is necessary.
>
>
>> Since nobody seems to have a good handle on this, I think we're better
>> off having this resolved outside of GSOC.
>> Where motivated devs can focus on key issues without trying to fit
>> this into a 10week project.
>>
>> If these devs want to re-factor the code or cleanup the architecture,
>> they can go ahead since they will be having to work with the new code
>> anyway.
>>
>
> I wrote this proposal because I think I can, using my knowledge, improve
> the current situation and direct the project in the direction, where it
> will begin to bring the desired results.
>
> --
> Best regards,
> Arystanbek Dyussenov
>
>


-- 
Best regards,
Arystanbek Dyussenov


More information about the Bf-committers mailing list