You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <be...@googlemail.com> on 2006/09/26 11:00:27 UTC
When do we ship?
Hi guys,
I've been unable to test RC3 and, as a consequence, I did not vote on it.
So I feel I am not in a comfortable position to put up a vote.
But, seriously, why wait any longer?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: When do we ship?
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Dienstag, den 26.09.2006, 16:45 -0400 schrieb Noel J. Bergman:
> > to simplify the website build and to include 2.2.0 and 2.3.0 docs
>
> We can update our web site indepedendently of the release cycle for the
> product.
But it would be very, very good to have the website in the best possible
condition when we release. (Of course we are software developers and not
web-designers (but not to forget to say that it looks quite good at the
moment))
In the time-frame, when the release gets announced I hope for some
bigger interest. IMO, the chance is good to get mentioned in the related
new tickers. The first impression potential new users get is very
important.
I know, I act the same: Read an interesting article, klick the link to
the project website and decide whether it's worth to download and give
it a chance.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano wrote:
>
>> In roadmap for the 2.3.0 final we have:
>> Fix m2 projects to not lookup dependencies on ibiblio
>
> Huh? Why do we care about Maven 2 for 2.3.0? I don't care about Maven 2
> for anything ever, but it certainly should not be a blocker for JAMES 2.3.0.
Well, not an issue as I'm faster.. ;-)
Our website and the documentation site for james 2.3.0 is created with
maven2, so this is why I care of it as part of the release.
>> to simplify the website build and to include 2.2.0 and 2.3.0 docs
>
> We can update our web site indepedendently of the release cycle for the
> product.
I prefer to have consistency between what we put in the documentation
site for 2.3.0 and what as been released in 2.3.0: version specific docs
are part of the server distribution.
>> Move server-site documents from james/server repository to
>> james/site/server repository
>
> JAMES 2.3 is a product release, and should not be blocked on anything
> related to Maven repositories.
Non an issue: I think you concentrated too much on this non-issue...
This will not block anything because I worked hard to publish the
updated site including the last documentation.
>> Invalid (outdated) urls in config files.
>> http://issues.apache.org/jira/browse/JAMES-626
>
> Fair enough. Non-critical.
I'll fix this tomorrow. We waited 2 years for a release, I don't think
that we want to release with bad urls if we know we have them.
>> We would also have more feedback on the leak issue opened by Noel
>
> The bug exists. I have no time right now to track it down, and everytime I
> have tried, the JVMs have hung early. :-\
I don't say that the bug does not exists: the bug may be everywhere, so
if we don't know if it is in james or in connector or in the jvm is not
of help.
Norman is running an *Xmx5M* james using mysql since few weeks, and I'm
running an Xmx64M using files repository since a month: so it is nothing
that is triggered so often in standard configurations.
I think we can wait at least for you to send us the cleaned config.xml
before releasing 2.3.0: I think few more eyes looking at your config.xml
worth the wait.
>> Either we decide this is not confirmed and close it until we can
>> confirm it, or we investigate on the cause of the leak.
>
> I won't close something that exists. And no one else seems to have either
> the time or awareness of the problem to look. Whatever is leaking, and I
> still see it, is slow enough that it can be worked around. I have so far
> not found any evidence to suggest that it is related to volume. So I'd
> release with a caveat.
Again, please instead of replying to this messages you could help
sending us more informations to be able to investigate and reproduce it.
you still cannot be sure the bug exists in james source code or in james
bundled libraries. Imo we have to fix this: I'm sorrt but if no one is
able to reproduce it but you then it will be closed as won't fix.
I don't say there is no bug, I simply say that we don't need that issue
opened if we don't have any clue on the cause of the bug and we don't
have complete informations about the environment (and the configuration)
where the bug has been experienced.
>> one of my production james (something near rc2) is up since 1 month
>> and with a default Xmx (64MB) and I had no OOM (this is an almost
>> default 2.3 configuration with file repositories).
>
> I wish I could say the same. :-(
>
> --- Noel
Please try the time to clean your config.xml and add it to JIRA. If you
don't have this time please at least select some trusted people and send
it privately. I hope you can find at least one people you trust that
will have the time to clean it and upload it to JIRA.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/28/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> >> I agree. We should not release until the website is ready. Btw, i don't
> >> think this will block us, because Stefano finished almost..
> >
> > As I see it we are not only having changes to the documentation but to
> > the code base as well, which leads us to RC4. RC4 could have been
> > RC1... for 2.3.1.
>
> There is nothing stopping us to release RC3 as 2.3.0 final if we want to
> do that. What happens in svn and what we want to release have not to be
> necessarily synchronized.
>
> I think that we should start a vote for RC4 as soon as possible (and
> after a brief test I will be +1 for RC4 release) and I would be -0 for
> releasing RC3 as 2.3.0 now.
>
> > We will always have bugs, even known bugs. So this should not be the
> > _only_ criteria for not releasing. It has to be weighted against the
> > nasty old bugs we have in the current stable release and if our user
> > base would be better off with the new ones instead of the old ones.
> > ;-)
>
> We waited more than 2 years to make this release and I we need to
> establish credibility for this release after 2 years of inactivity: imho
> a release with *known* bugs after so much time is a bad thing from a
> user perspective.
Ok, thats one perspective, the other is: "In all those years they
never put out a stable release fixing those bugs I have lurking here.
If they could at least fix _them_ and give me a better performing
system."
> People already has an RC to use and we are actively supporting anyone
> trying to use 2.3.0RCs much more than people using 2.2.0. If we were
> name M$ then we would probably have released 2.3.0a1 as 3.0, 2.3.0a2 as
> 3.0SP1, 2.3.0a3 as 3.0SP2, 2.3.0b1 as 4.0 and so on... Imho the RC
> cycles ends when you close the known bugs and you can't find new bugs
> until the vote for the final release is found: we are not a business, we
> should care for quality more than money or number of downloads ;-)
Right. Perfect. But at some point you have to get pragmatic. You are
not really saying we should close every single little issue, are you?
> > The fixes we are doing now (docs int 2.3-branch, serial nos, mime
> > conversion disabling) are all neccessary, but should they hold the
> > release? Remember, we could publish a "known problems" documentation,
> > too.
>
> We have to evaluate each change: I think that the convert fix is safe.
> The serial fix is needed in trunk. I think we should add also in 2.3.0
> to make it more clear that the classes are compatible, but the change
> should be safe, also.
I am not saying they are uneccessary or aren't safe to do.
That's not my point.
> If anyone think we are ready for a release and want to start a vote then
> go ahead: AFAIK releases cannot be vetoed, so a simple majority is
> needed.
Tempting... I'll think about that. ;-)
> I'm currently -0 for a release for 2 causes:
>
> 1) I would like to include fixes committed by Norman today
>
> 2) I think that we should delay a few weeks trying to close JAMES-592:
> if there is a leak in the james sources that eat 2MB per day I would
> like to have it fixed for 2.3.0 final or at least to be able to say:
> there is a leak in dns/there is a leak when using the toprocessor mailet
> but we decided to not fix it for 2.3.0 so be aware of this problem (or
> something similar)
Fair enough. But set this into relation to the dramatic memory
consumption improvements which have happend over the last month. With
that in mind, releasing with JAMES-592 remaining open does not look so
bad to me. Nobody said this is a blocker, au contraire: Some of us
even wanted to close this thing ;-)
The whole reason for me to rant over this topis is: I am afraid we
might fall back into "small-fixes-every-day mode" on release branch
like it was a few months back on trunk.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/28/06, Norman Maurer <nm...@byteaction.de> wrote:
> Bernd Fondermann schrieb:
> > On 9/28/06, Stefano Bagnara <ap...@bago.org> wrote:
> >> Bernd Fondermann wrote:
> > Ok, thats one perspective, the other is: "In all those years they
> > never put out a stable release fixing those bugs I have lurking here.
> > If they could at least fix _them_ and give me a better performing
> > system."
> Well if this is the point of the user he can use one of the rc's ;-)
Would you? I probably wouldn't.
> > The whole reason for me to rant over this topis is: I am afraid we
> > might fall back into "small-fixes-every-day mode" on release branch
> > like it was a few months back on trunk.
> >
> > Bernd
> No Fear ;-) I just don't feal thats the right "way". I agree 2.3.0 is
> much more stable then 2.2.0 , but for me realising with bugs is
> something i know from microsoft and not from apache projects :-P
> So let us fix the bugs release a new RC4 and after that publish final.
:-) never releasing anything is something I know from sourceforge, not
from Apache. ;-)
but ok, lets go for RC4.probably I have time to test this one, then.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Norman Maurer <nm...@byteaction.de>.
Bernd Fondermann schrieb:
> On 9/28/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Bernd Fondermann wrote:
>> >> I agree. We should not release until the website is ready. Btw, i
>> don't
>> >> think this will block us, because Stefano finished almost..
>> >
>> > As I see it we are not only having changes to the documentation but to
>> > the code base as well, which leads us to RC4. RC4 could have been
>> > RC1... for 2.3.1.
>>
>> There is nothing stopping us to release RC3 as 2.3.0 final if we want to
>> do that. What happens in svn and what we want to release have not to be
>> necessarily synchronized.
>>
>> I think that we should start a vote for RC4 as soon as possible (and
>> after a brief test I will be +1 for RC4 release) and I would be -0 for
>> releasing RC3 as 2.3.0 now.
>>
>> > We will always have bugs, even known bugs. So this should not be the
>> > _only_ criteria for not releasing. It has to be weighted against the
>> > nasty old bugs we have in the current stable release and if our user
>> > base would be better off with the new ones instead of the old ones.
>> > ;-)
>>
>> We waited more than 2 years to make this release and I we need to
>> establish credibility for this release after 2 years of inactivity: imho
>> a release with *known* bugs after so much time is a bad thing from a
>> user perspective.
>
> Ok, thats one perspective, the other is: "In all those years they
> never put out a stable release fixing those bugs I have lurking here.
> If they could at least fix _them_ and give me a better performing
> system."
Well if this is the point of the user he can use one of the rc's ;-)
>
>> People already has an RC to use and we are actively supporting anyone
>> trying to use 2.3.0RCs much more than people using 2.2.0. If we were
>> name M$ then we would probably have released 2.3.0a1 as 3.0, 2.3.0a2 as
>> 3.0SP1, 2.3.0a3 as 3.0SP2, 2.3.0b1 as 4.0 and so on... Imho the RC
>> cycles ends when you close the known bugs and you can't find new bugs
>> until the vote for the final release is found: we are not a business, we
>> should care for quality more than money or number of downloads ;-)
>
> Right. Perfect. But at some point you have to get pragmatic. You are
> not really saying we should close every single little issue, are you?
>
>> > The fixes we are doing now (docs int 2.3-branch, serial nos, mime
>> > conversion disabling) are all neccessary, but should they hold the
>> > release? Remember, we could publish a "known problems" documentation,
>> > too.
>>
>> We have to evaluate each change: I think that the convert fix is safe.
>> The serial fix is needed in trunk. I think we should add also in 2.3.0
>> to make it more clear that the classes are compatible, but the change
>> should be safe, also.
>
> I am not saying they are uneccessary or aren't safe to do.
> That's not my point.
>
>> If anyone think we are ready for a release and want to start a vote then
>> go ahead: AFAIK releases cannot be vetoed, so a simple majority is
>> needed.
>
> Tempting... I'll think about that. ;-)
>
>> I'm currently -0 for a release for 2 causes:
>>
>> 1) I would like to include fixes committed by Norman today
>>
>> 2) I think that we should delay a few weeks trying to close JAMES-592:
>> if there is a leak in the james sources that eat 2MB per day I would
>> like to have it fixed for 2.3.0 final or at least to be able to say:
>> there is a leak in dns/there is a leak when using the toprocessor mailet
>> but we decided to not fix it for 2.3.0 so be aware of this problem (or
>> something similar)
>
> Fair enough. But set this into relation to the dramatic memory
> consumption improvements which have happend over the last month. With
> that in mind, releasing with JAMES-592 remaining open does not look so
> bad to me. Nobody said this is a blocker, au contraire: Some of us
> even wanted to close this thing ;-)
>
Yes for me it should be closed as "won't fix". We can reopen it later
if we really feel like that... I not whould see it as stopper for 2.3
cause only noel have this problem.. So it seems to be not so common.
> The whole reason for me to rant over this topis is: I am afraid we
> might fall back into "small-fixes-every-day mode" on release branch
> like it was a few months back on trunk.
>
> Bernd
No Fear ;-) I just don't feal thats the right "way". I agree 2.3.0 is
much more stable then 2.2.0 , but for me realising with bugs is
something i know from microsoft and not from apache projects :-P
So let us fix the bugs release a new RC4 and after that publish final.
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> I agree. We should not release until the website is ready. Btw, i don't
>> think this will block us, because Stefano finished almost..
>
> As I see it we are not only having changes to the documentation but to
> the code base as well, which leads us to RC4. RC4 could have been
> RC1... for 2.3.1.
There is nothing stopping us to release RC3 as 2.3.0 final if we want to
do that. What happens in svn and what we want to release have not to be
necessarily synchronized.
I think that we should start a vote for RC4 as soon as possible (and
after a brief test I will be +1 for RC4 release) and I would be -0 for
releasing RC3 as 2.3.0 now.
> We will always have bugs, even known bugs. So this should not be the
> _only_ criteria for not releasing. It has to be weighted against the
> nasty old bugs we have in the current stable release and if our user
> base would be better off with the new ones instead of the old ones.
> ;-)
We waited more than 2 years to make this release and I we need to
establish credibility for this release after 2 years of inactivity: imho
a release with *known* bugs after so much time is a bad thing from a
user perspective.
People already has an RC to use and we are actively supporting anyone
trying to use 2.3.0RCs much more than people using 2.2.0. If we were
name M$ then we would probably have released 2.3.0a1 as 3.0, 2.3.0a2 as
3.0SP1, 2.3.0a3 as 3.0SP2, 2.3.0b1 as 4.0 and so on... Imho the RC
cycles ends when you close the known bugs and you can't find new bugs
until the vote for the final release is found: we are not a business, we
should care for quality more than money or number of downloads ;-)
> The fixes we are doing now (docs int 2.3-branch, serial nos, mime
> conversion disabling) are all neccessary, but should they hold the
> release? Remember, we could publish a "known problems" documentation,
> too.
We have to evaluate each change: I think that the convert fix is safe.
The serial fix is needed in trunk. I think we should add also in 2.3.0
to make it more clear that the classes are compatible, but the change
should be safe, also.
If anyone think we are ready for a release and want to start a vote then
go ahead: AFAIK releases cannot be vetoed, so a simple majority is
needed. I'm currently -0 for a release for 2 causes:
1) I would like to include fixes committed by Norman today
2) I think that we should delay a few weeks trying to close JAMES-592:
if there is a leak in the james sources that eat 2MB per day I would
like to have it fixed for 2.3.0 final or at least to be able to say:
there is a leak in dns/there is a leak when using the toprocessor mailet
but we decided to not fix it for 2.3.0 so be aware of this problem (or
something similar)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Bernd Fondermann <be...@googlemail.com>.
But we are
On 9/27/06, Norman Maurer <nm...@byteaction.de> wrote:
> Joachim Draeger schrieb:
> > Am Dienstag, den 26.09.2006, 16:45 -0400 schrieb Noel J. Bergman:
> >
> >
> >>> to simplify the website build and to include 2.2.0 and 2.3.0 docs
> >>>
> >> We can update our web site indepedendently of the release cycle for the
> >> product.
> >>
> >
> > But it would be very, very good to have the website in the best possible
> > condition when we release. (Of course we are software developers and not
> > web-designers (but not to forget to say that it looks quite good at the
> > moment))
> > In the time-frame, when the release gets announced I hope for some
> > bigger interest. IMO, the chance is good to get mentioned in the related
> > new tickers. The first impression potential new users get is very
> > important.
> > I know, I act the same: Read an interesting article, klick the link to
> > the project website and decide whether it's worth to download and give
> > it a chance.
> >
> > Joachim
>
> I agree. We should not release until the website is ready. Btw, i don't
> think this will block us, because Stefano finished almost..
As I see it we are not only having changes to the documentation but to
the code base as well, which leads us to RC4. RC4 could have been
RC1... for 2.3.1.
We will always have bugs, even known bugs. So this should not be the
_only_ criteria for not releasing. It has to be weighted against the
nasty old bugs we have in the current stable release and if our user
base would be better off with the new ones instead of the old ones.
;-)
The fixes we are doing now (docs int 2.3-branch, serial nos, mime
conversion disabling) are all neccessary, but should they hold the
release? Remember, we could publish a "known problems" documentation,
too.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Norman Maurer <nm...@byteaction.de>.
Bernd Fondermann schrieb:
> But we are
>
> On 9/27/06, Norman Maurer <nm...@byteaction.de> wrote:
>> Joachim Draeger schrieb:
>> > Am Dienstag, den 26.09.2006, 16:45 -0400 schrieb Noel J. Bergman:
>> >
>> >
>> >>> to simplify the website build and to include 2.2.0 and 2.3.0 docs
>> >>>
>> >> We can update our web site indepedendently of the release cycle
>> for the
>> >> product.
>> >>
>> >
>> > But it would be very, very good to have the website in the best
>> possible
>> > condition when we release. (Of course we are software developers
>> and not
>> > web-designers (but not to forget to say that it looks quite good at
>> the
>> > moment))
>> > In the time-frame, when the release gets announced I hope for some
>> > bigger interest. IMO, the chance is good to get mentioned in the
>> related
>> > new tickers. The first impression potential new users get is very
>> > important.
>> > I know, I act the same: Read an interesting article, klick the link to
>> > the project website and decide whether it's worth to download and give
>> > it a chance.
>> >
>> > Joachim
>>
>> I agree. We should not release until the website is ready. Btw, i don't
>> think this will block us, because Stefano finished almost..
>
> As I see it we are not only having changes to the documentation but to
> the code base as well, which leads us to RC4. RC4 could have been
> RC1... for 2.3.1.
>
> We will always have bugs, even known bugs. So this should not be the
> _only_ criteria for not releasing. It has to be weighted against the
> nasty old bugs we have in the current stable release and if our user
> base would be better off with the new ones instead of the old ones.
> ;-)
>
> The fixes we are doing now (docs int 2.3-branch, serial nos, mime
> conversion disabling) are all neccessary, but should they hold the
> release? Remember, we could publish a "known problems" documentation,
> too.
>
> Bernd
Well im not feel good to release with known bugs.. So im -0 to release
without fixes.
Bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Norman Maurer <nm...@byteaction.de>.
Joachim Draeger schrieb:
> Am Dienstag, den 26.09.2006, 16:45 -0400 schrieb Noel J. Bergman:
>
>
>>> to simplify the website build and to include 2.2.0 and 2.3.0 docs
>>>
>> We can update our web site indepedendently of the release cycle for the
>> product.
>>
>
> But it would be very, very good to have the website in the best possible
> condition when we release. (Of course we are software developers and not
> web-designers (but not to forget to say that it looks quite good at the
> moment))
> In the time-frame, when the release gets announced I hope for some
> bigger interest. IMO, the chance is good to get mentioned in the related
> new tickers. The first impression potential new users get is very
> important.
> I know, I act the same: Read an interesting article, klick the link to
> the project website and decide whether it's worth to download and give
> it a chance.
>
> Joachim
I agree. We should not release until the website is ready. Btw, i don't
think this will block us, because Stefano finished almost..
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: When do we ship?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano wrote:
> In roadmap for the 2.3.0 final we have:
> Fix m2 projects to not lookup dependencies on ibiblio
Huh? Why do we care about Maven 2 for 2.3.0? I don't care about Maven 2
for anything ever, but it certainly should not be a blocker for JAMES 2.3.0.
> to simplify the website build and to include 2.2.0 and 2.3.0 docs
We can update our web site indepedendently of the release cycle for the
product.
> Move server-site documents from james/server repository to
> james/site/server repository
JAMES 2.3 is a product release, and should not be blocked on anything
related to Maven repositories.
> Invalid (outdated) urls in config files.
> http://issues.apache.org/jira/browse/JAMES-626
Fair enough. Non-critical.
> We would also have more feedback on the leak issue opened by Noel
The bug exists. I have no time right now to track it down, and everytime I
have tried, the JVMs have hung early. :-\
> Either we decide this is not confirmed and close it until we can
> confirm it, or we investigate on the cause of the leak.
I won't close something that exists. And no one else seems to have either
the time or awareness of the problem to look. Whatever is leaking, and I
still see it, is slow enough that it can be worked around. I have so far
not found any evidence to suggest that it is related to volume. So I'd
release with a caveat.
> one of my production james (something near rc2) is up since 1 month
> and with a default Xmx (64MB) and I had no OOM (this is an almost
> default 2.3 configuration with file repositories).
I wish I could say the same. :-(
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> I've been unable to test RC3 and, as a consequence, I did not vote on it.
> So I feel I am not in a comfortable position to put up a vote.
> But, seriously, why wait any longer?
RC3 has been published
(http://people.apache.org/dist/james/server/binaries/) even if we,
maybe, never announced it! We at least changed the homepage to reflect
the news.
Are you talking about the final release?
In roadmap for the 2.3.0 final we have:
Fix m2 projects to not lookup dependencies on ibiblio, to simplify the
website build and to include 2.2.0 and 2.3.0 docs
- http://issues.apache.org/jira/browse/JAMES-634
Move server-site documents from james/server repository to
james/site/server repository
- http://issues.apache.org/jira/browse/JAMES-618
Invalid (outdated) urls in config files.
- http://issues.apache.org/jira/browse/JAMES-626
I think I'll take care of the 3 above in the next couple of days: I'm
waiting to close the vote about the m2 site changes (I'll close it later
today by lazy consensus).
We would also have more feedback on the leak issue opened by Noel: I'm
not fine releasing a 2.3.0 final with an unknown leak issue opened in
JIRA. Either we decide this is not confirmed and close it until we can
confirm it, or we investigate on the cause of the leak. Until now we
don't know if the leak is confirmed to be in james or is confirmed to be
somewhere else (JVM/connectorj). PS: one of my production james
(something near rc2) is up since 1 month and with a default Xmx (64MB)
and I had no OOM (this is an almost default 2.3 configuration with file
repositories).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Bernd Fondermann <be...@googlemail.com>.
Agreed, it would be cool to have the web site finished for the
release, at least for the release announcement.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: When do we ship?
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Bernd Fondermann wrote:
>> I've been unable to test RC3 and, as a consequence, I did not vote on
>> it.
>> So I feel I am not in a comfortable position to put up a vote.
>> But, seriously, why wait any longer?
>
> RC3 has been published
> (http://people.apache.org/dist/james/server/binaries/) even if we,
> maybe, never announced it! We at least changed the homepage to reflect
> the news.
>
> Are you talking about the final release?
>
> In roadmap for the 2.3.0 final we have:
>
> Fix m2 projects to not lookup dependencies on ibiblio, to simplify the
> website build and to include 2.2.0 and 2.3.0 docs
> - http://issues.apache.org/jira/browse/JAMES-634
>
> Move server-site documents from james/server repository to
> james/site/server repository
> - http://issues.apache.org/jira/browse/JAMES-618
>
> Invalid (outdated) urls in config files.
> - http://issues.apache.org/jira/browse/JAMES-626
>
> I think I'll take care of the 3 above in the next couple of days: I'm
> waiting to close the vote about the m2 site changes (I'll close it
> later today by lazy consensus).
>
> We would also have more feedback on the leak issue opened by Noel: I'm
> not fine releasing a 2.3.0 final with an unknown leak issue opened in
> JIRA. Either we decide this is not confirmed and close it until we can
> confirm it, or we investigate on the cause of the leak. Until now we
> don't know if the leak is confirmed to be in james or is confirmed to
> be somewhere else (JVM/connectorj). PS: one of my production james
> (something near rc2) is up since 1 month and with a default Xmx (64MB)
> and I had no OOM (this is an almost default 2.3 configuration with
> file repositories).
>
> Stefano
>
I also have an rc2 running on one server till almost 3 weeks without a
OOM. It use mysql and use -Xmx5m -Xms2m. thats why i want to close it
as "not reproducable".
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org