On Wed, Sep 18, 2013 at 12:30 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > 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? ) >
The patches can be browsed online in [1] - Sedat - [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.33.2 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
