On Sat, 2006-03-18 at 03:16, Eric Spakman wrote: > I really don't see your point. Why do you see those things as an > improvement, what does it 'solve' (and what is Alpine?).
Eric, Others have expressed interest in these ideas. Vinki, created a 2.6 kernel, and Alpine was a proposed new branch. http://www.mail-archive.com/[email protected]/msg07953.html > 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. > I think you point to the wrong kind of 'improvements', those listed > are technical implementations. It doesn't make things necessarely > 'better'. Again, a bering-uclibc team opinion. > I would rather point to things like: > > -Webconf > -Easier upgrading These seem to be berin-uclibc team development goals. > -improve documentation (wiki) Easily done. Anyone of our project members with sufficient time and SF shell knowledge can install a wiki. No one has done it yet. > -package management ipkg <-- discouraged udeb <-- discouraged > Those are things which are visible to the enduser and increase the user > experience. Again a bering-uclibc decision. > >> In my opinion evolution doesn't only mean bring new leaf branches in > >> and let others die (when people abandon a specific LEAF distro and > >> move on to a "better" one which seems to be happened in the past). > > > >No, but sprouting new branches is a major part of the development model > >I described. I don't see that happening anymore. However, I do see > >fragmentation appearing again. Projects that in the past would have been > >welcomed here are creating new homes instead. > > > > Maybe it's SF, maybe it's me. I'm not sure what the problem is, > > but there is one. :-( > > > > why create new branches which lead to fragmentation? They don't lead to fragmentation, and are the driving force behind accelerated development I envisioned. Evolution as a project development model http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg04541.html Branch Derivation http://leaf-project.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=2 > I think the Bering-uClibc team created a very nice framework of high > quality packages. Agreed, and we're back to my current proposal. > 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. > 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. 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. I'm probably a dinosaur, and my time has passed. :-( -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs ------------------------------------------------------- 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
