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

[Campbell Barton]

On Mon, Feb 6, 2012 at 5:46 PM, Arystanbek Dyussenov
<arystan.d at gmail.com> wrote:
> *Hi,
>
> My name is Arystan. I am one of the developers of the COLLADA im/exporter
> for Blender, which is being discussed now.
>
> I participated in designing this project and developed armature animation
> im/export in 2009. From September 2009 to June 2010 I took part, along with
> other contributors, in bugs fixing in COLLADA im/export functionality.
>
> In 2010 I had to stop working on the project because I had to seek for a
> job.
>
> As one of the initiators of the project I would like it to be successful,
> to justify the invested efforts and people’s expectations and to continue
> developing.
>
> At the moment there are following problems in COLLADA im/export
> functionality:
>
>   1. it is difficult to fix bugs
>   2. there are few people, who fix bugs
>   3. it is difficult for a new developer to add new features
>   4. new features create new bugs
>   5. there are bugs in animation im/export
>
> In 2009 the code was designed with only a single goal in mind: “just to
> make it work”. The design did not take into account the possibility of
> modifications and extensions by other developers in the future and the
> question of providing stable functioning in the future by means of a single
> clearly organized testing process, was not addressed.
>
> I think these are the two main reasons why it is currently difficult to fix
> bugs, there are few people who fix bugs and why new bugs pop up in
> previously developed functionality.
>
> I think that for successful development of the project we need to set 3
> main priorities:
>
>   1. architecture, extensible in the directions of all possible new
>   features. This will allow the developers to add new features without
>   interfering with the main code.
>   2. contributor-friendly code. Will help to attract representatives of
>   commercial companies to participate in the development of COLLADA im/export
>   functionality.
>   3. a clearly organized testing process. Will provide stable im/export
>   functioning in the future.
>
> I offer to tacke these problems this year. Since I am a last year student,
> it would be ideal for me to get sponsoring from GSOC. This is why I ask you
> to consider accepting COLLADA in the GSOC projects list this year.*
>
> --
> Best regards,
> Arystanbek Dyussenov

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.

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

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.