Thanks to all of you for this discussion. To be clear, I raised this issue only as a point of discussion for the community. I didn't intend to demand that a specific recommendation of any kind be followed. Rather, I was sharing some thoughts that came to my mind when I saw Tim Bird's "flag" suggestion on LWN, in the context of the part of the embedded world I generally see, and then suggesting that joining Tim's initiative might be both (a) easy and (b) useful in *some* way for the BusyBox and/or uClibc projects. It's of course up to the developers of these projects to decide if such is useful or not.
Rob Landley wrote at 17:04 (EST) on Wednesday: > The depth of the epic fail to understand the embedded world embodied > in that sentence is just awe inspiring. The embedded software world a big place, and it's likely true that I probably see a very different side of it than Rob does. Thus, my observations probably don't apply in some parts of the embedded world, but I also suspect that Rob's observations may not be universally true everywhere and for every embedded product. Nevertheless, I agree completely that in those corners that are as Rob describes, there's no obvious value in a "flag" version of either BusyBox or uClibc. Rob Landley wrote at 03:08 (EST): > http://busybox.net/FAQ.html#backporting > Bradley? Read that FAQ entry please. I'd forgotten, we already had a > FAQ on why we don't have flag versions. I was indeed already familiar with that FAQ entry, although it wasn't precisely on my mind when I posted last week. However, rather than reasking that FAQ myself, I was instead, in effect, proposing a slight modification to it -- i.e., something like (to make a minimal edit on the text that's there (CAPS used to emphasis said change)): ... We want to make the current version, OR OUR 'FLAGGED VERSION' work for you. But diagnosing, debugging, and backporting fixes to ANY OTHER VERSIONS ... > This does not apply to BusyBox, and does not apply to uClibc. We > don't have significant out-of-tree patches that prevent people from > upgrading. Anyway, to separate this discussion from the specific idiosyncrasies of Linux itself, consider that some projects do "Long Term Support" releases. Whether such is of value (and to whom it has value) is a matter that's hotly debated in many Free Software and Open Source communities. I wasn't per se seeking to open such a debate here. Rather, I was wondering if there was interest in joining on Tim's bandwagon, but I pointed out that joining said bandwagon would require picking a 'flag' version. As such, I noted that while it *won't* get people running git master and/or the latest release, it *might* get them at least running a more recent release rather than (as the FAQ mentions) something pathetically old like BusyBox 0.50. It seemed to me there might be some value in that. Meanwhile, it seems from the discussion that a few BusyBox/uClibc developers are mildly in favor of this idea, a few are very much against it, but most who commented seem to be ambivalent. Thus, it appears there's no clear consensus. (I am not, BTW, demanding a consensus be reached, but instead I merely offer my efforts to help get BusyBox and/or uClibc on the aforementioned bandwagon should there be a consensus on the issue.) I will reiterate only one part of my argument in favor of the idea (which is likely the most important part): I think the primary value to BusyBox and/or uClibc of getting involved with this "flag version" plan is a marketing/advocacy advantage for BusyBox and/or uClibc toward further adoption in some segments of the embedded Linux development space. I admit that I have no hard data to present that proves a marketing/advocacy benefit here. My opinion on the subject is primarily just a feeling, informed by my ten years of experience of regularly observing the parts of the embedded Linux market with which I regularly come in contact (primarily through GPL enforcement efforts). Conservancy's job as BusyBox's and uClibc's non-profit home is (in part) to help the promote the projects (but always without interfering with the artistic and technological decisions of the project). When I saw Tim's email on LWN, I thought this was a good place to make a recommendation to the projects' developers in this regard. Thanks to all of you for your time in considering my recommendation, and I do apologize if this discussion turned out to actually be a pointless rat hole. -- Bradley M. Kuhn President, Software Freedom Conservancy (BusyBox's organizational home) _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
