At 2002-02-28 10:51 -0600, guitarlynn wrote:
>On Thursday 28 February 2002 08:29, Mike Noyes wrote:
> > 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.
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"
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.
>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 
decided not to join or affiliate with us, but he does participate on the
mailing lists. Ken Frazier  decided he didn't want anything to do with us.
> 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 , releases/branches survive on their merits, and the
willingness of their lead developer(s) to continue working on them.
>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
>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 having a release
>that has never happened before. Trust among different releases at the
>mercy of site admins and their opinions, this doesn't exist anywhere
>else. You figure out the reasons for the "glue".
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
>My point ..... all paths lead to the same destination.
>Does my opinion matter?
>Not really, I'm not a lead developer or a project admin.
As Charles admonished me earlier, I now do for you. 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.
BTW, this reply took me almost two hours. Your post was very thought
provoking. Thanks. :-)
Mike Noyes <[EMAIL PROTECTED]>
Leaf-devel mailing list