[james-project] branch master updated: JAMES-2826 Since java 9 there's a release parameter that do exactly what animal-sniffer does
This is an automated email from the ASF dual-hosted git repository. matthieu pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/james-project.git The following commit(s) were added to refs/heads/master by this push: new 0ff5716 JAMES-2826 Since java 9 there's a release parameter that do exactly what animal-sniffer does 0ff5716 is described below commit 0ff5716977ba6446f2044036087569fc94da682c Author: Matthieu Baechler AuthorDate: Mon Jul 8 18:09:33 2019 +0200 JAMES-2826 Since java 9 there's a release parameter that do exactly what animal-sniffer does The idea is to leverage a java > 8 compiler to gain greater compile speed, to replace the slow animal-sniffer plugin and to still generate artifacts for Java 8 --- dockerfiles/compilation/java-8/Dockerfile | 16 pom.xml | 28 ++-- server/container/spring/pom.xml | 15 --- server/data/data-jpa/pom.xml | 10 -- server/queue/queue-file/pom.xml | 15 --- 5 files changed, 10 insertions(+), 74 deletions(-) diff --git a/dockerfiles/compilation/java-8/Dockerfile b/dockerfiles/compilation/java-8/Dockerfile index c496289..7d27c22 100644 --- a/dockerfiles/compilation/java-8/Dockerfile +++ b/dockerfiles/compilation/java-8/Dockerfile @@ -2,19 +2,19 @@ # # VERSION 1.0 -FROM openjdk:8u171-jdk +FROM adoptopenjdk:11-jdk-hotspot ENV GIT_VERSION 1:2.11.0-3 -# Install Maven -WORKDIR /root -RUN wget https://archive.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz -RUN tar -xvf apache-maven-3.5.4-bin.tar.gz -RUN ln -s /root/apache-maven-3.5.4/bin/mvn /usr/bin/mvn - # Install git RUN apt-get update -RUN apt-get install -y git +RUN apt-get install -y git wget unzip + +# Install Maven +WORKDIR /root +RUN wget https://archive.apache.org/dist/maven/maven-3/3.6.1/binaries/apache-maven-3.6.1-bin.tar.gz +RUN tar -xvf apache-maven-3.6.1-bin.tar.gz +RUN ln -s /root/apache-maven-3.6.1/bin/mvn /usr/bin/mvn # Copy the script COPY compile.sh /root/compile.sh diff --git a/pom.xml b/pom.xml index 762f9fd..f491cad 100644 --- a/pom.xml +++ b/pom.xml @@ -576,7 +576,7 @@ otherwise the set values are used by default. --> UTF-8 -1.8 +8 1.9-SNAPSHOT
Re: project artifact needs a release?
Hi Ioan, We need to follow the normal release processs (with min 3 days vote). Thx, Eric On 29/12/2012 03:50, Ioan Eugen Stan wrote: Hello, I've updated the plugin versions to latest, some info and bumped the parent apache:apache to version 12. I wish to cut release 1.8.2 for project. Should this follow the normal 3 day vote procedure? It's not a user facing release. It only affects the way we develop. Cheers, - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
project artifact needs a release?
Hello, I've updated the plugin versions to latest, some info and bumped the parent apache:apache to version 12. I wish to cut release 1.8.2 for project. Should this follow the normal 3 day vote procedure? It's not a user facing release. It only affects the way we develop. Cheers, -- Ioan Eugen Stan / CTO / http://axemblr.com - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[JAMES 3.0] Are there any timelines identified for a release ?
Hi, I would like to know if a specific timeline has been identified for the JAMES 3.0 release ? Regards, Radhakrishnan P.S: I had posted this question on the server-user mailing list. However, I sent the question without subscribing to the list. Also I was told this is the right place to ask the question, hence the cross-post.
Re: Something new about a release?
On 7/24/08, Toni Lamar <[EMAIL PROTECTED]> wrote: > > Is there anything new regarding a relase (of any type) for James ? What type of release were you looking for? And from which codestream? > Last time I asked about a release was more than one year ago, and the main > problem seemed to be the consensus :(. We still struggle for consensus and need more volunteers who are interested in working on releases. I had hoped that we would have released jsieve, mime4j, mailet-API and the crypto mailets by now but each effort has stalled for one reason or another. Norman has mooted another 2.x. > Doesn't Apache.org have solutions for such "pat(stalemate)" situations? Apache uses a community based development model. JAMES needs more active contributors to break the deadlock. Robert > > Thnx. > > -- > View this message in context: > http://www.nabble.com/Something-new-about-a-release--tp18637234p18637234.html > Sent from the James - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Something new about a release?
Is there anything new regarding a relase (of any type) for James ? Last time I asked about a release was more than one year ago, and the main problem seemed to be the consensus :(. Doesn't Apache.org have solutions for such "pat(stalemate)" situations? Thnx. -- View this message in context: http://www.nabble.com/Something-new-about-a-release--tp18637234p18637234.html Sent from the James - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Todos for a Release Candidate
Bernd Fondermann wrote: I don't think the latest alpha qualifies as RC. We should look into these topics first: a. More backports from TRUNK, like the removed ristretto dependency. +1 IIRC I fixed newlines issues in trunk after the branch so the test files are not "comparable" and future backporting would be more difficult if we don't merge back. b. add commons-net.jar to tools/lib +1 c. determine how to distribute junit.jar +0 Don't know anything about it, but most people having ant should already have junit also. => all these are related to running unit tests d. resolve the TEMPORARY DEFAULT to filedb/derby in the vanilla config +1 . I think that as soon as our betas will be used by much more people we'll find out wether derby can be used by default (as we hope) or not. I am looking into a.& b the next days. Bernd Thank you, Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Todos for a Release Candidate
I don't think the latest alpha qualifies as RC. We should look into these topics first: a. More backports from TRUNK, like the removed ristretto dependency. b. add commons-net.jar to tools/lib c. determine how to distribute junit.jar => all these are related to running unit tests d. resolve the TEMPORARY DEFAULT to filedb/derby in the vanilla config I am looking into a.& b the next days. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Javamail problems (Re: Pushing towards a RELEASE)
I just posted the issues to the javamail-interest mailing list. Let's see if they confirm this or not. Stefano Markus Kühn wrote: "Stefano Bagnara" <[EMAIL PROTECTED]> Markus Kühn wrote: So the bug is that if you turn 8bit support on you have to check if an incoming message as encoding information? And is this bug confirmed by Sun? The setContent bug is in their bugparade "in progress." The bug I talk about is not the same but similar. It is "correct" code in SMTPTransport that simply hit the "in progress" bug: the proposed a workaround for the bug, the should use it in their code. I have not found this SMTPTransport bug reported in their bug db. ALso I had no time to write a unittest and report it. Any volounteer is welcome! The bug is: - read a 7bit quoted-printable message from a stream - send it via SMTPtransport to a server supporting 8bitmime and having activated 8bitmime support in the SMTPSession. You receive a message with headers updated to report 8bit content, but content unaltered and still containing the quoted-printable stuff. Furthermore if you read an 8bitmime message from a stream and you sent it via STMPTransport to a server not supporting 8bitmime it is not converted to 7bitmime. So we have 2 bugs here. I have not reported the bug almost for time reasons but also because the main bug is in their db since 2001 and it is still "in progress"... I think the encoding issue and missing encoding information (now bug nr. 3) could be considered as "bugs" themselves, so you should report them. I am curious about their point of view. Markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
- Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]> Markus Kühn wrote: So the bug is that if you turn 8bit support on you have to check if an incoming message as encoding information? And is this bug confirmed by Sun? The setContent bug is in their bugparade "in progress." The bug I talk about is not the same but similar. It is "correct" code in SMTPTransport that simply hit the "in progress" bug: the proposed a workaround for the bug, the should use it in their code. I have not found this SMTPTransport bug reported in their bug db. ALso I had no time to write a unittest and report it. Any volounteer is welcome! The bug is: - read a 7bit quoted-printable message from a stream - send it via SMTPtransport to a server supporting 8bitmime and having activated 8bitmime support in the SMTPSession. You receive a message with headers updated to report 8bit content, but content unaltered and still containing the quoted-printable stuff. Furthermore if you read an 8bitmime message from a stream and you sent it via STMPTransport to a server not supporting 8bitmime it is not converted to 7bitmime. So we have 2 bugs here. I have not reported the bug almost for time reasons but also because the main bug is in their db since 2001 and it is still "in progress"... I think the encoding issue and missing encoding information (now bug nr. 3) could be considered as "bugs" themselves, so you should report them. I am curious about their point of view. Markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Markus Kühn wrote: So the bug is that if you turn 8bit support on you have to check if an incoming message as encoding information? And is this bug confirmed by Sun? The setContent bug is in their bugparade "in progress." The bug I talk about is not the same but similar. It is "correct" code in SMTPTransport that simply hit the "in progress" bug: the proposed a workaround for the bug, the should use it in their code. I have not found this SMTPTransport bug reported in their bug db. ALso I had no time to write a unittest and report it. Any volounteer is welcome! The bug is: - read a 7bit quoted-printable message from a stream - send it via SMTPtransport to a server supporting 8bitmime and having activated 8bitmime support in the SMTPSession. You receive a message with headers updated to report 8bit content, but content unaltered and still containing the quoted-printable stuff. Furthermore if you read an 8bitmime message from a stream and you sent it via STMPTransport to a server not supporting 8bitmime it is not converted to 7bitmime. So we have 2 bugs here. I have not reported the bug almost for time reasons but also because the main bug is in their db since 2001 and it is still "in progress"... Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
- Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]> 1) There are NPE problems when you have messages with no encoding 2) It furthermore changes the headers of mime parts without calling a new setContent. Once you workaround to the enconding issue by manually checking that each message has an encoding, you will find that output messages have updated headers but UNCHANGED contents. So you end up sending quotedprintable content with 8bit/text-plain headers (corrupted) and viceversa. All works fine when you create the message from scratch and not from inputstreams. So the bug is that if you turn 8bit support on you have to check if an incoming message as encoding information? And is this bug confirmed by Sun? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Apparently Sun is not able to workaround to its own bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403733 When we have control of the getContent/setContent (see AddHeader mailet) we already have a workaround for this, but this time the problem is in the SMTPTransport and we cannot do much for that. Create a new MimeMessage from an 8bit file using a sharedinputstream (not sure this happens with all inputstreams or only sharedinputstreams, I don't remember). Send it to an smtp server not supporting 8bitmime. Create a new MimeMessage from a 7bit file using an inputstream. Send it to an smtp server supporting 8bitmime and activating the 8bitmime support in the mail session. If you want to investigate on this look at the SMTPTransport.convertTo8bit method from javamail 1.3.2 (I have not checked 1.4 sources yet). 1) There are NPE problems when you have messages with no encoding 2) It furthermore changes the headers of mime parts without calling a new setContent. Once you workaround to the enconding issue by manually checking that each message has an encoding, you will find that output messages have updated headers but UNCHANGED contents. So you end up sending quotedprintable content with 8bit/text-plain headers (corrupted) and viceversa. All works fine when you create the message from scratch and not from inputstreams. Stefano Markus Kühn wrote: - Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]> After the release of James 2.3.0a1 people reported problem with mail sent by james to other mail servers (supporting 8bitmime). I investigated the bug and found a javamail bug. So I removed the 8bitmime support from RemoteDelivery. Do you now know that it is a javamail bug or is it still an assumption? Javamail tends to shift responsibility to the user (see header encoding). Markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
- Original Message - From: "Stefano Bagnara" <[EMAIL PROTECTED]> After the release of James 2.3.0a1 people reported problem with mail sent by james to other mail servers (supporting 8bitmime). I investigated the bug and found a javamail bug. So I removed the 8bitmime support from RemoteDelivery. Do you now know that it is a javamail bug or is it still an assumption? Javamail tends to shift responsibility to the user (see header encoding). Markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Unfortunately I cannot broadcast my feelings and confidence ;-) Did you (Vincenzo, Serge, Noel) tried the current trunk or is it only a feeling? I understand that it is easier to know if the code is "production ready" or not when you are the one that did the changes, but I also think I cannot do much more than writing new code and test things I use in my real world applications. I mostly know when I commit new code if that could cause problem, but this is not always the case. I cite 2 things I reverted for the next alpha 2 release: 1) 8bitmime stuff: From a conceptual level it was already supported. I enabled things locally and started a few tests. I found problems and I added patch and put them in my (personal) server. It worked fine so I committed it. After the release of James 2.3.0a1 people reported problem with mail sent by james to other mail servers (supporting 8bitmime). I investigated the bug and found a javamail bug. So I removed the 8bitmime support from RemoteDelivery. We have then received further reports and I found we hit the same javamail bug when we accept mail in 8bit and try to send it as 7bit. So this is a javamail bug. I updated the bug status to blocker to remember that we cannot make a release with that code while I did more tests. I always thought this was an easy patch and with no possible troubles but I was wrong. 2) JDBC store "streaming". I wrote the code to read and write streams from db, I wrote tests and I put the code in production in my personal server (against mysql4.1 and using connectorj5alpha). It worked. I knew that the change was critical so I decided to commit it in 2 steps: first the writing code, then the reading code. I also wrote a message to the server-dev list to let people know that the trunk was not production-ready because the new code was experimental. We received 2 bug reports: one was related to dbfile (i didn't test dbfiles) and fixed asap, I was not able to reproduce the other. I started working with Norman to find out the problem because no one else was reporting the bug but I have been not able to reproduce the problem. No one else reported the problem (has anyone else tried it??) but I decided to mark it as a blocker. I also added an option to reenable the code because if we want to solve the OutOfMemory issues this is the only way we can follow. Noel wrote he wanted to push a release, so I applied patches (revert/workaround) to avoid the 2 issues so we are now able to test the code for this alpha 2 release. The point is: we don't have 100% test coverage and no one is willing to write all these tests, so the only way to be confident about the code is ask with people working on the code what is the current status and test it personally. So download the current trunk, test it and let's release a 2.3.0a2. If you have any suggestion to improve this workflow or any hint on to avoid the above problems I'm happy to hear! James 2.3.0a1 has been a good release if you consider it was an alpha: we had only one major bug (8bitmime). Personally I feel happier with the current trunk than with the 2.2.0 final. We solved at least 2 critical message corruption bugs from 2.2.0. Stefano PS: I'm going to put current trunk in production tomorrow. If I don't find further problem I'll tag it as 2.3.0a2 and start the vote for the release, so you can test it and vote. Vincenzo Gianferrari Pini wrote: Noel J. Bergman wrote: What does it say that neither Serge nor I are running the current code in production? I normally ran trunk in production, but there were so many key changes on top of one another that I was no longer comfortable putting trunk into production. I feel the same. The version I have in production is trunk as of June 24, 2005 plus my changes to the bayesian analyser. In the past I always tried to run the current code in production. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Am Donnerstag, den 04.05.2006, 13:28 +0200 schrieb Vincenzo Gianferrari Pini: > no longer comfortable putting trunk into > >production. > > > > > I feel the same. The version I have in production is trunk as of June > 24, 2005 plus my changes to the bayesian analyser. > In the past I always tried to run the current code in production. > We use current trunk in production without a problem at the moment bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Pushing towards a RELEASE
Noel J. Bergman wrote: What does it say that neither Serge nor I are running the current code in production? I normally ran trunk in production, but there were so many key changes on top of one another that I was no longer comfortable putting trunk into production. I feel the same. The version I have in production is trunk as of June 24, 2005 plus my changes to the bayesian analyser. In the past I always tried to run the current code in production. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
Am Montag, den 01.05.2006, 01:37 +0200 schrieb Norman Maurer: > Am Sonntag, den 30.04.2006, 18:15 -0400 schrieb Noel J. Bergman: > > Norman Maurer wrote: > > > > > Maybe your right. We should but out a 2.3 release and focus a 2.4 > > > release to add this changes. > > > > Sure. I would have no problem putting out a real Release every 60-90 days, > > or even monthly, if we had a basis for them. Especially now that we have > > formal testing in place, rather than relying on ad-hoc testing and a few > > production servers. > > I think a new "stable" release every 6 month will be enough.. Maybe a > bugfix release every 1 - 2 month should be focused. > > > > > There are more features which are really intressting we should add in > > > future. > > > > > 1. Maildir support > > > > Yes. But this is an optional drop-in, so bugs would not effect most > > mainstream users, just as bugs in the mbox support would effect few users. > > > Right. > > > 2. SPF Support ( after Stefano and I are finish with JSpf > > > > We should get this into SVN, and develop it there, not put it in when > > finished. > > A sideproject should be created for this (like jsieve) cause its > independent of james at all.. I forget to say that this is not possible for me at the moment without commit rights at all for this JSpf if it will be created. bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Pushing towards a RELEASE
Am Sonntag, den 30.04.2006, 18:15 -0400 schrieb Noel J. Bergman: > Norman Maurer wrote: > > > Maybe your right. We should but out a 2.3 release and focus a 2.4 > > release to add this changes. > > Sure. I would have no problem putting out a real Release every 60-90 days, > or even monthly, if we had a basis for them. Especially now that we have > formal testing in place, rather than relying on ad-hoc testing and a few > production servers. I think a new "stable" release every 6 month will be enough.. Maybe a bugfix release every 1 - 2 month should be focused. > > > There are more features which are really intressting we should add in > > future. > > > 1. Maildir support > > Yes. But this is an optional drop-in, so bugs would not effect most > mainstream users, just as bugs in the mbox support would effect few users. > Right. > > 2. SPF Support ( after Stefano and I are finish with JSpf > > We should get this into SVN, and develop it there, not put it in when > finished. A sideproject should be created for this (like jsieve) cause its independent of james at all.. > > And this might work better with the next item being done at the same time: > > > 3. SMTPHandler chain refactor > > Absolutely. Once 2.3 is out, this would be high on my list, too. This > would be the major mainstream change that I would want to see happening for > 2.4. > Nice to hear this. > > 4. IMAP ( I think this is the feature which most users really miss now.. > > Me too) > > Another thing that can be done on the side, without effecting most users, > although the *core* piece --- the mail repository interface --- will be > mainstream. I agree not sure if its possible without changes on the interface. bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Pushing towards a RELEASE
Norman Maurer wrote: > Maybe your right. We should but out a 2.3 release and focus a 2.4 > release to add this changes. Sure. I would have no problem putting out a real Release every 60-90 days, or even monthly, if we had a basis for them. Especially now that we have formal testing in place, rather than relying on ad-hoc testing and a few production servers. > There are more features which are really intressting we should add in > future. > 1. Maildir support Yes. But this is an optional drop-in, so bugs would not effect most mainstream users, just as bugs in the mbox support would effect few users. > 2. SPF Support ( after Stefano and I are finish with JSpf We should get this into SVN, and develop it there, not put it in when finished. And this might work better with the next item being done at the same time: > 3. SMTPHandler chain refactor Absolutely. Once 2.3 is out, this would be high on my list, too. This would be the major mainstream change that I would want to see happening for 2.4. > 4. IMAP ( I think this is the feature which most users really miss now.. > Me too) Another thing that can be done on the side, without effecting most users, although the *core* piece --- the mail repository interface --- will be mainstream. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
Am Sonntag, den 30.04.2006, 09:00 -0400 schrieb Noel J. Bergman: > Stefano Bagnara wrote: > > > I don't agree: imho we already have a stable release out: 2.2.0. > > Yes, but consider the many enhancements, changes and bugfixes since that > release that are based upon "feedback and contributions [of] features people > need." If we continue to delay releasing those, might not "people [switch] > to different mail servers", too? > Maybe your right. We should but out a 2.3 release and focus a 2.4 release to add this changes. > > I would prefer to have a few more alpha cycle and possibly introduce new > > features before 2.3.0 but I'll not be -1 on putting out a release on the > > current feature-set. > > Right, that's what I'm saying. Let's focus on getting a solid release out, > and then continue with feature changes. > > > If we want to feature freeze here for 2.3.0 then I think we should > > create a branch so that we can also keep going on with new code. > > We can do that, and it is a good practice, but as you note, "no one here > work on James as a full time "priority" job", so I am a bit concerned that > efforts will continue to focus on adding features to another branch rather > than on putting out a release. I'm asking that we as a community make > getting a solid release out a priority. > > And, as Serge notes, by incrementally adding features to a solid release, > more people will be willing to test it, which helps development. What does > it say that neither Serge nor I are running the current code in production? > I normally ran trunk in production, but there were so many key changes on > top of one another that I was no longer comfortable putting trunk into > production. If we can get into a more frequent release cycle, where we are > not changing too many things at once, I believe that we'll have better > pickup. There are more features which are really intressting we should add in future. 1. Maildir support 2. SPF Support ( after Stefano and I are finish with JSpf 3. SMTPHandler chain refactor 4. IMAP ( I think this is the feature which most users really miss now.. Me too) bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Pushing towards a RELEASE
Stefano Bagnara wrote: > I don't agree: imho we already have a stable release out: 2.2.0. Yes, but consider the many enhancements, changes and bugfixes since that release that are based upon "feedback and contributions [of] features people need." If we continue to delay releasing those, might not "people [switch] to different mail servers", too? > I would prefer to have a few more alpha cycle and possibly introduce new > features before 2.3.0 but I'll not be -1 on putting out a release on the > current feature-set. Right, that's what I'm saying. Let's focus on getting a solid release out, and then continue with feature changes. > If we want to feature freeze here for 2.3.0 then I think we should > create a branch so that we can also keep going on with new code. We can do that, and it is a good practice, but as you note, "no one here work on James as a full time "priority" job", so I am a bit concerned that efforts will continue to focus on adding features to another branch rather than on putting out a release. I'm asking that we as a community make getting a solid release out a priority. And, as Serge notes, by incrementally adding features to a solid release, more people will be willing to test it, which helps development. What does it say that neither Serge nor I are running the current code in production? I normally ran trunk in production, but there were so many key changes on top of one another that I was no longer comfortable putting trunk into production. If we can get into a more frequent release cycle, where we are not changing too many things at once, I believe that we'll have better pickup. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Stefano Bagnara wrote: I don't agree: imho we already have a stable release out: 2.2.0. of course. i correct myself: we should focus on putting out official stable releases on a regular basis. We'll get feedback and contributions if we add features people need, otherwise people will switch to different mail servers. and the only way to get people to use these features are final releases. what turns people away is a project seemingly dead from that perspective. I would prefer to have a few more alpha cycle and possibly introduce new features before 2.3.0 but I'll not be -1 on putting out a release on the current feature-set. If we want to feature freeze here for 2.3.0 then I think we should create a branch so that we can also keep going on with new code. About "release dates" I don't think we can decide a release date: no one here work on James as a full time "priority" job, so we can release when things are ready. If you feel the core was better 4 months ago we can even branch the code from 4 months ago and release from there, but please don't slow down the *few* developing efforts out there. you are doing a great job applying patches, writing large chunks of code yourself, supporting users. (thank you very much, by the way!) beyond that, i have the feeling that development is slowed down more than accelerated by not having an official release out for month. there is no need for going back 4 months, AFAICT. of course we should not release if not ready! but release preparation needs some extra efforts which need to be focused into a shorter timespan. 8 weeks until ApacheCon seem realistic to me. it's a goal not a burden. Bernd Stefano Bernd Fondermann wrote: Noel J. Bergman: But if we don't adopt some discipline on what changes we do, we will never get a release out. I was hoping to do a release many months ago, but a flurry of changes to the core wiped out all chance of that happening. Now, with a lot of work from Bernd and Stefano (and backing out some changes), the core is starting to feel stable again, and we can look forward to a release. But not if we keep changing things. Agreed. As an Apache project we should put more focus one the user community in terms of putting out stable releases. We would get back feedback and contributions. Why not aim for ApacheCon Europe 06 as a release date for 2.3? Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
I don't agree: imho we already have a stable release out: 2.2.0. We'll get feedback and contributions if we add features people need, otherwise people will switch to different mail servers. I would prefer to have a few more alpha cycle and possibly introduce new features before 2.3.0 but I'll not be -1 on putting out a release on the current feature-set. If we want to feature freeze here for 2.3.0 then I think we should create a branch so that we can also keep going on with new code. About "release dates" I don't think we can decide a release date: no one here work on James as a full time "priority" job, so we can release when things are ready. If you feel the core was better 4 months ago we can even branch the code from 4 months ago and release from there, but please don't slow down the *few* developing efforts out there. Stefano Bernd Fondermann wrote: Noel J. Bergman: But if we don't adopt some discipline on what changes we do, we will never get a release out. I was hoping to do a release many months ago, but a flurry of changes to the core wiped out all chance of that happening. Now, with a lot of work from Bernd and Stefano (and backing out some changes), the core is starting to feel stable again, and we can look forward to a release. But not if we keep changing things. Agreed. As an Apache project we should put more focus one the user community in terms of putting out stable releases. We would get back feedback and contributions. Why not aim for ApacheCon Europe 06 as a release date for 2.3? Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
On 4/30/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote: Agreed. As an Apache project we should put more focus one the user community in terms of putting out stable releases. We would get back feedback and contributions. Yes, and add this... frequent releases can keep us in a position to test large issues that come up. We're not going to be able to test the DNS cache leak code until we get to a release. :) -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Noel J. Bergman wrote: Norman Maurer wrote: Noel J. Bergman: But if we don't adopt some discipline on what changes we do, we will never get a release out. I was hoping to do a release many months ago, but a flurry of changes to the core wiped out all chance of that happening. Now, with a lot of work from Bernd and Stefano (and backing out some changes), the core is starting to feel stable again, and we can look forward to a release. But not if we keep changing things. Agreed. As an Apache project we should put more focus one the user community in terms of putting out stable releases. We would get back feedback and contributions. Why not aim for ApacheCon Europe 06 as a release date for 2.3? Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
Norman Maurer wrote: > Noel J. Bergman: > > Stefano Bagnara wrote: > > > I would like to also change the smtp command handler code > > > before a final release, otherwise we will have to mantain > > > 2 totally different fastfail codes. > > I disagree. We document this as INTERNAL ONLY, we do NOT > > encourage people to write new ones, and warn them that the > > API will change, we get the product shipping, and THEN we > > clean up the API. Unless there is something in the current > > API that blocks OUR ability to ship a release. > But a "better and more pluggable" smtp handler code whould be > also a very nice think. Yes it would. High on my list. I was going to start work on something in a branch, and Stefano also has ideas, so I'd be happy for us to set off a branch to collaborate on such changes. But if we don't adopt some discipline on what changes we do, we will never get a release out. I was hoping to do a release many months ago, but a flurry of changes to the core wiped out all chance of that happening. Now, with a lot of work from Bernd and Stefano (and backing out some changes), the core is starting to feel stable again, and we can look forward to a release. But not if we keep changing things. > If we want to not any new featues or improvements yet we should > write a new roadmap for next changes and whats the main goals. I do not believe that we have too much, if any, disagreement amongst ourselves on changes and goals (other than my dislike for Maven ;-)). I'm just saying that we should consolidate a release first. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
Am Freitag, den 28.04.2006, 21:18 -0400 schrieb Noel J. Bergman: > Stefano Bagnara wrote: > > > All the configurations/components introduced in 2.3.0a1 needs to be > > reviewed and possibly renamed/moved/changed. > > That's fair. > > > I would like to also change the smtp command handler code before a final > > release, otherwise we will have to mantain 2 totally different fastfail > > codes. > > I disagree. We document this as INTERNAL ONLY, we do NOT encourage people > to write new ones, and warn them that the API will change, we get the > product shipping, and THEN we clean up the API. Unless there is something > in the current API that blocks OUR ability to ship a release. > Thats also a good point. But a "better and more pluggable" smtp handler code whould be also a very nice think. It whould be more pluggable at all and when adding new features the core solid code will not affected. So also the testing and fixing bug will be maybe a bit easier cause if the bug only happen on the new "pluggin" you know were to search and can also exlude only this and notify the developer of this code . > When we provide the API for external use, we will also want to add a loader > so that people can register handler packages. > > > I would also like to introduce the command handler pattern to pop3 and > > remotemanager: this would add a great level of extensibility to James. > > Same as above. I agree with wanting to add functionality, but we first need > to consolidate what we have, and get a solid release out, and THEN add > features. > If we want to not any new featues or improvements yet we should write a new roadmap for next changes and whats the main goals. bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Pushing towards a RELEASE
Stefano Bagnara wrote: > All the configurations/components introduced in 2.3.0a1 needs to be > reviewed and possibly renamed/moved/changed. That's fair. > I would like to also change the smtp command handler code before a final > release, otherwise we will have to mantain 2 totally different fastfail > codes. I disagree. We document this as INTERNAL ONLY, we do NOT encourage people to write new ones, and warn them that the API will change, we get the product shipping, and THEN we clean up the API. Unless there is something in the current API that blocks OUR ability to ship a release. When we provide the API for external use, we will also want to add a loader so that people can register handler packages. > I would also like to introduce the command handler pattern to pop3 and > remotemanager: this would add a great level of extensibility to James. Same as above. I agree with wanting to add functionality, but we first need to consolidate what we have, and get a solid release out, and THEN add features. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
> Unfortunately few people (just Norman and me, probably) is testing the > current trunk so it takes a lot to collect bugreports and to try to > find the real problems and possible workarounds. I can do some limited bench testing, but I am not yet willing to put trunk into production. Perhaps with some of the recent changes I saw fly by, I will be willing to give it a shot at such time as I can also babysit the server. > I think that a 2.3.0a2 would really help if people will test it > and try to work more on that issues before 2.3.0a3. I'm perfectly happy to post an alpha build whenever we're ready to declare one. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pushing towards a RELEASE
Stefano Bagnara wrote: > Imho there are many features that should be changed before adding them > to the final 2.3.0 release. Let's add them to 2.4, 2.5, whatever. I feel a keen need for a stable (as in reliable) release, and then we can make changes. > I think that the current trunk is almost ready for an alpha 2 release. > We could schedule the next release for the end of the next week > can you take care of the release? (we should remember to tag the > code we release, this time) Yes, to both. I should have time to do that on Friday afternoon, baring any unforeseen complications when I see the oral surgeon on Friday morning (just a follow-up). We'll want to vote first, of course, but we have from now until Thursday to do some sanity checking, clean up any minor nits, and vote. > About the stability issue I think we talked about this in past: if we > want to feature freeze we should branch. As above, when I say stable, I don't mean that the features are frozen. I mean that the code base is reliable and solid. We have made enough core changes to key areas that I have not had that comfort level. The need to revert some changes seems to corroborate my feeling. But I am quite pleased that we now have so much better testing that we can more rapidly validate changes. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Bernd Fondermann wrote: Stefano Bagnara wrote: I don't think that the current James trunk is ready to be feature freezed. Imho there are many features that should be changed before adding them to the final 2.3.0 release. Just out of curiosity: What are they? Bernd All the configurations/components introduced in 2.3.0a1 needs to be reviewed and possibly renamed/moved/changed. I would like to also change the smtp command handler code before a final release, otherwise we will have to mantain 2 totally different fastfail codes. I would also like to introduce the command handler pattern to pop3 and remotemanager: this would add a great level of extensibility to James. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Hi Bernd, I just committed a patch for the ClassCastException you reported. Please open a new JIRA issue if you still have exceptions. Stefano Bernd Fondermann wrote: r233184 is the 8bitmime stuff I disabled today (temp workaround, but we may need to submit a bugreport to sun-javamail) How can it be related to JAMES-447 ? Isn't that commit related to JAMES-419? sorry for the confusion. you are right. after the 447 problems had gone, another exception popped up: 27/04/06 17:16:52 INFO James.Mailet: RemoteDelivery: Exception caught in RemoteDelivery.run() java.lang.ClassCastException at org.apache.james.transport.mailets.RemoteDelivery.setEncodingIfMissing(RemoteDelivery.java:785) at org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:527) at org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1098) at java.lang.Thread.run(Thread.java:534) my interpretation was, that this is the same ClassCastException like with 447, but of course i could be wrong. i'm still trying to get a more decent stack trace. after removing the code from said revision the problem is gone. i'll sync my diverse test envs, do some more investigation and share any usefull info here. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Stefano Bagnara wrote: Bernd Fondermann wrote: What is the Postage problem with current trunk? Do you need help with that? (I only returned to these problems yesterday.) On Unix (Linux/MacOS) I still get JAMES-447 until I revert r233184. On Windows I get JAMES-419. I'll check today if same solution applies here. r233184 is the 8bitmime stuff I disabled today (temp workaround, but we may need to submit a bugreport to sun-javamail) How can it be related to JAMES-447 ? Isn't that commit related to JAMES-419? sorry for the confusion. you are right. after the 447 problems had gone, another exception popped up: 27/04/06 17:16:52 INFO James.Mailet: RemoteDelivery: Exception caught in RemoteDelivery.run() java.lang.ClassCastException at org.apache.james.transport.mailets.RemoteDelivery.setEncodingIfMissing(RemoteDelivery.java:785) at org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:527) at org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1098) at java.lang.Thread.run(Thread.java:534) my interpretation was, that this is the same ClassCastException like with 447, but of course i could be wrong. i'm still trying to get a more decent stack trace. after removing the code from said revision the problem is gone. i'll sync my diverse test envs, do some more investigation and share any usefull info here. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Stefano Bagnara wrote: I don't think that the current James trunk is ready to be feature freezed. Imho there are many features that should be changed before adding them to the final 2.3.0 release. Just out of curiosity: What are they? Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
I don't think that the current James trunk is ready to be feature freezed. Imho there are many features that should be changed before adding them to the final 2.3.0 release. I think that the current trunk is almost ready for an alpha 2 release. I just closed or temporarily resolved the known show-stoppers and the current trunk should be better than alpha 1, overall. Now we have 2 minor patches waiting to be included in alpha2 (via JIRA) but I think we can test the current code and make an alpha2 release as soon as possible, and then move again forward. We could schedule the next release for the end of the next week or at last mid may: can you take care of the release? (we should remember to tag the code we release, this time) I think we could even skip the vote if we don't make the release "official" but only a test build like we did for alpha1, am I right? In current alpha2 we have 9 improvements, 4 features, and 13 bug fixes (an half only affecting the new code, the other half affecting 2.3.0a1 and also older code). I'm not aware of new bugs introduced after 2.3.0a1 and unresolved. About the stability issue I think we talked about this in past: if we want to feature freeze we should branch. I currently prefer to keep releasing alphas and introducing minor features instead of feature freezing. Stefano Noel J. Bergman wrote: Stefano, As much as I would like to see changes in the current FF code, I really urge that we focus on making the current trunk stable and releasable, and then add improved functionality after the release. If we keep adding rather than consolidating, we'll never get a release done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Bernd Fondermann wrote: What is the Postage problem with current trunk? Do you need help with that? (I only returned to these problems yesterday.) On Unix (Linux/MacOS) I still get JAMES-447 until I revert r233184. On Windows I get JAMES-419. I'll check today if same solution applies here. r233184 is the 8bitmime stuff I disabled today (temp workaround, but we may need to submit a bugreport to sun-javamail) How can it be related to JAMES-447 ? Isn't that commit related to JAMES-419? I saw no replies to JAMES-447 so I closed it as invalid: please comment the issue and reopen it if valid. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Stefano Bagnara wrote: Bernd Fondermann wrote: Norman Maurer wrote: Am Donnerstag, den 27.04.2006, 09:23 +0200 schrieb Stefano Bagnara: I'm working with Norman to find a solution for JAMES-466. Unfortunately few people (just Norman and me, probably) is testing the current trunk so it takes a lot to collect bugreports and to try to find the real problems and possible workarounds. i'm always on trunk. as soon as the postage code is running with TRUNK, too, i will be able to run tests on windows/linux/macos. Do you use db repositories? yes. default Derby. > Have you experienced the JAMES-466 issue? (SQLException storing messages in repositories). no, not yet. i'll double check and keep my eyes open. What is the Postage problem with current trunk? Do you need help with that? (I only returned to these problems yesterday.) On Unix (Linux/MacOS) I still get JAMES-447 until I revert r233184. On Windows I get JAMES-419. I'll check today if same solution applies here. If others could run Postage and give feedback this would be cool. Maybe they get the same errors, maybe not. > PS: I had not worked on your latest patches because I hope you will have the rights to do it yourself soon. OK, I thought so. I'll hope to get the account soon. (And no, I am not impatient ;-) ) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Bernd Fondermann wrote: Norman Maurer wrote: Am Donnerstag, den 27.04.2006, 09:23 +0200 schrieb Stefano Bagnara: I'm working with Norman to find a solution for JAMES-466. Unfortunately few people (just Norman and me, probably) is testing the current trunk so it takes a lot to collect bugreports and to try to find the real problems and possible workarounds. i'm always on trunk. as soon as the postage code is running with TRUNK, too, i will be able to run tests on windows/linux/macos. Do you use db repositories? Have you experienced the JAMES-466 issue? (SQLException storing messages in repositories). What is the Postage problem with current trunk? Do you need help with that? Stefano PS: I had not worked on your latest patches because I hope you will have the rights to do it yourself soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Norman Maurer wrote: Am Donnerstag, den 27.04.2006, 09:23 +0200 schrieb Stefano Bagnara: I'm working with Norman to find a solution for JAMES-466. Unfortunately few people (just Norman and me, probably) is testing the current trunk so it takes a lot to collect bugreports and to try to find the real problems and possible workarounds. i'm always on trunk. as soon as the postage code is running with TRUNK, too, i will be able to run tests on windows/linux/macos. Yesterday we finally found a "revert" patch that remove JAMES-466 exception and it seemed to work, so we currently have an option to remove the 3 show stoppers issue: for all of the 3 bugs the "fast" solution is to disable totally or partially the new code. i'd favor roll back of new features if the blockers are too hard to solve ATM. I would not like to release 2.3.0 final with that 3 issues solved with "workarounds" bit I think that a 2.3.0a2 would really help if people will test it and try to work more on that issues before 2.3.0a3. This would be a good idea cause many people are scared about use nigthly builds. So we maybe get more testers ;-) Noel J. Bergman wrote: Stefano, As much as I would like to see changes in the current FF code, I really urge that we focus on making the current trunk stable and releasable, and then add improved functionality after the release. If we keep adding rather than consolidating, we'll never get a release done. --- Noel Thats also right. We should consider to "freeze" the current james version( no new features) and only try to fix bugs to get it stable. After we/you realease the stable version we/you can work again on new featues Agreed, let's freeze features and put out a 'beta', as soon as all known blockers are removed. 'beta', because it shows users that bigger changes have become more unlikely and we are getting closer to release. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pushing towards a RELEASE
Am Donnerstag, den 27.04.2006, 09:23 +0200 schrieb Stefano Bagnara: > I'm working with Norman to find a solution for JAMES-466. > > Unfortunately few people (just Norman and me, probably) is testing the > current trunk so it takes a lot to collect bugreports and to try to find > the real problems and possible workarounds. > > Yesterday we finally found a "revert" patch that remove JAMES-466 > exception and it seemed to work, so we currently have an option to > remove the 3 show stoppers issue: for all of the 3 bugs the "fast" > solution is to disable totally or partially the new code. > > I would not like to release 2.3.0 final with that 3 issues solved with > "workarounds" bit I think that a 2.3.0a2 would really help if people > will test it and try to work more on that issues before 2.3.0a3. This would be a good idea cause many people are scared about use nigthly builds. So we maybe get more testers ;-) > > On the other side I would also like if we focus on taking decisions > about the creation of the spf subproject and the svn rights for Alan and > Norman ;-) Hope so too ;-) > > Stefano > > Noel J. Bergman wrote: > > Stefano, > > > > As much as I would like to see changes in the current FF code, I really urge > > that we focus on making the current trunk stable and releasable, and then > > add improved functionality after the release. If we keep adding rather than > > consolidating, we'll never get a release done. > > > > --- Noel Thats also right. We should consider to "freeze" the current james version( no new features) and only try to fix bugs to get it stable. After we/you realease the stable version we/you can work again on new featues Bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Pushing towards a RELEASE
I'm working with Norman to find a solution for JAMES-466. Unfortunately few people (just Norman and me, probably) is testing the current trunk so it takes a lot to collect bugreports and to try to find the real problems and possible workarounds. Yesterday we finally found a "revert" patch that remove JAMES-466 exception and it seemed to work, so we currently have an option to remove the 3 show stoppers issue: for all of the 3 bugs the "fast" solution is to disable totally or partially the new code. I would not like to release 2.3.0 final with that 3 issues solved with "workarounds" bit I think that a 2.3.0a2 would really help if people will test it and try to work more on that issues before 2.3.0a3. On the other side I would also like if we focus on taking decisions about the creation of the spf subproject and the svn rights for Alan and Norman ;-) Stefano Noel J. Bergman wrote: Stefano, As much as I would like to see changes in the current FF code, I really urge that we focus on making the current trunk stable and releasable, and then add improved functionality after the release. If we keep adding rather than consolidating, we'll never get a release done. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pushing towards a RELEASE
Stefano, As much as I would like to see changes in the current FF code, I really urge that we focus on making the current trunk stable and releasable, and then add improved functionality after the release. If we keep adding rather than consolidating, we'll never get a release done. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
Noel J. Bergman wrote: Serge, Noel J. Bergman wrote I am still concerned about the Derby related crash that I saw earlier. Anyone have a clue? And is there anything that we need to do to cleanly shut Derby down? I'm at -0 over using Derby at this point. Well, we aren't talking about it being the only database, just the default database until a user configures another. my gut was telling me Derby isn't a production grade DB for the type of heavy IO use that James has. I am leaning towards disagreeing with you. Derby is used extensively and reliably in commercial products. I'm not sure what our issue is, so I'd suggest that we try to get some help from the Derby folks to evaluate and correct our use of it (cc: [EMAIL PROTECTED]). I'm happy to help. What's the problem? Also -- 1) What version of derby is being used? Posting the output from this command would be the most helpful: java org.apache.derby.tools.sysinfo 2) Which jdbc driver is being used? (Derby embedded, Derby Network Client, DB2 UDB Universal JDBC, Object Web C-JDBC, ) -jean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
> AFAIK if it has it's own virtual machine (so it's in network mode) and if has > more than 64MB it can gracefully handle such situations. The problem is that under > 64MB it can do to much for such situations - it's like an IDE that doesn't do well > without a minimal size :). see below... > No it's not the same. Derby is not 'full in memory' db, and it has special > fail safe functions(and recovery too). > There are however a few tips that must be followed to work efficiently (and mostly they > do not apply on any DB - e.g. Mysql) I thought derby (like hsqldb) could run in either network, or embedded mode. I think noel is using it in embedded mode: his config suggests that (and that is the advantage of derby over any other database to james - it's embedded - doesnt require any external program running). And in that mode, it shares memory with everything else in the JVM. Fail safe/recovery functions are great... but cant do anything if they cant allocate any memory because somthing else in the JVM is hogging it all! Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
Given that the whole crash starts with: java.lang.OutOfMemoryError, then maybe that caused the problem with derby. From the derby list, 64MB for it only looks like not enough. Does anyone know anything about derby's behaviour when it runs out of memory? I'd imagine that these errors are caught in any code that uses a lot of memory (ie loading data) but what about other parts of code that arnt as likely to cause that kind of problem? AFAIK if it has it's own virtual machine (so it's in network mode) and if has more than 64MB it can gracefully handle such situations. The problem is that under 64MB it can do to much for such situations - it's like an IDE that doesn't do well without a minimal size :). I know very little about derby, but i have used hsqldb before. It had similar problems - if one instance of the driver opened a database, other instances couldnt write to them (or read iirc). No it's not the same. Derby is not 'full in memory' db, and it has special fail safe functions(and recovery too). There are however a few tips that must be followed to work efficiently (and mostly they do not apply on any DB - e.g. Mysql) IMHO the best would be to setup a test system that can be reached by other Apache members, and than to ask kindly the authors from Derby to have a look(they are also Apache members, right?). I think they would be more than happy to help (since this could be a prestige 'powered by' project) :). Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
> I am still concerned about the Derby related crash that I saw earlier. > Anyone have a clue? And is there anything that we need to do to cleanly > shut Derby down? > > --- Noel Given that the whole crash starts with: java.lang.OutOfMemoryError, then maybe that caused the problem with derby. Does anyone know anything about derby's behaviour when it runs out of memory? I'd imagine that these errors are caught in any code that uses a lot of memory (ie loading data) but what about other parts of code that arnt as likely to cause that kind of problem? I know very little about derby, but i have used hsqldb before. It had similar problems - if one instance of the driver opened a database, other instances couldnt write to them (or read iirc). So if you managed to crash that instance of the database, you had to restart the container before you could use it again. This is a problem with built in java databases, and java in general. It's a shame there isnt a way to allocate java memory to specific services (ie, allocate xMB to derby, xMB to core, xMB to remotedelivery, etc). Have you tried reinstating the memory leak to see if the same crash occurs? Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
Serge, > Noel J. Bergman wrote > > I am still concerned about the Derby related crash that I saw earlier. > > Anyone have a clue? And is there anything that we need to do to cleanly > > shut Derby down? > I'm at -0 over using Derby at this point. Well, we aren't talking about it being the only database, just the default database until a user configures another. > my gut was telling me Derby isn't a production grade DB for the > type of heavy IO use that James has. I am leaning towards disagreeing with you. Derby is used extensively and reliably in commercial products. I'm not sure what our issue is, so I'd suggest that we try to get some help from the Derby folks to evaluate and correct our use of it (cc: [EMAIL PROTECTED]). > Maybe configure it as the default database, but still leave > the file for now? Or dbfile? I don't believe that we're planning to remove support for file or dbfile any time soon. I prefer dbfile, actually, for my own use. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
On 11/7/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > OK, I ran another set of tests overnight, and didn't see any sign of a > memory leak. > > I am still concerned about the Derby related crash that I saw earlier. > Anyone have a clue? And is there anything that we need to do to cleanly > shut Derby down? I'm at -0 over using Derby at this point. I hate to veto, but my gut was telling me Derby isn't a production grade DB for the type of heavy IO use that James has. Maybe configure it as the default database, but still leave the file for now? Or dbfile? What do you think we should do at this point re: Derby if we don't have some easy workaround? -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
> [...] The next > thing after that will be more aggressive looking for memory > leaks, and the interesting task of converting my production > configuration to the new scheme. If that works, great. If > not, we have some tweaking to do. > :-) Plus whatever comes back from user tests. OK, I ran another set of tests overnight, and didn't see any sign of a memory leak. I am still concerned about the Derby related crash that I saw earlier. Anyone have a clue? And is there anything that we need to do to cleanly shut Derby down? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
Serge Knystautas wrote: > Any chance we can use ASF hardware to conduct these tests > so other people can help? Interesting thought. We could ask for a JAMES zone, but we will have to be very careful (a) not to permit others to access JAMES there for spam, and (b) to make sure that we don't unduly use resources, e.g., the spinloop issues I found in postal and rabid. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
> [...] The next > thing after that will be more aggressive looking for memory > leaks, and the interesting task of converting my production > configuration to the new scheme. If that works, great. If > not, we have some tweaking to do. > :-) Plus whatever comes back from user tests. > > Sound about right? > > --- Noel +1 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
On 10/30/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Noel J. Bergman <[EMAIL PROTECTED]> wrote on Oct 19th: > > > I have run a first test, but also encountered a problem. Not with > > JAMES, but > with the test environment. At home, I run JAMES on > > one server, postal and rabid on another. I hadn't noticed before, > > but postal and rabid are not CPU friendly. Basically, they eat the CPU. > > I have fixed this, at least sufficiently for more testing. I was also able > to run a few tests using a second machine. So far so good. One more test, > and I believe that I will be ready to post a build to be voted on as an > alpha. The next thing after that will be more aggressive looking for memory > leaks, and the interesting task of converting my production configuration to > the new scheme. If that works, great. If not, we have some tweaking to do. > :-) Plus whatever comes back from user tests. > > Sound about right? Sounds good. Any chance we can use ASF hardware to conduct these tests so other people can help? (I may have asked this before... my brain is blanking right now). -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
Noel J. Bergman <[EMAIL PROTECTED]> wrote on Oct 19th: > I have run a first test, but also encountered a problem. Not with > JAMES, but > with the test environment. At home, I run JAMES on > one server, postal and rabid on another. I hadn't noticed before, > but postal and rabid are not CPU friendly. Basically, they eat the CPU. I have fixed this, at least sufficiently for more testing. I was also able to run a few tests using a second machine. So far so good. One more test, and I believe that I will be ready to post a build to be voted on as an alpha. The next thing after that will be more aggressive looking for memory leaks, and the interesting task of converting my production configuration to the new scheme. If that works, great. If not, we have some tweaking to do. :-) Plus whatever comes back from user tests. Sound about right? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Planning on it. I need to re-do my testing configuration with the new > config and test that, and then re-do my production configuration and give > that a whirl. If those look good, I'll propose an alpha for vote. I don't > like posting anything that I would not run myself. I have run a first test, but also encountered a problem. Not with JAMES, but with the test environment. At home, I run JAMES on one server, postal and rabid on another. I hadn't noticed before, but postal and rabid are not CPU friendly. Basically, they eat the CPU. So running postal and rabid under VMware on my laptop along with JAMES means that they interfer with testing, so I had to back off the testing a bit. Just rebuilt postal and rabid for Mac OS X, so we'll run those on a separate physical machine. And I have notified Russell of the issue. I have run an overnight test with just SMTP and SMTP relay, using db for mailboxes and users, and file for all else. No perceived memory leaks, but I did run out of handles for the database until I raised the max to 40. Bottom line: so far, so good. Will start additional testing along the full SMTP and POP3 path tonight, and will check file, db and dbfile using Derby for the DB. Do not plan to test any other databases. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
On 10/17/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Planning on it. I need to re-do my testing configuration with the new > config and test that, and then re-do my production configuration and give > that a whirl. If those look good, I'll propose an alpha for vote. I don't > like posting anything that I would not run myself. Sounds great. Thanks! -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Working towards a release
Serge Knystautas wrote: > This feels extremely lame to say, but why don't we just put an alpha > release out (once you get derby properly set as default, steps to > migrate, whatever core issues you addressed) and not worry about all > the other project-level issues? Planning on it. I need to re-do my testing configuration with the new config and test that, and then re-do my production configuration and give that a whirl. If those look good, I'll propose an alpha for vote. I don't like posting anything that I would not run myself. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
On 10/15/05, Scott Carr <[EMAIL PROTECTED]> wrote: > >make changes, primarily in the smtphandler. But for now, I'm calling it > >2.3. > > > Configuration changes may warrant a 3.0 release, depending on how much > and how in depth the changes are. +1 This feels extremely lame to say, but why don't we just put an alpha release out (once you get derby properly set as default, steps to migrate, whatever core issues you addressed) and not worry about all the other project-level issues? No documentation is bad, but IMO no releases is worse. :( -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
> So, I'm sitting here starting to work on the release. > Amongst my questions is whether this is 2.3 or 3.0. One > basis for the latter are the changes not so much in API, but > in the configuration files. Administrators will need to make > changes, primarily in the smtphandler. But for now, I'm > calling it 2.3. +1. > With respect to config.xml: > > -- we say that derby is our default, but ALL of the > data sources are commented out, including Derby. I'm +1 for this change. http://issues.apache.org/jira/browse/JAMES-393?page=all > -- the config is putting the database under bin/. > I think we should move that under var/. Thank you for the fix. > As I said, I'm just working my way through things, and > posting as I find something of note. Comments solicited. > Help appreciated. :-) > > Speaking of which, we need to work on: > > -- docs > -- package build. licenses need to be put at the package root > -- web site. Embarrassingly, the AL v1 is showing on the web > site (I noticed that today), even though AL v2 is everywhere > else in JAMES. > -- web site building (just moving things around a bit, to start). > > Does anyone have time to help work on these things? > > --- Noel I currently don't have too much time. Maybe I should try to keep the time for code issues. I don't know much about documentation generation, website rules and release packaging. I don't know wether this is a possible roadmap or not but I think we could publish a first 2.3.0 alpha 1 release and from there decide what changes/bugfix we need for the following release and delay the goal to update website/docs for the 2.3.0rc1. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
Noel J. Bergman wrote: So, I'm sitting here starting to work on the release. Amongst my questions is whether this is 2.3 or 3.0. One basis for the latter are the changes not so much in API, but in the configuration files. Administrators will need to make changes, primarily in the smtphandler. But for now, I'm calling it 2.3. Configuration changes may warrant a 3.0 release, depending on how much and how in depth the changes are. With respect to config.xml: -- we say that derby is our default, but ALL of the data sources are commented out, including Derby. -- the config is putting the database under bin/. I think we should move that under var/. Move under /var definately. /usr is no place for data. [snip] -- Scott Carr OpenOffice.org Documentation Maintainer http://documentation.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working towards a release
Noel J. Bergman wrote: So, I'm sitting here starting to work on the release. Amongst my questions is whether this is 2.3 or 3.0. One basis for the latter are the changes not so much in API, but in the configuration files. Administrators will need to make changes, primarily in the smtphandler. But for now, I'm calling it 2.3. With respect to config.xml: -- we say that derby is our default, but ALL of the data sources are commented out, including Derby. -- the config is putting the database under bin/. I think we should move that under var/. As I said, I'm just working my way through things, and posting as I find something of note. Comments solicited. Help appreciated. :-) Speaking of which, we need to work on: -- docs -- package build. licenses need to be put at the package root -- web site. Embarrassingly, the AL v1 is showing on the web site (I noticed that today), even though AL v2 is everywhere else in JAMES. -- web site building (just moving things around a bit, to start). Does anyone have time to help work on these things? Where would be the best place to help? I know Java pretty good, and can help in various areas, as needed. What kind of docs are needed? --- Noel -- Scott Carr OpenOffice.org Documentation Maintainer http://documentation.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Working towards a release
So, I'm sitting here starting to work on the release. Amongst my questions is whether this is 2.3 or 3.0. One basis for the latter are the changes not so much in API, but in the configuration files. Administrators will need to make changes, primarily in the smtphandler. But for now, I'm calling it 2.3. With respect to config.xml: -- we say that derby is our default, but ALL of the data sources are commented out, including Derby. -- the config is putting the database under bin/. I think we should move that under var/. As I said, I'm just working my way through things, and posting as I find something of note. Comments solicited. Help appreciated. :-) Speaking of which, we need to work on: -- docs -- package build. licenses need to be put at the package root -- web site. Embarrassingly, the AL v1 is showing on the web site (I noticed that today), even though AL v2 is everywhere else in JAMES. -- web site building (just moving things around a bit, to start). Does anyone have time to help work on these things? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
On Tuesday 05 July 2005 18:18, Noel J. Bergman wrote: > Soren Hilmer wrote: > > Just noticed that we are still using the "untagged" version of Phoenix. > > I thought that it was a goal of the merger process to get to Phoenix > > version 4.0.4 (isn't that the latest) or have I missed some discussion > > on this? > > I thought that Stephen and Co. had already updated Phoenix when updating > the rest of the Avalon components. If not, we should try to find the right > code and get it included. > Well I you look at the phoenix-bin in trunk it is exactly the same as in the old branch_2_1_fcs also starting the trunk-James gives states Phoenix 4.0.1, so... > Where do you see Phoenix v4.0.4? I see v4.0.3 under tags, but nothing > later. Hmmm, it is sitting here on my disk :-) I downloaded it from ASF a while back (February 18. 2004 to be exact), but the download pages seams gone with the project :-( I can point you to a mirror here: http://www.axint.net/apache/avalon/phoenix/v4.0.4/ Do you by any chance know why ASF has removed Avalon,Phoenix and related downloads. As we keep saying, even while the Avalon project has died, the code is still fine. So there would be no reason to disable downloads of the released versions. Dead projects code could/should be moved to some area for unsupported code or something, "ASF Cemetary" perhaps :-) Also totally unrelated, I noticed that the James home page states: "James requires Java 1.4", again have I missed a consensus on demanding 1.4 I thought that was scheduled for a future release. --Søren > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A release?
Soren Hilmer wrote: > Just noticed that we are still using the "untagged" version of Phoenix. > I thought that it was a goal of the merger process to get to Phoenix > version 4.0.4 (isn't that the latest) or have I missed some discussion > on this? I thought that Stephen and Co. had already updated Phoenix when updating the rest of the Avalon components. If not, we should try to find the right code and get it included. Where do you see Phoenix v4.0.4? I see v4.0.3 under tags, but nothing later. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
Hi all, Just noticed that we are still using the "untagged" version of Phoenix. I thought that it was a goal of the merger process to get to Phoenix version 4.0.4 (isn't that the latest) or have I missed some discussion on this? --Søren On Monday 04 July 2005 18:40, [EMAIL PROTECTED] wrote: > > FYI, I have james-3.0-dev in production since some weeks now, > > and it runs quite well: I didn't have any single problem until now. > > So do I > > > I would vote +1 for a new release if asked ;-) > > > > Vincenzo > > So do I ;-) > > Stefano > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
> FYI, I have james-3.0-dev in production since some weeks now, > and it runs quite well: I didn't have any single problem until now. So do I > I would vote +1 for a new release if asked ;-) > > Vincenzo So do I ;-) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
FYI, I have james-3.0-dev in production since some weeks now, and it runs quite well: I didn't have any single problem until now. I would vote +1 for a new release if asked ;-) Vincenzo Noel J. Bergman wrote: Serge Knystautas wrote: I would /love/ to get a release out and never have to support branch_2_1_fcs again! :) At least put it out for public testing... have we mentioned there are the 3.0 releases in the Test build directory? OK. When I get back online (probably late on Tuesday), I'll start to prep for a build. In the meantime, let's try to put together a release plan of things that must be done before release, other than testing. Along those lines, I am not entirely comfortable with one recently applied patch that I want to revisit, so I have got that bookmarked. If someone wouldn't mind starting the release plan as a wiki page, I'd appreciate it, rather than having to sift through another 2500 e-mails, which is what I had from when I was off-line last week. And I think that we're talking about a release plan starting now, not post POJO and a million other things. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A release?
Noel J. Bergman wrote: > > > Seeking for perfection keeps stalling us. > > Hence focusing on what we can do now. > > > Could we not backout that patch and revisit it after alpha1? > > Well, we could just as easily leave it in, too. But I do > want to take a > closer look at it. Not knowing what the patch is, all I'm saying is that if you are unsure if it will break something, hold it back until you have confidence in it. Whether it gets into aplha1 or alpha21 doesn't matter. We only freeze features when switching from alphas to release candidates don't we? > > > we're talking about a release plan starting > > > now, not post POJO and a million other things. > > > We should be looking at releasing what we have now. > > Well, I would start the process, but if we have some low hanging fruit > pending, I would just as soon try to get it into this cycle. > > > Should we be trying to sweep up as many open issues in Jira > > as we can too? This might mean fixes, won't fix, or fix in > > a post 3.0 release. > > Right. But focus on things we can fix now, not that will take merging > MIME4J or other changes. Get this out, and then start > merging in those new > functional changes. Yep! Dealing with Jira entries means classifying them and just one of those classifications - fix version 3.0 - means incorporating them into the release. We can classify MIME4J or other possible architectural changes to a fix version of 'unknown'. Post 3.0 we can reclassify them to a specific fix version or even 'Won't fix' if we decide that this isn't the way we are going. Its just a way of reducing the number of open issues that some people view as indicative of us being unresponsive. There may be better ways? > > I just want to make this good and stable. Absolutely! A solid base for the future. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A release?
> Seeking for perfection keeps stalling us. Hence focusing on what we can do now. > Could we not backout that patch and revisit it after alpha1? Well, we could just as easily leave it in, too. But I do want to take a closer look at it. > > we're talking about a release plan starting > > now, not post POJO and a million other things. > We should be looking at releasing what we have now. Well, I would start the process, but if we have some low hanging fruit pending, I would just as soon try to get it into this cycle. > Should we be trying to sweep up as many open issues in Jira > as we can too? This might mean fixes, won't fix, or fix in > a post 3.0 release. Right. But focus on things we can fix now, not that will take merging MIME4J or other changes. Get this out, and then start merging in those new functional changes. I just want to make this good and stable. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
On 6/30/05, Steve Brewin <[EMAIL PROTECTED]> wrote: > > And I think that we're talking about a release plan starting > > now, not post > > POJO and a million other things. > > We should be looking at releasing what we have now. > > Should we be trying to sweep up as many open issues in Jira as we can too? > This might mean fixes, won't fix, or fix in a post 3.0 release. +1 I think we try to make 3.0 release as stable as possible, i.e., a replacement for 2.2.x. This signals an end to the 2.x branch and then we start deciding what to add after that goes out. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A release?
Noel J. Bergman wrote: > Serge Knystautas wrote: > > > I would /love/ to get a release out and never have to > > support branch_2_1_fcs again! :) At least put it out > > for public testing... have we mentioned there are the > > 3.0 releases in the Test build directory? > > OK. When I get back online (probably late on Tuesday), I'll > start to prep > for a build. In the meantime, let's try to put together a > release plan of > things that must be done before release, other than testing. > Along those > lines, I am not entirely comfortable with one recently > applied patch that I > want to revisit, so I have got that bookmarked. Seeking for perfection keeps stalling us. Could we not backout that patch and revisit it after alpha1? > If someone wouldn't mind starting the release plan as a wiki page, I'd > appreciate it, rather than having to sift through another > 2500 e-mails, > which is what I had from when I was off-line last week. > > And I think that we're talking about a release plan starting > now, not post > POJO and a million other things. We should be looking at releasing what we have now. Should we be trying to sweep up as many open issues in Jira as we can too? This might mean fixes, won't fix, or fix in a post 3.0 release. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A release?
Serge Knystautas wrote: > I would /love/ to get a release out and never have to > support branch_2_1_fcs again! :) At least put it out > for public testing... have we mentioned there are the > 3.0 releases in the Test build directory? OK. When I get back online (probably late on Tuesday), I'll start to prep for a build. In the meantime, let's try to put together a release plan of things that must be done before release, other than testing. Along those lines, I am not entirely comfortable with one recently applied patch that I want to revisit, so I have got that bookmarked. If someone wouldn't mind starting the release plan as a wiki page, I'd appreciate it, rather than having to sift through another 2500 e-mails, which is what I had from when I was off-line last week. And I think that we're talking about a release plan starting now, not post POJO and a million other things. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
On 6/14/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > How close are we to doing a release? I'm thinking we might well be pretty > close? Are there any showstoppers or low hanging fruit? > > There is a lot of good stuff in the current build that would benefit our > users, and we finally have a merged build to support. I would /love/ to get a release out and never have to support branch_2_1_fcs again! :) At least put it out for public testing... have we mentioned there are the 3.0 releases in the Test build directory? -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A release?
> How close are we to doing a release? I'm thinking we might > well be pretty close? Are there any showstoppers or low > hanging fruit? > > There is a lot of good stuff in the current build that would > benefit our users, and we finally have a merged build to support. ** release often, release early ** BTW I think that James 3 will change more after this "milestone" release than from the last release to now. IMHO in the release notes should be clear that Mailet APIs probably will change again before 3.0 final, that configuration probably will change again before 3.0 final and similar "alerts". PS: I would like to see this patch applied before a release: http://issues.apache.org/jira/browse/JAMES-356 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A release?
How close are we to doing a release? I'm thinking we might well be pretty close? Are there any showstoppers or low hanging fruit? There is a lot of good stuff in the current build that would benefit our users, and we finally have a merged build to support. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
