Re: [Leaf-devel] Evolution as a project development model
Mike, Thank-you for the excellent reply and insight that explains much of the depth, experience, and respect that is rightfully deserved and displayed in this project :-) On Friday 01 March 2002 11:37, Mike Noyes wrote: At 2002-02-28 10:51 -0600, guitarlynn wrote: Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. Yes, very observant, we all have our baseline to work from. I think all of our releases are showing that the baseline is not only being challenged now, but being lowered when compared to the limitations of the past. The only thing monolithic is the package repositories I can wait on seeing kde30.lrp for a while though :) snip of completely true statements that leave nothing to be said The acknowledgement and existance of LEAF affiliates assumes the position that you seem most concerned with, and the only seperation between release and affiliate here appears to be the opinion and process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. It also benefits in vastness of scope that is unmatched in any other project or release/version/distro that I am aware of. Many others are very good products, but very limited in what you can do with them when compared. This is an extreme benefit to the project and releases. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. That is disappointing to hear. I'm am in the process of attempting to use cish for some simulation in Cisco (hopefully). This shell could really add a compatibility layer to the project. I hope he wouldn't object to his shell being used with LEAF. David D has it packaged. If I remember right, Ken worked with Coyote for some time, his insight and different point of view would have also been nice! This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. That is one reason I make an honest effort to try many different releases/products. Many of them fit a certain niche better than others. The sad part is that some of the more cutting-edge versions do not necessarily fit the most used niche, and end up not being used as often. This would be a good point to thank all the developers for their hard work and excellent products that I am happy to say are at the top of their niche's in respect to quality. snip of more sound reasoning 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. It appears to have promoted many excellent products and a very healthy, stable development community. As Charles admonished me earlier, I now do for you. Thank-you, Mike ;) All of our opinions/ideas matter. Whether you're a lead developer or project admin has nothing to do with the validity of your opinion/idea. Absolutely, however the effect of a project leader or lead developer having an issue would create far more effects to the community than myself. This does not mean that my opinion does not matter or should not be effective, but rather the people that primarily have made the larger contributions to the project should get the respect that they deserve for the time and effort that has made this possible. I intend this with exhaultion to these people, rather than any lack of self-esteem on my part or source of degrading demeanor towards anyone else. BTW, this reply took me almost two hours. Your post was very thought provoking. Thanks. :-) The reply was worth every minute you put into it, IMHO. Thank-you for extending your thoughts :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Evolution as a project development model
At 2002-02-28 10:51 -0600, guitarlynn wrote: On Thursday 28 February 2002 08:29, Mike Noyes wrote: snip Lynn, Your description above closely resembles what SF calls a Foundry. I believe we are more than that. In your opinion, are we a Linux Embedded Appliance Foundry, or are we a project that uses evolution as a development model? In my opinion, we are the latter. I think of LEAF more like the Gnome or KDE projects. Lynn, Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. My resistance to the idea directly relates to the amount of time and effort that went into gathering everyone under one roof. I'm leery of anything that might lead us back to the fragmentation of the past. That is completely understood. I think the maturity and tolerance of other ideas are far more accepted with LEAF than were constrained within the limitations of the past. The fragmentation in the past seemed to be developers going directions that were not accepted under the opinion of the person hosting/controlling the project site. Was Matthew's, Coyote, George Toft's, David D's, or Charles' branches ever hosted on the LRP site, or any one site for that matter? Not that I can remember. They were treated more like what LEAF refers to as affiliate versions. They weren't even given that much recognition. The only thing allowed was mailing list use. As a result, fragmentation ensued. I believe that is a profound and clear fundamental difference that has no predecessor with LRP. Agreed. The acknowledgement and existance of LEAF affiliates assumes the position that you seem most concerned with, and the only seperation between release and affiliate here appears to be the opinion and process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. [1] http://freshmeat.net/projects/cish/ [2] http://www.frazierwall.com/ From your theory of the project evolution model, I would assume includes by definition that one release would eventually eat up other releases. I don't see this happening per se because of the different directions that everyone is headed. Think of evolution within a family/species, not food chain. As I sated previously [3], releases/branches survive on their merits, and the willingness of their lead developer(s) to continue working on them. [3] http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg04417.html As directions from different projects head towards the same direction, some may merge together (or rather join forces for development reasons). Most won't! The reasoning for this, in my mind, lies in the simple core target media a single floppy disk. This target media will always promote different ideas and process direction. This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. Has the process of the past ever proven evolution were targets and evolution were the same? The mere existance of LRP, Coyote, what-ever Matthew will call his new router-system, Mosquito, Duckling, and associated releases of LEAF (not to mention countless others) thoroughly proves otherwise. Some simply will not exist in the umbrella that we call LEAF and the simple existance of any or all of these denies the concept of evolution itself as being a driving force between LEAF releases. You just proved that evolution works on a macro level. We are using it within this project on a micro level. I doubt we're the first project to try this, but I was unable to locate an example of a prior attempt. However, I was able to locate a paper describing the benefits of chaotic evolutionary development. http://papers.maxwell.af.mil/research/ay2000/awc/hept.htm The maturity, selflessness, and tolerance of the lead developers make LEAF what it is, including you Mike . there are fundamental differences in you having the power over this site w/o
