On Thu, 4 Nov 2004, Dain Sundstrom wrote:
> So in your off list discussion what features got axed?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is exactly why I'm reporting on the conclusions here. I
would appreciate if you don't give me a hard time for doing the right
thing. We spent an hour wrangling on the phone, and had we done it on the
mailing list, it would have taken days or weeks and no doubt degenerated
into a flame war.
As for the second half of that question, more extensive offline
deployment features got axed (start, stop, deploy [as opposed to
distribute], etc.).
The gist of the problem is that it is onerous for a tool to be
completely correct for offline deployment against an arbitrary server
configuration. For example, what if the server does not have a disk-based
configuration store or persistent configuration list? The "naive"
deployer only knows about the GBeans it was built with, and would write
changes to disk which would be ignored by the server. The "correct"
deployer would need to load the entire server from module-to-be-deployed
up to root, and then start interacting with GBeans from here, which seems
quite heavy (particularly for operations like list-modules or
list-targets). The issue revolves around what the best middle ground
would be (if in fact you believe in middle ground at all).
> That doesn't sound like the Apache way to me. This plan was discussed
> on the list and the community came to a decision. I think you should
> continue your development and Jeremy can complain when he gets time.
Let me cast it this way: Jeremy feels strongly enough that I am
not comfortable unilaterally overriding him. In in hour, I was unable to
convince him of the error of his ways. It is my opinion that he needs to
discuss his concerns with the wider community. He does not have the time
to do that "right this second", and I agreed not to represent his position
to the list (we kind of proved that doesn't work already). So I think he
will be addressing the issue in more detail when he can.
However, I don't want to drop everything until then. So I'm
planning to commit what we agree on, and leave the rest for further
discussion.
On the meta level, I do not appreciate being stuck in the middle,
with Jeremy harassing me to not proceed, and Dain and others harassing me
to proceed. I think the community needs to resolve this issue together.
I'm not convinced that the best way to proceed is to commit code that
someone flagrantly objects to.
Aaron
