On Sat, 2008-12-06 at 23:56 +0100, Georg Martius wrote: > Hello everyone, > > please find attached a patch for the stabilization plugin and the tclist for > HEAD (created with cvs diff). > I corrected (hopefully) all remaining code-style issues and some minor > problem > but more importantly fixed a bug in the new tclist implementation. This > caused the stabilization plugin to segfault - took me a while to nail down > the problem.
Thank you for the contribution. Will apply ASAP. > If there is now anything which hinders the plugin from being included in the > next release, please let me know. I was really a bit disappointed that it did > not make in into the last 2 releases without obvious reasons. Sorry for causing disappointment! That's not my intention, quite the opposite. I think your code (and the overall idea as well) very interesting and a worthy addition. > It is > a) quite demotivating to wait so long before things get included > b) difficult to improve/debug the plugin if nobody can use it. > Anyway, sorry for the rant. No problem, we're here to talk. So, let me explain. First and foremost, 1.1.0 is a difficult _AND_ important release. Really difficult and really important. It is difficult because a lot of infrastructural work was laid down, but a very few of that work emerged to the user. So, few selling point for widespread adoption, but high need for such adoption. On the other hand, it's also a very important release: with the infrastructure laid down (or in progress), further enhancements are much easier. For example, the 1.0.7-1.1.0RC3 (raw, considering official bz2balls) intra diff is something around 12 (twelve) megabytes. The net result is that release is heavy on development side but doesn't add much on the user side. Add to that the chronical lack of resource of the core team, as Phil correctly and kindly explained. Moreover (if that isn't yet enough :)), we're currently in RC phase, after a while. A really long while. Being in RC phase means (or it should mean) that only fixes and refinement patches (docs, tests...) should be applied. Of course theory doesn't always work in practice, but that is the general direction I've chosen. Is not only that. We're also late (The original plan, at least my part of the plan :) was to put 1.1.0 out roughly one year ago), and being late stops further development for the above reason (we need infrastructure in place). We retired a really big change for this release, a whole new set of export modules (encode+multiplex, to be exact) exactly for that reason: being late, lack of development resources. The only option left was to bite the bullet and put 1.1.0 out ASAP (e.g. December the 29 as per schedule on tcforge.berlios.de website) as is (so, not perfect to be gentle) and go on, unblocking a torrent of new features (if you see http://tcforge.berlios.de/articles/tasks/index.html , which is roughly the roadmap for next major releases, and if you inspect the sources, you'll find that most of points are already almost done!) Finally, as for your patch. It was promptly added to CVS, but my original plan was to merge it after 1.1.0 released. The reasons are explained above: I tried to freeze things as much as possible, in order to have an 1.1.0 in good shape. The filter stabilization plugin is mostly self contained, but not enterely: we've got tclist for that (using a private list implementation will be worse. Transcode was historically plagued by such problem, to have private copies with small differences all around). But after some thinking, I've changed my mind. Adding this filter is another selling point for the new release, and with minor adjustment the code could be made almost enterely self contained. Sorry for the long explanation, I hope that illustrated my rumblings and the reasons behind some choices. > I saw in the tclist.c another thing I was wondering about. After a > tc_alloc(...) or similar the pointer is checked for NULL and if so the > function returns silently, true, but we have NULL checks into tc_*alloc*. That's the reason (checking for NULLness before to return in just one point) why we have the tc_*alloc*, actually :) > e.g. in tclist.c:335: tc_list_insert_dup(...) > I would rather suggest to die or at least complain with an _error message_ > because it actually a severe problem and should not be hidden. I see your point and I thank you for the patch. Will be applied. To summarize: - Sorry for causing annoyance. - Thank you for your contributions! - Expect stabilization patch to be merged into 1.1.0 RC5/Final - If you don't hear feedback, please bug me. I always try my best to promptly answer here on -devel for contribution and questions, but sometimes I have hard time finding some time to do that (and I was out of town and without (really or practically) internet access From december 5 to December 8, extremes included, actually). best regards, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
