Doing a release?
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Thu Nov 7 09:58:14 UTC 2013
Dear Vineet Gupta,
On Thu, 7 Nov 2013 05:18:17 +0000, Vineet Gupta wrote:
> > It's just that I think feature-based releases is a never-ending story.
> > The current feature set hasn't moved too much for a while, so it would
> > be good to make a release out of it, and as soon as 0.9.34-rc1 is out,
> > re-open the tree to merge more features: stabilization of 0.9.34 and
> > integration of additional features for 0.9.35 can take place in
> > parallel.
>
> I agree with Thomas. What matters in the end is that code is merged in mainline.
> Build systems such a buildroot anyways allow tip snapshot for build so that should
> be good enough.
It's true that Buildroot allows to build uClibc snapshots, which is
useful for people doing active uClibc development.
However, the fact that uClibc tends to almost never do releases is
causing problems for "normal" usage of uClibc. We currently have 50+
patches on uClibc, some of them adding features, such as missing
syscalls/functions. However, while we can apply those patches when
Buildroot is responsible for building the toolchain (using the
so-called 'internal backend'), we cannot do that for the uClibc
pre-built toolchains, such as the ones provided by Analog Devices for
the Blackfin architecture for example. This is causing problems because
an increasing number of userspace packages use features such as
posix_fallocate(), execvpe(), posix_madvise() and so on, which have
never been part of an uClibc stable release. Therefore, none of the
existing pre-built toolchains have these features.
If the uClibc community was doing more regular releases, then hopefully
providers of pre-built toolchains would update their uClibc version,
and make life easier for uClibc users.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
More information about the uClibc
mailing list