On Fri, 2010-02-05 at 10:27 +0100, Georg Martius wrote: > It would be great if you can stay available for consulting purposes for > further developments.
I'll definitely do that ;) For starters, I'll gladly answer to any question about current and (formerly) planned design and changes of transcode. Moreover, There are still some ideas floating in the back of my head, expect some patches by me from time to time. > I am in fear that transcode is slowly going to die. I'm afraid that's quite likely. IMHO, a project of the size, with the characteristics and complexity of transcode needs at least 3-5 active developers to stay healthy and to be competitive. > How many "active" developers are there at the moment? It depends on what you count as "active" :). You and Allan Snider (et. al. ?) contributed some interesting new filters. Some people (mostly package maintainers) from time to time sends bug-fix patches. But the vast majority of the development since 2006 circa was provided by me and Andrew. HG log has of course better memory, but I'm quite confident that its answer will not be so different from mine. > How long would you thing it takes to get familiar with the code for a new > maintainer? Less than we took for me, that's for sure. ;) Just compare the shape of 1.0.x and the last HG head snapshot and tell me if I'm wrong (and why!) :^) We dedicated countless hours and huge efforts to improve the shape of our codebase, and that work it is just starting to be fruitful. Transcode has now a much saner and easily understandable structure, less code duplication, much more documentation (mostly API but some design sketches as well). Transcode has much better supporting libraries (libtcutil et. al.). Writing a module/plugin is definitively easier. Changing the core is easier as well, even there are of course much more things to grasp properly before. But there are still some scary parts. Most of them are lurking into the import layer, which is the less changed so far (improvents are been planned for 1.3.0 and beyond...). Some parts of the code are still hard to test (tcrequant) or even to grok. There is still some (IMO) bad design choices fixing them will take a lot of effort. Example: transcode opens the input too much: one time for tcprobe'ing it, one time for import thread. No good at all for streaming source. And so forth. My very wild, little-grounded guess if that any decent C/*nix programmer with at least a clue to multimedia programming will get up to speed in about three months, expending roughly the same amount of time I did... > And a last question: How much time did you roughly spend on the project? In the ol' good, funny, days, about 8-10 hours per week. Bests, -- Francesco Romani // Ikitt
