On Wed, Sep 18, 2013 at 11:10 AM, Florian Fainelli <f.faine...@gmail.com> wrote: > Hello, > > 2013/9/18 Carmelo Amoroso <carmel...@gmail.com>: >> >> >> Il 18 settembre 2013 06:49:44 Thomas Petazzoni >> <thomas.petazz...@free-electrons.com> ha scritto: >>> >>> Dear uClibc developers, >>> >> >> Hi Thomas >> >> >>> The last release of uClibc, 0.9.33.2, has been made well over a year >>> ago. However, there is fairly big number of improvements/fixes in the >>> master branch that would be interesting to have in a release. At the >>> Buildroot level, we now have 53 patches in your patch stack against >>> uClibc 0.9.33.2, all coming from the master branch if I'm correct (see >>> http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2). >>> >> At a first look it seems you have there some patches not part of any uclibc >> branches ... Likely it would be nice to include them as well. >> >> For sure it's time for a 0.9.33.3 but I do also think that we can start a >> 0.9.34 release from master. >> >> Bernard what do you think ? > > Some others and myself even started to provide branches containing > patches present on master that needed backporting to release a future > 0.9.33.3 and it seemed like we were closed and then nothing happened. > I do not blame anyone as my time on this is also scarce, but at some > point I think we should make a release, even if that means doing a > 0.9.33.4 shortly after. > >> >> >>> It'd be really nice if uClibc adopted a slightly more frequent release >>> schedule, to more easily allow downstream users to benefit from >>> improvements/fixes. >>> >> >> I agree. I know to have been less active recently as my major tasks are >> currently on the kernel side and SOC bring up but I'll try to respin my >> contribution to uclibc and upstream several patches we have in STMicro >> branch. > > Very true, at the moment, both people building uClibc-based toolchains > from source and companies need to keep following the uClibc master > branch development and do the backports themselves, clearly this is an > effort duplication when uClibc could do this.
+1 LikeIt or WTF young people express their ecstasy. Just some more numbers from the Freetz router project: $ cd freetz-git/ $ git log -1 | cat commit 629fb1225d6b5338b959a6222a576bd7c4bc388f Author: er13 <er13@149334a1-2f27-0410-a3b9-fc62619ac1e6> Date: Tue Sep 17 22:19:41 2013 +0000 * do not regenerate Config.in.cache while cleaning, fixes tools/parse-config fails because of missing Config.in.generated git-svn-id: file:///var/svn/freetz/trunk@11016 149334a1-2f27-0410-a3b9-fc62619ac1e6 $ ls toolchain/make/target/uclibc/0.9.33.2/*.patch | wc -l 59 Can't say how many of those 59 patches are taken from upstream. There is no clear patch-management (and naming scheme) in Freetz. ( Embedded Linux seems to mean for a lot of people to care only about size - that's why docs are so small or do not exist? ) - Sedat - _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc