Hi Mike, note - when I say "we", I'm speaking of the Bering uClibc team (and not LEAF as a whole or developers from other branches).
>>Ofcourse we look at things like kernel 2.6 and initramfs and we will >>> move on when it gain us something, but one step at a time. > > > The 'we' above is a bering-uclibc team decision. It's a monolithic > approach to development decisions. Indeed it is _for the Bering uClibc branch_. But I was under the impression we were talking about the development model for the LEAF project, not for a specific branch. >>-package management > > > ipkg <-- discouraged > udeb <-- discouraged > the fact that we didn't drop everything to implement a different package system back when this came up in the past, doesn't mean that we will never change the packaging system (same goes for the kernel, by the way). At the time we dismissed the idea, there were other (in our view more important) things to do. Now we are revisiting the idea because * Bering uClibc 3.0 will break binary compatibility with older releases anyway, so one might as well look at a different packaging format * we're trying to implement some sort of update/upgrade system, and a new packaging system might help with that But all of those things apply only to Bering uClibc, other branches are obviously free to do as they wish. Basically, those decisions are the result of having a limited amount ot manpower and still wanting to finish what we start. That makes us have to weigh the amount of effort we need to put into a change, and the benefit we get in return. If something doesn't provide significant benefit, it moves down on the TODO list and things that promise more benefit move up. Over time, it may well be that something that was dismissed in the past will be revisited, simply because people now see the benefits differently than in the past. >>Instead of reinventing the wheel again and again, you could also >>> think of branches as using the existing framework to create specific >>> functionality by using the existing packages. It's just an higher >>> level view. > > > You're redefining our project development model. We're back to my > proposal, which doesn't hide behind semantics. > > Under your model we'd still be using LRP. Charle Steinkuehler's > EigerStein, David Douthitt's Oxygen, and Serge Caron's PacketFiler would > never have been LEAF branches. Even LEAF wouldn't have existed. You're trying to make this an either-or thing. Either we use the evolutionary development model, or we can try to share as much as possible between branches. Think of it this way - each branch will need some configuration frontend of some sort. Rather than each branch starting from scratch and doing their own thing, why not use an existing framework and instead focus on what makes the branch unique (pretty much like was done in the past - as far as I know, lrcfg was used in Dachstein, Bering and Bering-uclibc). If the defining characteristic of a specific branch is a totally new, radically different config engine, that's obviously where that branch should do their own thing and not use a common framework. >>There is also room enough for separate projects working on things like >> webconf and package management. I don't see a reason to compete >> within the limited room of a project with a small userbase. I believe >> in cooperation to use the limited resources we have to improve things >> with a common goal. > > > In other words, a monolithic development model defined by the > Bering-uClibc team. Bering-uClibc wins. > > I'm probably a dinosaur, and my time has passed. :-( I'm utterly confused. In the mail you linked to, you wrote: > 1. Use of evolution as a development model. > 2. Tolerance for new ideas and differing opinions. > 3. Full control by lead developers of release/branch direction > and purpose. So, when the Bering-uClibc team is using their "Full control of release/branch direction and purpose." (by setting their own priorities), this is a sign that we want a monolithic development model and that we're trying to make Bering-uclibc "win"? I don't agree with Eric that all efforts should be aimed at collaboration (even though it makes sense given the limited amount of manpower we have) - usually, a little competition, different approaches to solving a certain problem or simply different overall goals are good, even if it means that progress may be slower, due to the scarce resources. That way, we don't end up with a one-size fits all distro, but rather with several, that reflect the different ideas and priorities of the developers. But sharing work where it is possible, is simply a sensible thing to do (IMHO). > Take the LEAF name, and move on. > However, don't pretend that you're advocating a evolutionary development > model as I defined it any longer. Nobody from the Bering uclibc crew wants to take the LEAF name and move on. I think you're seeing some sort of attempted coup where there is none. The goals and priorities of the people in the Bering uClibc crew seem to not coincide completely with yours (for example when it comes to creating a USB image) - that's all, as far as I can tell. I must be missing something fundamental. Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
