On Feb 19, 2007, at 11:06 AM, Sander Temme wrote:
On Feb 19, 2007, at 1:44 AM, Nick Kew wrote:
The breakage between 1.x and 2.0 was far too much. If we
do it again, the world will rightly conclude that Apache
is not a solution fit for the long term.
+1. While it's fun and rewarding to hack on advanced stuff in its
own right, the project as a whole must keep an eye on the user
community, their needs and their wants. Many of us wouldn't be
here if the server wasn't popular to begin with: we need the user
community as a soundboard and a source of new contributors.
Yes and no. There is an inherent reflex of any group of people
to resist change. That is the main reason I wanted the work to
be done in one or more sandboxes, instead of some place that is
perceptually limited by a version number.
New design is not a group effort. Critique of designs is a group
effort, as is tweaking the results to fit new ideas or setting
constraints within which a particular solution can be found.
New implementation is not a group effort either, at least no more
so than can be cleanly broken out into components and worked on
separately.
It is important to always keep in mind that the group as a whole
does not *do* anything in particular for Apache other than to
critique each others' designs and implementations in the hope that
our collection of experience will compensate for the time spent
collaborating on a common solution.
We work best as a collaboration when we give people the freedom to
explore their own personal wild ideas (or even just reasonable ideas
for which the solution has no clear timeline). If we artificially
constrain the scope of what can be done based on the group's a priori
perception, then we effectively go nowhere new (because collectives
fear the new). The fact of the matter is that any one of us could,
given adequate energy, rewrite the entire server in a couple months
of focused time, and the only thing holding us back (aside from lack
of said time) is the fear of acceptance at the end. We need to lose
that fear.
In short, worrying about API backwards compatibility is not an
issue yet. If you want to make it an issue, then you have to
create a way to provide backwards compatibility for whatever
ends up being merged to trunk. You don't have to worry about
what breaks in amsterdam until a later time, when we have evidence
to evaluate whether the breakage is worth the cost and we have
a reasonable chance of determining whether a bridge API could
be built as part of the merge.
In the mean time, work on what matters to you. Do not work against
what matters to someone else.
....Roy
