On Mon, Feb 6, 2012 at 5:46 PM, Arystanbek Dyussenov <arysta...@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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers