On Fri, Nov 5, 2010 at 5:33 PM, Bradley M. Kuhn <[email protected]> wrote: > 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."
This makes sense. > 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. I don't know. You need to ask busybox/uclibc *users*. If they do want something like this, I certainly can maintain such flag version of busybox. My fear is that often the reason for using very outdated version of busybox is different: it's simply lack of time/resources to migrate. There is usually a big "time to market" pressure in embedded field, and the thinking is that migration to newer kernel/toolchain/libc/busybox can make schedules slip. Flag version would not help with *that*. > 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. Yes, let's hear what user community says. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
