Hi John, >> this is a little depressing. After spending years (and tons of emails) >> discussing the need for a kernel 2.6 version of LEAF, there has been >> no response on this list on the topic. > > Sorry, Martin, I only read the list as a newsgroup, every week or so. No problem. I just started to doubt the value of the time spent (and not mainly by me - Dirk and Eric put in as much, if not more, time as I have). It's not about ego (hence my line about not looking for a "good job, well done" response), it's simply about finding out if one is wasting one's time. I don't gain anything if people use the new branch (or Bering uClibc, or any other LEAF branch), so if I'm working on something that nobody is really interested in, I guess I'd better stop wasting my time and do something more productive. If there is interest, and people will use it (and some will contribute), it's much easier to justify the time spent. To me, that's really all it comes down to.
> It's important to me because LEAF still seems by far the simplest > small, easily customizable distribution for running Shorewall; and the > latest Shorewall-4 with the excellent shorewall-perl compiler handles > IPsec only in the new kernel 2.6 style with nf-policy-match support. Well, there's an new issue, I guess. Somebody will have to build a perl.lrp package that provides everything shorewall-perl needs. I guess size isn't much of an issue (I doubt that anybody who knows what they're talking about is going to expect a 2.6 kernel, a useful set of tools plus perl to fit onto one floppy). But since I have no experience whatsoever with that part of shorewall (I got by just fine with the part of shorewall provided with Bering uClibc), I'm afraid somebody else will have to provide that set of tools. I can help with the buildtool stuff, so I'm sure it can be done as a collaborative effort - but I doubt I'll find the time or energy to provide that all by myself (that's mainly what the paragraph about focusing on the core features, on things that those who build the packages need themselves and can actually test themselves, was all about in my first email in this thread). > Without really understanding the leadership structure of the project I don't think there's much of a "leadership structure". Everybody is free to contribute, or to create a branch of their own if they want to do something different from what everybody else is doing. At least, that's the way I understood the evolutionary development model that Mike proposed - and I like the idea. It just didn't seem to really work too well in the past (since it seemed it always came down to a small group of people doing the development). But this _could_ change now, with a new branch that uses the (IHMO) solid base of Bering uClibc, uses the same build toolchain (so people who know how to build packages for Bering uClibc, can build packages for the new branch without having to re-learn anything). That was mainly the reason for my frustration - we provided a working image, the devel toolchain is the same as for the current stable release, so not getting any feeback was a bit disappointing. Maybe I sent the email too soon - but maybe the email served as a wakeup call as well, getting more people out of the "let's see how that progresses" mode (one that I often fall into myself...). > I > had assumed from a mailing list archive reading it was futile to work > on a kernel 2.6 branch; you seem to have proved otherwise, so perhaps I > will find the time to collaborate. Well, maybe that wasn't made very clear (or, more likely, it never really was clear to any of the participants of the discussion at the time - it's hard to say anything for sure before one has tried it. And then, the 2.6 kernel has changed over the last 2+ years, since the discussion first came up). To me, it always seemed "impossible" to continue to support floppies with kernel 2.6. That still holds true - at this point, it doesn't look like it's doable. I would still like to find a way to boot from floppy, but at this point, it doesn't look like it will happen. But using a 2.6 kernel booting from something with more storage is surely possible (obviously, by now), it just meant a considerable amount of work, and at the time the discussion first came up, it just didn't seem reasonable to spend that time, given the marginal benefit a 2.6 kernel would have meant. For me, the reason to start working on that was first of all, because I wanted to see if it could be done (to get past the "gee, wouldn't it be nice if..." stage), and maybe more importantly, because I have a few PC Engines ALIX boxes lying around here that I feel would benefit from a 2.6 kernel (if and how much they'll benefit from it remains to be seen - I've not had time to actually work on that part yet). I would be very happy to see LEAF to get a broader developer base, with people working on all kinds of things, rather than just waiting for the the "core developers" to provide something (I never liked that term anyway - to me the only reason somebody was a "core developer" always seemed to be that the person in question was the one who contributed, rather than hoping somebody else will do it). So, if we manage to broaden the developer base, the distinction between a "core developer" and somebody who simply actively participates in development will become extremely blurry (to the point of non-existence). And to me, development means more than just providing packages - we need people looking at the toolchain, the packages, for testing, helping with the documentation, working on the webpage, helping on the lists, all kinds of things. But of course, there will be some sort of a hierarchy somewhere (especially if there's disagreement on some architectural or technical question among the developers), but lets just wait and see how that works out - so far, I'm confident that one can solve technical questions among the developers, without having to resort to rank within the project hierarchy (if there is one in the first place). The only thing I will have an issue with is being told what I should do in my spare time. I will put in my spare time to make sure the new branch does what I need it to do. I will spend my spare time working on something that I agree is worthwhile for the project as a whole. But I will not spend my spare time just to please somebody else, working on something I don't need, or something I don't see much value in (no matter how much value it would provide to the people asking - I'm not debating that it might be useful to _them_...). But I'm getting redundant - since that's basically a re-phrase of one of the paragraph's of my announcement mail for the new branch. Thank you for your feedback - and I hope that by working together, we can all bring the LEAF project forward. Martin P.S. Sorry for being so verbose :-) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
