Doing a release?
Sedat Dilek
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:
>> 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? )
>
The patches can be browsed online in [1]
- Sedat -
[1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.33.2
More information about the uClibc
mailing list