> Look at TC3 vs TC4 - I subscribed about a year ago to their dev
> list and the
> relationships between the two groups were less than good and a few people
> were trying to make the division even greater .. apparently now
> all is good over there.
Keep in mind (maybe not Peter but other readers of this post) that:
1) Both groups always had common long term objectives but disagreed on the
way to achieve them or had different short term targets;
2) If there had been a strict imposition from above, TC3.3 could have been
forked and a lot of that group could have gone elsewhere. Maybe this
would have permanently destroyed many synergies between the 2 groups
that were always there (like with the connectors) and others that are
now evolving.
In the process, maybe some TC3.3 ideas proved their worth to some TC4
guys, which means increased cross pollination.
In this case strict control would have prevented several positive things
from happening.
Similar situation with the Logging APIs, just that this time on separate
projects:
1) Now both groups are quite a bit incompatible and forcing a merge would
destroy or send away one of the projects;
2) Still, some projects prefer Log4J and others LogKit;
3) Each of these Logging libraries seems to have its advantages and
different strong and week spots. I am quite sure of this since at the
company I work for we have been using LogKit and Log4J for different
projects and I have been doing some logging work with both;
4) The need of other projects (e.g.: commons components) to use both is
already putting some pressure into cross pollination. With time, it
can happen that:
- They will finally be able to merge;
- One of them will learn all the advantages from the other and
become dominant.
Either way, positive cross pollination is bound to happen.
This is why I would prefer to have both projects around instead of just
forcing them to merge. Lets put some peer pressure on them without
destroying them.
Many general strict rules - like forcing to merge what seems to be the
same thing - would be very destructive in this kind of situation.
Common sense must be applied (like: "no, you can not fork Tomcat in
another project") on a case by case basis.
And yes, I am aware of how uncommon common sense seems to be but I still
believe there is enough of it around here.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 12:12 PM
>
>
> On Tue, 8 Jan 2002 09:02, Jeff Turner wrote:
> > I would encourage people (esp. Jon, Ceki, Peter) to read Linus' emails
> > on design:
> >
> > "The problem with "singlemindedness and strict control" (or "design")
> > is that it sure gets you from point A to point B in a much straighter
> > line, and with less expenditure of energy, but how the HELL are you
> > going to consistently know where you actually want to end up? It's
> > not like we know that B is our final destination."
> >
> > -- http://kerneltrap.org/article.php?sid=398
>
> Choice is fine and the more the better. However I would much
> prefer that all
> Xs were implemented by one project where X is whatever we are
> talking about.
> Look at TC3 vs TC4 - I subscribed about a year ago to their dev
> list and the
> relationships between the two groups were less than good and a few people
> were trying to make the division even greater .. apparently now
> all is good
> over there.
>
> Isn't that a better solution than having projects side by side
> "competing"?
> Sure it may be rocky for a bit but it is better for Apache in the
> end (though
> maybe less ego stroking for the individual developers).
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------------
> First, we shape our tools, thereafter, they shape us.
> -----------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
