Should BusyBox and uClibc also make a "flag version" like Embedded Linux?

Bradley M. Kuhn bkuhn at ebb.org
Fri Nov 5 16:33:36 UTC 2010


LWN.net  wrote at 18:30 (EDT) on Thursday:
> As a result of discussions held at two recent embedded Linux summits
> (and reported back to the recent Kernel Summit), the [Linux] community
> has decided to identify specific kernel versions as "flag versions" to
> try to reduce "version fragmentation". On the linux-embedded mailing
> list, Tim Bird ... has announced that 2.6.35 will be the first
> embedded flag version, and it will be supported by (at least) Sony,
> Google, MeeGo, and Linaro. "First, it should be explained what having
> a flag version means. It means that suppliers and vendors throughout
> the embedded industry will be encouraged to use a particular version
> of the kernel for software development, integration and testing. Also,
> industry and community developers agree to work together to maintain a
> long-term stable branch of the flag version of the kernel (until the
> next flag version is declared), in an effort to share costs and
> improve stability and quality."

Tim Bird's email post that LWN is quoting from above can be seen at:
http://lwn.net/Articles/413341/rss

(There's also a brief summary at
http://lwn.net/SubscriberLink/413036/a954ac0a143a99d9/ of the discussion
that took place at the embedded kernel summit on this).

I read this and began wondering if uClibc and BusyBox had an interest in
doing "flag versions" in tandem with Linux.  As most of you know, I do a
lot of GPL enforcement work for BusyBox, and I find frequently companies
stuck on ridiculously old versions of BusyBox and uClibc.  I constantly
encourage companies, as part of compliance efforts, to use more recent
versions but I have been mostly unsuccessful in that part of the effort.

Thus, I thought perhaps this "flag version" of Linux is an opportunity
for the BusyBox and uClibc community to also pick versions that the
embedding companies will standardize around, and thus allow the BusyBox
and uClibc community to better dictate what versions end up being
de-facto long-term-support versions.

BTW, both Erik and I have known Tim Bird for some time.  I can't speak
for Erik, but I am willing to spend some time reaching out to Tim to
coordinate this on behalf BusyBox/uClibc if there's interest from the
BusyBox and uClibc community.
-- 
Bradley M. Kuhn
President, Software Freedom Conservancy
           (BusyBox's & uClibc's organizational home)


More information about the uClibc mailing list