geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@gluecode.com>
Subject Re: Deployment Status
Date Fri, 05 Nov 2004 00:53:55 GMT
As Aaron says, this was a quick chat to clarify issues rather than a 
shady meeting in smoke filled rooms.

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


Mime
View raw message