Doing a release?

Sedat Dilek sedat.dilek at gmail.com
Wed Sep 18 10:30:05 UTC 2013


On Wed, Sep 18, 2013 at 11:10 AM, Florian Fainelli <f.fainelli at gmail.com> wrote:
> Hello,
>
> 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
>>> 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 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
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 -


More information about the uClibc mailing list