You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/11/05 00:07:59 UTC
Deployment Status
I talked to Jeremy. Our plan for now is that I will check in a
deployer tool that includes the following features:
- everything, when working online (on the same PC as the server)
- package and distribute, when working offline (on the same PC)
- nothing, when working online (on a different PC from the server)
This is basically the same functionality in the current
deployer.jar tool, plus online same-PC deployment via JSR-88.
Jeremy is going to write up a "position paper" regarding
additional offline deployer features when he gets a chance (next couple of
days?). He has concerns about the original vision of a single unified
offline+online tool. (We should spend some time on this at the Hackathon
if it's not resolved sooner.)
Jeremy is also working on the remote-PC JSR-88 implementation, and
the tool will be updated to work with that once it's ready.
Aaron
Re: Deployment Status
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Nov 4, 2004, at 4:48 PM, Aaron Mulder wrote:
>
> 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.
+1
That's why shoving in a branch gets the code there for everyone to see,
makes sure you don't lose the hard work you put into it, etc. There
can be no objection for putting into a branch, because it doesn't
affect anyone else and is easy to get rid of.
geir
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: Deployment Status
Posted by Jeremy Boynes <jb...@gluecode.com>.
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
Re: Deployment Status
Posted by David Blevins <da...@visi.com>.
On Thu, Nov 04, 2004 at 07:48:48PM -0500, Aaron Mulder wrote:
>
> 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.
>
Don't single Dain out, I also voted for the deployer as did six other
people. Haven't seen anyone retract their vote.
-David
Re: Deployment Status
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 4 Nov 2004, David Blevins wrote:
> Yes, but 8 people voted +1 to the proposed deployer so, flame war or
> not, this is discussion everyone should be able to participate in.
That is why Jeremy is going to write up his position!!! If you
are trying to suggest that there should be no conversations between
individual committers that do not take place in a public forum, well, I
guess I just don't think that's realistic. I think our goal should be to
report the issues and/or outcome to the mailing list for further
discussion, which is what we are doing in this case.
> Jeremy has an obligation Dims, Bruce, Dain, Hiram, James, Jailton,
> myself, you and the community to vote if he disagrees. Otherwise we
> proceed with what was voted upon regardless of who implements it.
I invite you to proceed, then. I am going to check in that which
we all agree on, but I would like to resolve the other issues before doing
more work in the grey area.
Aaron
Re: Deployment Status
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 4, 2004, at 9:01 PM, Jeremy Boynes wrote:
> David Blevins wrote:
>> Jeremy has an obligation Dims, Bruce, Dain, Hiram, James, Jailton,
>> myself, you and the community to vote if he disagrees.
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?
> listName=dev@geronimo.apache.org&msgNo=9427
Which links to:
> Date: Tue, 26 Oct 2004 08:52:38 -0700
> From: Jeremy Boynes <jb...@gluecode.com>
> Subject: Please Vote: 1 deployment tool or 2?
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> 2 simple tools rather than one complex one.
>
> --
> Jeremy
I see two things here.
1) There is no -1
2) This is a comment and not a technical argument.
I thought the solution we +1ed was simple, and since there was no other
comments/votes from you, that you were fine with the solution. If you
would like to put in an official veto, then all you have to do is sent
and email with your technical argument. At the very least, I think you
need to enlighten the rest of us about the problem you are seeing
-dain
Re: Deployment Status
Posted by Jeremy Boynes <jb...@gluecode.com>.
David Blevins wrote:
> Jeremy has an obligation Dims, Bruce, Dain, Hiram, James, Jailton,
> myself, you and the community to vote if he disagrees.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=dev@geronimo.apache.org&msgNo=9427
Re: Deployment Status
Posted by David Blevins <da...@visi.com>.
On Thu, Nov 04, 2004 at 07:48:48PM -0500, 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.).
>
Yes, but 8 people voted +1 to the proposed deployer so, flame war or
not, this is discussion everyone should be able to participate in.
Jeremy has an obligation Dims, Bruce, Dain, Hiram, James, Jailton,
myself, you and the community to vote if he disagrees. Otherwise we
proceed with what was voted upon regardless of who implements it.
-David
Re: Deployment Status
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
Re: Deployment Status
Posted by David Blevins <db...@gluecode.com>.
On Nov 4, 2004, at 3:42 PM, Dain Sundstrom wrote:
> On Nov 4, 2004, at 3:07 PM, Aaron Mulder wrote:
>
>> I talked to Jeremy. Our plan for now is that I will check in a
>> deployer tool that includes the following features:
>>
>> - everything, when working online (on the same PC as the server)
>> - package and distribute, when working offline (on the same PC)
>> - nothing, when working online (on a different PC from the server)
>>
>> This is basically the same functionality in the current
>> deployer.jar tool, plus online same-PC deployment via JSR-88.
>
> So in your off list discussion what features got axed?
>
>> Jeremy is going to write up a "position paper" regarding
>> additional offline deployer features when he gets a chance (next
>> couple of
>> days?). He has concerns about the original vision of a single unified
>> offline+online tool. (We should spend some time on this at the
>> Hackathon
>> if it's not resolved sooner.)
>
> 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.
>
Exactly. The following people voted +1:
Aaron Mulder
Bruce Snyder
Davanum Srinivas
Dain Sundstrom
David Blevins
Hiram Chirino
James Strachan
Jailton Lopes (non-binding)
Jeremy is welcome to direct is opinion to the list so that everyone who
voted +1 can participate in the discussion.
-David
Re: Deployment Status
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 4, 2004, at 3:07 PM, Aaron Mulder wrote:
> I talked to Jeremy. Our plan for now is that I will check in a
> deployer tool that includes the following features:
>
> - everything, when working online (on the same PC as the server)
> - package and distribute, when working offline (on the same PC)
> - nothing, when working online (on a different PC from the server)
>
> This is basically the same functionality in the current
> deployer.jar tool, plus online same-PC deployment via JSR-88.
So in your off list discussion what features got axed?
> Jeremy is going to write up a "position paper" regarding
> additional offline deployer features when he gets a chance (next
> couple of
> days?). He has concerns about the original vision of a single unified
> offline+online tool. (We should spend some time on this at the
> Hackathon
> if it's not resolved sooner.)
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.
-dain