To write up the issue as I see it will take time. I actually have work to do (being the middle of the work day here) so I said I would write something up soon.
In the meantime, Aaron has made good progress on some key features here so rather than wait it makes sense to commit those. Having branch for the newer stuff lets us ALL discuss it and resolve the issues.
-- Jeremy
Aaron Mulder wrote:
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
