Re: [VOTE RESULT] InetAddress unbounded cache patch backport

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
> On 1/18/07, Noel J. Bergman <no...@devtech.com> wrote:
>> Oh good ... so now JAMES functionality is going to depend upon a local
>> modification to the container launching it?
> 
> running in a container introduces a coupling of functionality to the 
> container

We already depends on classloaders provided by the container for 
mailets, I think this acceptable: we use a container, we try to use its 
features. If we move to spring (as an example) we'll have to take care 
to define a new place for mailets resources (SAR-INF is a phoenix 
specific folder).
In fact the TTL issue is a "JVM issue/feature", the JVM is the container 
of our container (phoenix) and our functionalities strictly depends on 
both containers.

>> Does anyone believe that's a
>> maintainable solution, as we look at alternative runtime environments?
> 
> but i definitely take your point: just doing this would be an
> unmaintainable solution going forward

The ttl issue is an issue to be resolved in containers: it is a security 
property. I think it would be really dangerous and inappropriate to set 
security properties inside component code.
On the other side trunk services already avoid using InetAddress at all 
so we won't suffer this issue anymore.

> we need to elect a release manager who can shepherd the release
> through these difficult waters. we need to take a release branch ASAP
> so the short term push towards a release can be separated from medium
> term concerns about design and maintainability.

I agree. How is a release manager elected? What is the "special power" 
of the release manager vs other committers?

> but on trunk, we should implement the best medium term solution. this
> means implementing noel's fixes in a more elegant fashion.
> 
> - robert

Trunk is not affected by this issue: we already fixed it long time ago.

We added the ttl properties there anyway to protect users from 
InetAddress usage in their own mailets.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] InetAddress unbounded cache patch backport

[Stefano Bagnara <ap...@bago.org>]

robert burrell donkin ha scritto:
>> > we need to elect a release manager who can shepherd the release
>> > through these difficult waters. we need to take a release branch ASAP
>> > so the short term push towards a release can be separated from medium
>> > term concerns about design and maintainability.
>>
>> I agree. How is a release manager elected?
> 
> by an election ;-)
> 
> typically lazy consensus
> 
>> What is the "special power" of the release manager vs other committers?
> 
> none but none should be needed
> 
> - robert

*IMHO* we have the following possible releases:

- 2.3.1 : IMHO everything is ready in v2.3 (as I wrote in the recent 
"About 2.3.1" topic) and only need someone to take care of it (I can do 
if asked, but I would prefer if someone else do)

- 2.4.0 : (ex next-minor) has been proposed by Noel and Vincenzo. If 
they still have this in their plans IMHO one of them can be the release 
manager and branch "v2.4" from current "v2.3" and start the "vetted 
backports" (as per Noel mails)

- 2.5.0 / 3.0.0: (ex next-major) sooner or later trunk should (IMHO) be 
branched to start consolidation and release something. We agreed on this 
generically but have not found a solution. Now you are the most active 
in trunk, so maybe you will take care of understanding what can be done 
and when.

I personally don't care of 2.4.0 (next-minor). I'm willing to help for 
2.3.1 if asked, and to help with 2.5.0/3.0.0 (once I'll have understood 
what can be done there).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] InetAddress unbounded cache patch backport

[Norman Maurer <nm...@byteaction.de>]

Stefano Bagnara schrieb:
> robert burrell donkin ha scritto:
>>> > we need to elect a release manager who can shepherd the release
>>> > through these difficult waters. we need to take a release branch ASAP
>>> > so the short term push towards a release can be separated from medium
>>> > term concerns about design and maintainability.
>>>
>>> I agree. How is a release manager elected?
>>
>> by an election ;-)
>>
>> typically lazy consensus
>>
>>> What is the "special power" of the release manager vs other committers?
>>
>> none but none should be needed
>>
>> - robert
>
> *IMHO* we have the following possible releases:
>
> - 2.3.1 : IMHO everything is ready in v2.3 (as I wrote in the recent
> "About 2.3.1" topic) and only need someone to take care of it (I can
> do if asked, but I would prefer if someone else do)

Well i allready did most of the merging. So i can step in if noone is
against this ;-)


>
> - 2.4.0 : (ex next-minor) has been proposed by Noel and Vincenzo. If
> they still have this in their plans IMHO one of them can be the
> release manager and branch "v2.4" from current "v2.3" and start the
> "vetted backports" (as per Noel mails)
>
> - 2.5.0 / 3.0.0: (ex next-major) sooner or later trunk should (IMHO)
> be branched to start consolidation and release something. We agreed on
> this generically but have not found a solution. Now you are the most
> active in trunk, so maybe you will take care of understanding what can
> be done and when.
>
> I personally don't care of 2.4.0 (next-minor). I'm willing to help for
> 2.3.1 if asked, and to help with 2.5.0/3.0.0 (once I'll have
> understood what can be done there).

Same here.
>
> Stefano

bye
Norman

-- 
Mit freundlichen Grüßen 

i.A. Norman Maurer 
Systemadministrator

ByteAction GmbH
Auf der Beune 83-85
64839 Münster

Phone:   +49 (0) 60 71 92 16 - 21
Fax:       +49 (0) 60 71 92 16 - 20
E-mail:    nm@byteaction.de
Internet: www.byteaction.de
AG Darmstadt, HRB 33271
Ust-Id: DE206997247
GF: Thomas Volkert
------------------------------------------------------ 
Diese E-Mail enthält vertrauliche Informationen und ist nur für den in der E-Mail genannten Adressaten bestimmt. Für den Fall, dass der Empfänger dieser E-Mail nicht der in der E-Mail benannte Adressat ist, weisen wir darauf hin, dass das Lesen, Kopieren, die Wiedergabe, Verbreitung, Vervielfältigung, Bekanntmachung, Veränderung, Verteilung und/oder Veröffentlichung der E-Mail strengstens untersagt ist. Bitte verständigen Sie den Absender dieser E-Mail unter folgender Rufnummer +49 (0) 6071 / 9216-0, falls Sie irrtümlich diese E-Mail erhalten haben und löschen Sie diese E-Mail. Der Inhalt dieser E-Mail ist nur rechtsverbindlich, wenn er von unserer Seite schriftlich durch Brief oder Telefax bestätigt wird. Die Versendung von E-Mails an uns hat keine fristwahrende Wirkung. 

This e-mail contains information which is privileged and is intended only for the Addressee named in the e-mail. In case that the recipient of this e-mail is not the named addressee, we would like to inform you that it is strictly prohibited to read, to reproduce, to disseminate, to copy, to disclose, to modify, to distribute and/or to publish this e-mail. If you have received this e-mail in error, please call the sender under following telephone number +49 (0) 6071 / 9216-0 and delete this e-mail. The content of this e-mail is not legally binding unless confirmed by letter or telefax. E-mails which are sent to us do not constitute compliance with any time limits or deadlines.
------------------------------------------------------ 



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [VOTE RESULT] InetAddress unbounded cache patch backport

[robert burrell donkin <ro...@gmail.com>]

On 2/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:

<snip>

> > we need to elect a release manager who can shepherd the release
> > through these difficult waters. we need to take a release branch ASAP
> > so the short term push towards a release can be separated from medium
> > term concerns about design and maintainability.
>
> I agree. How is a release manager elected?

by an election ;-)

typically lazy consensus

> What is the "special power" of the release manager vs other committers?

none but none should be needed

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org