Doing a release?
sedat.dilek at gmail.com
Wed Sep 18 10:35:58 UTC 2013
On Wed, Sep 18, 2013 at 12:30 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Wed, Sep 18, 2013 at 11:10 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
>> 2013/9/18 Carmelo Amoroso <carmelo73 at gmail.com>:
>>> Il 18 settembre 2013 06:49:44 Thomas Petazzoni
>>> <thomas.petazzoni at 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
>>> 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
>>> 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
>> 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 at 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
> $ ls toolchain/make/target/uclibc/0.9.33.2/*.patch | wc -l
> 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 
- Sedat -
More information about the uClibc