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

[Campbell Barton]

On Tue, Feb 7, 2012 at 7: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.

Undoubtedly you can make improvements to the current system
architecture, its just my opinion that such improvements should be
done in the context of fixing user level issues, not on their own.

>> - 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.

IMHO its worth trying  to manage refactoring/code-cleanup/redesign
with volunteers, organize tasks into smaller chunks that volunteers
can complete.

As for testing, we definitely need to do better here,  my impression
is its very easy to write tests that work well for a while but nobody
ends up using. Work on testing is great but need existing maintainers
on-board that they find the tests useful, will maintain them and
follow up on issues when they fail.

>> 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.

This is fine but IMHO should be apart of a project which addresses (at
least some of) the existing problems too.

> --
> Best regards,
> Arystanbek Dyussenov



-- 
- Campbell