Mike; Eric Spakman indeed spoke for the Bering-uClibc team and their decisions.
He just expressed a view in the discussion - that's what disscussions are for. If someone will build a new branch like Alpine it would be fine, and may speed Bering-uClibc with 2.6 kernel significantly From day one the Bering-uClibc crew understood LEAF and branches as a win-win situation, Bering-uClibc very much profited from Jacques Nilo's and Erik Wolzaks work, Alpine may profit from Bering-uClibc What's actually the problem make Alpine a new branch? Mike; in no way it's encouraging if one of the most active LEAF developers (count cvs commits, count postings on the mail lists, look into the guides) get's bashed for expressing his (or his team's) opinion!! I agree with you, Luis' mail recently was not as polite as I think mails in this community have to be, but he apologized quickly. Can we all calm down and respect each others work and opinions? kp Am Samstag, 18. März 2006 17:05 schrieb Mike Noyes: > 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/leaf-devel@lists.sourceforge.net/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.htm >l > > 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. :-( ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
