Re: [jira] Commented: (JAMES-424) Invalid DATA for Message shows up in Headers in mailstore
Noel J. Bergman (JIRA) wrote: [ http://issues.apache.org/jira/browse/JAMES-424?page=comments#action_12434868 ] Noel J. Bergman commented on JAMES-424: --- as you keep saying this is a problem in Javamail (and I could agree) Keep it in context. It is a problem with JavaMail because the content is invalid, and JavaMail requires valid content, sometimes resulting in even more invalid content. Without JavaMail having problems, we could still transport such messages. IIRC the problem is in the SMTP transport part, because previously we never change the message and we prepend the Recipient manipulating the original stream and if we never change it then it will be written as is and not parsed. Btw I still don't understand HOW you would parse it IF you have to parse it. I understand what we can do when we don't have to parse it, but we also bundle in James mailets that changes the body: HOW should they work? Let's forget of javamail or mime4j now, I just want to understand the what is the intended/best behaviour! I would like to know where you would add the Received: header in the following message: This is a test Received: a received header I tested ecelerity, and received: 550 5.6.0 Required headers not found (see RFC2822 section 3.6) Not sure but I think this is not RFC compliant: rfc2821 (SMTP) does not say you can check that the data is valid rfc2822 content. So I would avoid behaving this way. Do you agree? qmail, however, accepted it, and I received (so delivered by qmail and added to by JAMES): - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MessageIsInfected: false Received: from minotaur.apache.org ([209.237.227.194]) by mail.devtech.com (JAMES SMTP Server 2.3.0rc3) with SMTP ID 986 for [EMAIL PROTECTED]; Thu, 14 Sep 2006 16:38:25 -0400 (EDT) Date: Thu, 14 Sep 2006 16:38:25 -0400 (EDT) From: [EMAIL PROTECTED] Received: (qmail 95997 invoked by uid 1589); 14 Sep 2006 20:11:44 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 95992 invoked from network); 14 Sep 2006 20:11:44 - Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Sep 2006 20:11:44 - Received: (qmail 1843 invoked by uid 500); 14 Sep 2006 20:11:44 - Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 1840 invoked by uid 99); 14 Sep 2006 20:11:44 - X-ASF-Spam-Status: No, hits=9.2 required=10.0 tests=MISSING_FROM,MISSING_HB_SEP,MISSING_HEADERS,MISSING_SUBJECT,TO_CC_NONE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [66.112.202.2] (HELO devtech.com) (66.112.202.2) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 14 Sep 2006 13:11:44 -0700 X-Virus-Checked: Checked by ClamAV on apache.org this is a test Received: a test header - So qmail prepended headers to the message, but did not take the existing content and try to make a body out of it. Never tested qmail, but I understood from Norman that it was considering it a body: can you test a local delivery to qmail to see if the local mailbox is altered and how? You should look at the saved mailbox in order to understand wether the change is done by qmail, by the pop3 server or by the client reading it. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r446544 - /james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java
Author: bago Date: Fri Sep 15 01:17:50 2006 New Revision: 446544 URL: http://svn.apache.org/viewvc?view=revrev=446544 Log: Translate an italian comment in OnlyText (left by mistake) Modified: james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java Modified: james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java?view=diffrev=446544r1=446543r2=446544 == --- james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java (original) +++ james/server/trunk/src/java/org/apache/james/transport/mailets/OnlyText.java Fri Sep 15 01:17:50 2006 @@ -164,7 +164,7 @@ for (int index = 32; index 128; index++) charMap.put(# + index, String.valueOf((char) index)); for (int index = 128; index 256; index++) charMap.put(# + index, String.valueOf((char) index)); -// una buona tabella è qui +// A complete reference is here: // http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references charMap.put(#09, \t); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r446545 - in /james/server/trunk/src/java/org/apache/james/pop3server: POP3Handler.java POP3Session.java PassCmdHandler.java RsetCmdHandler.java
Author: bago
Date: Fri Sep 15 01:19:40 2006
New Revision: 446545
URL: http://svn.apache.org/viewvc?view=revrev=446545
Log:
Moved POP3Handler.stat() method from the Handler to the RsetCmdHandler
Modified:
james/server/trunk/src/java/org/apache/james/pop3server/POP3Handler.java
james/server/trunk/src/java/org/apache/james/pop3server/POP3Session.java
james/server/trunk/src/java/org/apache/james/pop3server/PassCmdHandler.java
james/server/trunk/src/java/org/apache/james/pop3server/RsetCmdHandler.java
Modified:
james/server/trunk/src/java/org/apache/james/pop3server/POP3Handler.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/pop3server/POP3Handler.java?view=diffrev=446545r1=446544r2=446545
==
--- james/server/trunk/src/java/org/apache/james/pop3server/POP3Handler.java
(original)
+++ james/server/trunk/src/java/org/apache/james/pop3server/POP3Handler.java
Fri Sep 15 01:19:40 2006
@@ -30,8 +30,6 @@
import org.apache.james.util.watchdog.Watchdog;
import org.apache.mailet.Mail;
-import javax.mail.MessagingException;
-
import java.io.IOException;
import java.io.OutputStream;
import java.util.ArrayList;
@@ -102,9 +100,9 @@
* emails in the user's inbox at any given time
* during the POP3 transaction.
*/
-private ArrayList userMailbox = new ArrayList();
+private List userMailbox = new ArrayList();
-private ArrayList backupUserMailbox; // A snapshot list
representing the set of
+private List backupUserMailbox; // A snapshot list representing
the set of
// emails in the user's inbox
at the beginning
// of the transaction
@@ -308,38 +306,6 @@
}
/**
- * Implements a stat. If the handler is currently in
- * a transaction state, this amounts to a rollback of the
- * mailbox contents to the beginning of the transaction.
- * This method is also called when first entering the
- * transaction state to initialize the handler copies of the
- * user inbox.
- *
- */
-public void stat() {
-userMailbox = new ArrayList();
-userMailbox.add(DELETED);
-try {
-for (Iterator it = userInbox.list(); it.hasNext(); ) {
-String key = (String) it.next();
-Mail mc = userInbox.retrieve(key);
-// Retrieve can return null if the mail is no longer in the
store.
-// In this case we simply continue to the next key
-if (mc == null) {
-continue;
-}
-userMailbox.add(mc);
-}
-} catch(MessagingException e) {
-// In the event of an exception being thrown there may or may not
be anything in userMailbox
-getLogger().error(Unable to STAT mail box , e);
-}
-finally {
-backupUserMailbox = (ArrayList) userMailbox.clone();
-}
-}
-
-/**
* Reads a line of characters off the command line.
*
* @return the trimmed input line
@@ -517,14 +483,14 @@
/**
* @see org.apache.james.pop3server.POP3Session#getUserMailbox()
*/
-public ArrayList getUserMailbox() {
+public List getUserMailbox() {
return userMailbox;
}
/**
* @see
org.apache.james.pop3server.POP3Session#setUserMailbox(java.util.ArrayList)
*/
-public void setUserMailbox(ArrayList userMailbox) {
+public void setUserMailbox(List userMailbox) {
this.userMailbox = userMailbox;
}
@@ -533,6 +499,14 @@
*/
public List getBackupUserMailbox() {
return backupUserMailbox;
+}
+
+
+/**
+ * @see
org.apache.james.pop3server.POP3Session#setUserMailbox(java.util.ArrayList)
+ */
+public void setBackupUserMailbox(List backupUserMailbox) {
+this.backupUserMailbox = backupUserMailbox;
}
/**
Modified:
james/server/trunk/src/java/org/apache/james/pop3server/POP3Session.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/pop3server/POP3Session.java?view=diffrev=446545r1=446544r2=446545
==
--- james/server/trunk/src/java/org/apache/james/pop3server/POP3Session.java
(original)
+++ james/server/trunk/src/java/org/apache/james/pop3server/POP3Session.java
Fri Sep 15 01:19:40 2006
@@ -27,7 +27,6 @@
import java.io.IOException;
import java.io.OutputStream;
-import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
@@ -184,26 +183,29 @@
*
* @return mailbox content
*/
-ArrayList getUserMailbox();
+List getUserMailbox();
/**
* Sets a new mailbox content
*
* @param userMailbox mailbox
*/
-void
Re: JAMES Server Nightly Build Report
JAMES Nightly Build System wrote: --- Updating From Source Control --- Reverted 'src/java/org/apache/james/transport/mailets/UnwrapText.java' Reverted 'src/java/org/apache/james/transport/mailets/OnlyText.java' At revision 446534. Anyone knows why the build server keep reverting this 2 files? I checked that the native eol-style is set and that running fixcrlf for the file does not need change them. What am I missing? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] extract part of james-server xdocs to site project or to server-site subproject
+1 bye Norman Stefano Bagnara schrieb: We already removed a few genirc James project docs from the server source tree. Now I would like to remove something more and create a server-site project to mantain all of the site-related things from the server product. We could even simply move this to the server subfolder of the site project (maybe this is better as a first try, so we don't increase too much the number of modules needed to build the website) I would like to move the James menu (Overview, James FAQ, Mailing lists, Wiki) and the Project menu (Bug Database, Source Code, TODO, not sure about Changelog) and Useful RFCs out from the server source tree and only keep pages found in the documentation menu inside each specific james source tree. This way we can keep james 2.2 and james 2.3 documentations live at the same time in an easy way, then we could move to 2.3+2.4, then 2.4 and 3.0 and so on. WDYT? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,45092f6845111614544438! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so why change it for 2.4? Because IMHO it was wrong :-) . Ok, What I'm trying to say that consistency helps understanding: if you change the rules in the middle you don't help people. And if you really have to change the rule for the next minor why don't we change the yet-to-be-release 2.3? I simply say that imho this discussion does not belong to a 2.4. My intent is to stress that IMO, for our project, a next minor release should not be just a subset of features of a next major release, but that there are some compatibility/ease-of-install/risk differences from the point of view of the user, that could drive/justify one branching strategy or another. The numbering scheme is just a suggestion on how to evidentiate it, but is not the substance :-) . Anyway, I always said that I don't care about the number while discussing, I just care about what we release and when. So we can even talk about the next release and skip the number if this helps (we'll vote the number just before the release). 2.x releases have been storage compatible in past, so I think we can safely put in the 2.x scheme every future storage compatible release and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about this meaningless thing: we need code to make releases, not numbers. Not only storage compatible, but also configuration compatible etc. About numbering, it is like naming: helps in stating things. And please breathe a second and take it easy before ironizing and telling other people that they say meaningless things etc. You won't convince anybody this way, you will only put them off. This is not true: 2.x releases have been only storage compatible. I had to upgrade config.xml for evey second-digit step from 2.0 to 2.1.* to 2.2.0 to current 2.3.0rc3. I know. In fact I'm stressing the compatibility/ease-of-install/risk issue (see above) as something to take care of, for our users sake (*we* committers don't have too many problems of this kind). I don't say that what you say is meaningless, I say that numbering is meaningless in a roadmap: a roadmap should include features, maybe dates, but numbers are simply labels used to understand each other. Right. see above. So my proposal is to choose 2 names: one for the release you and Noel are proposing and that will be a branch of 2.3.0 with a few features from trunk to be released before the end of november and the other for the release I and Norman want to work for and to be branched from trunk at start of January 2007 and released in March 2007. I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag to Trunk so that we don't introduce much more confusion. We marked things resolved against 3.0, it is better to say that we resolved them in trunk so we can rename trunk to something else when we'll branch. My fantasy is limited so I would define then next-minor-release and next-major-release (and we could have a next-greater-release for storage incompatibility and other major changes). I think that you can create a new version in jira and call it next-minor and make a list of things you want to merge back in this release. I hope it is fine for you if I won't work on this branch and to agree that this release should not block trunk development or the start of the next-major release. I agree. But, if the next-minor is worth doing, we all need some of your and Norman's help. Otherwise it probably can't be done. I'm not trying to convince anyone, and I'm simply trying to define something that works for me. If you say something that I think is not correct I tell you: this is the way I discuss. I think I worked much more than most of other committers on the James code in the last year so I think that you may not have the same visibility I had on some of the code that has been included in trunk and 2.3 branch, and that's why I write them here. Take into consideration that I will always read and try to understand your point: this doesn't mean I change my ideas easily, but I change them very often (only stupids never change idea). I perfectly know that I don't know perfectly the new code (Socrates teaches ;-) ), and this is the reason why I'm now wary and conservative, and want to be assured and convinced by you (the one that knows the most about the new code) and by Noel (the one that has the widest knowledge of the James code in general) about how sound and feasible and costly and safe is to build the next-minor release (that we all agree that would be worth doing) from the 2.3 branch. And this is the kernel of the discussion going on between you and Noel, that I'm observing to build my final choice. And I would like to hear something from Serge, Danny and the others, because this is going to be a very an important decision. It's more
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini wrote: I think that you can create a new version in jira and call it next-minor and make a list of things you want to merge back in this release. I hope it is fine for you if I won't work on this branch and to agree that this release should not block trunk development or the start of the next-major release. I agree. But, if the next-minor is worth doing, we all need some of your and Norman's help. Otherwise it probably can't be done. I already said that I won't work for the next-minor. At my best I could help you with the website stuff (as I refactored all and maybe I better know the new maven2 site builds), with the maven spf builds (but I need an answer to my repository proposal and if no answer I need Noel to setup the svn notifications so I can really work on james repository) and few other things. I'm not ready to test that releases or to look for bugs in that release. Btw if you find a bug in next-minor and the bug is also in trunk (as when we'll start next-major, next-minor should be already closed), as always, I'll put that on top of my priorities. I'm not trying to convince anyone, and I'm simply trying to define something that works for me. If you say something that I think is not correct I tell you: this is the way I discuss. I think I worked much more than most of other committers on the James code in the last year so I think that you may not have the same visibility I had on some of the code that has been included in trunk and 2.3 branch, and that's why I write them here. Take into consideration that I will always read and try to understand your point: this doesn't mean I change my ideas easily, but I change them very often (only stupids never change idea). I perfectly know that I don't know perfectly the new code (Socrates teaches ;-) ), and this is the reason why I'm now wary and conservative, and want to be assured and convinced by you (the one that knows the most about the new code) and by Noel (the one that has the widest knowledge of the James code in general) about how sound and feasible and costly and safe is to build the next-minor release (that we all agree that would be worth doing) from the 2.3 branch. And this is the kernel of the discussion going on between you and Noel, that I'm observing to build my final choice. I never agreed that it WORTH doing: I said that it would be a good thing to James project and to James users, but I think that it does not worth the efforts and this is the very reason why I say I will work on next-major and not on next-minor. If the efforts are not mine, then I'm really happy with a next-minor release. I think that a +1 should always means I will work for this to happen, and a +0 is it's ok for me but I won't actively help. I'm simply +0 for the next-minor and +1 for the next-major. And I would like to hear something from Serge, Danny and the others, because this is going to be a very an important decision. Well, I always welcome involvement in votes and code, but I think this is not a so big decision: if you fill you can do the next-minor work on it. If it is feasible it will be done, otherwise we have the next-major on the road.. so no big problems either way. It's more than one year that I write to this list, you should have learned that my discussion are a little rude. Don't take it so hard. Ok :-) . But we italians (especially we emiliani and romagnoli) have sometimes to remember that we have sangue caldo ;-) . And the language doesn't help. Right, I'm much more polite (sometimes) when I speak italian. [...] I simply think that with almost the same efforts needed to release 2.3+new improved fastfail (next-minor) we would release the next-major because that one is one of the few things that still deserve much attention. And *this is the key point* :-) . As an alternative approach, what would you think about not backporting the new improved fastfail to 2.3, but instead backporting the new filters (like spf, graylisting etc.) to the old fastfail availble in 2.3? Would it be simpler and safer or not? Maybe Norman has a better overview of this. I always thought and said that fastfail in v2.3 should have not been included or marked as experimental because I know that it was not our final solution and we would have broken backward compatibility later, so I'm not so happy in releasing a new minor release just to improve an experimental feature, but I could leave with it (-0). I really don't know what are the efforts and the risk of backporting the additional filters to the old fastfail pattern. Never thought at this possibility but as a first guess I don't think this is a better approach. I still run heavily modified local branches and my main reason for being a committer to james is reduce my costs to keep them updated by sharing my work with the community: 2.3 has been a failure in my roadmap, I simply can't put more efforts in a
Re: LONG JAMES v2.4 Road Map
Hi to all Developers, I have been following this thread for some time now. Being a Person that is only watching, I came to the conclusion that You as Developers have a totally different understanding as of what should be a 2.4 Release. Right now you are quarreling about things that should be defined once and then be clear to everyone. Looking at the Message History, quarreling and endless discussions are quite common to this project. I know I am an outsider talking, but my Company is spending a certain amount of time and money into this project by giving Norman the opportunity to support this project (the official way). We chose james because we felt that James has a good codebase, and gives us the opportunity to extend its functionality to what we need. We have a lot of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing was as easily extendable as james. On the Contrary, the Feature Set is still very limited. That said, there have been great efforts in widening this topic. Our Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail Server which can be used as a drop-in solution with best-of-breed solutions to common problems. What we have found out is, that this project is willing to walk the way with us. BUT I have also found out, that the Members are hindering themselves to some extent by not talking objectively about certain topics. I see and understand that there are different understandings about release planning. So I want to first lay the cornerstone for the next release. Please vote on which mechanism you want to keep on developing. Vincenzo suggested the most common approach project-x.y.z releases where x - is a release change that is not backwards compatible, or contains major feature enhancements, that involve more inspection by the user, because current configurations are incompatible with this release. y - is a release change that is backward compatible, but contains major feature enhancements. The Installation is not guaranteed to be working with current configurations, but most likely will. z - is completely compatible to the previous release, and contains only bugfixes. From what I understood from the recent posts, is that release planning was handles different in the past, and why should one change it now, when it was different in the past. Well IMHO we all evolve with a project. Sometimes certain decisions are good, sometimes they are bad. But just because there have been bad decisions does not mean to keep bearing with them instead of changing them to something better. But the version numbering is only solving half the problem. The next thing is to define what should be inside a Release. this should first be analyzed by topic i.e. will feature a be an incompatible change, or not. Successful Open-Source Projects (Eclipse, ...) have a strict Release Plan (Minor Releases every 6 Months, Major Releases every Year), with a certain set of features. The Feature Sets should be chosen, so that the release is possible. The Projected Release Dates are fixed to some extend. If a Release Date is coming closer, and it is obvious that a certain feature can not be implemented/integrated to the projected date, there should be a vote on what to do. Move the Release Date, or Move the Feature to the next Release Cycle. Those Rules should be clear to everyone, so noone has to argue or quarrel about what is a next release. That said/written please vote about how release planning should be considered in the future. I would consider the discussed road map to be the 3.0 road map, Norman and Stefano should be responsible for its development. Features that are wanted in 2.4 should be backported by the people that want it within 2.4 release. Noel and Vincenzo should be responsible fpr the 2.4 release. If there are Problems during backporting/migration of features Stefano and Norman should be available for helping, but should keep their focus on 3.0 So please step back from terms of throwing trunk on people and the like, and keep focus on the project. Clear the misunderstandings out, vote on release planning/cycles terminology. Keep focus on the project in favor of interpersonal dislikings. Again I know I am an Outsider, but still I hope you consider my suggestions to this project Kind regards Juergen Hoffmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/14/06, Norman Maurer [EMAIL PROTECTED] wrote: Vincenzo Gianferrari Pini schrieb: I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. Who will do this merge and test it ? I don't think it will be more stable then the code in trunk. For me that make no sense.. Then we have to maintain 3 trees. We are to few developer for that. I share Norman's objections. Maintaining 3 trees will not help us progressing, it will only help stalling the project. For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/14/06, Noel J. Bergman [EMAIL PROTECTED] wrote: I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. I am having a hard time understanding this. Do you say, that all commits in current trunk since branching have a silent -1 from you? What specific changes do you object? I think there are enough eyeballs constantly monitoring trunk, which does not mean to _release_ it blindly without testing. But having an audit on a commit-per-commit basis makes no sense, since many of them where applied to 2.3 branch anyway. The rest simply has to be tested. This is also the reason for me to propose following our original reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch): This is the maintainence branch where we apply bugfixes for 2.3.x. Fixes are isolated, well tested and thus a branch is maintainable. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/15/06, Vincenzo Gianferrari Pini [EMAIL PROTECTED] wrote: Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: It's more than one year that I write to this list, you should have learned that my discussion are a little rude. Don't take it so hard. Ok :-) . But we italians (especially we emiliani and romagnoli) have sometimes to remember that we have sangue caldo ;-) . And the language doesn't help. :-) ... my salt pot is always right here, just for the grain of salt ;-) everyone reading apache lists has to have one! keep in mind, still not everybody has. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Bernd Fondermann wrote: For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd When I say that it is only a number and I don't care of the number I mean *NOW* that we are planning a ROADMAP I don't care too much of the numbers. I agree that the number is really important for a release but I think we could simply decide the right number for our marketing purposes just before releasing it. Either way we need a way to talk each others about the different roadmaps/branches, so I thought at the next-minor, next-major labels... I'm trying to reduce the number of things to be discussed now to the minimum so to increase the probability that we come to some agreement on what to do. If anyone want to start a proposal for a new numbering, I suggest to do it as a separated thread, and I will add my ideas and I will vote about it. I already said that I'm not against the numbering proposed by Vincenzo (or your), and we discussed few times about the current 2.3 in terms of 3.0: we finally decided to use the 2.3 number. I think we should have no worry to make proposals and cast our votes. You know I really used few -1 in past, so don't think that every time I have a different idea it means I will veto it. I usually say I would probably veto this if I think I will do that and when I say I don't agree / I have a different idea it means that I will probably vote -0 and propose something alternative. I don't start that proposal now because I already wrote 2 proposals that are awaiting answers or actions by the people with karma so I don't want to put too many things in the in-progress list. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Bernd Fondermann schrieb: On 9/14/06, Noel J. Bergman [EMAIL PROTECTED] wrote: I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. I am having a hard time understanding this. Do you say, that all commits in current trunk since branching have a silent -1 from you? What specific changes do you object? I think there are enough eyeballs constantly monitoring trunk, which does not mean to _release_ it blindly without testing. But having an audit on a commit-per-commit basis makes no sense, since many of them where applied to 2.3 branch anyway. The rest simply has to be tested. I fully agree on this. I review every commit. I think every commiter should try todo it. If i see any problems with a commit i whould raise my voice. This is also the reason for me to propose following our original reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch): This is the maintainence branch where we apply bugfixes for 2.3.x. Fixes are isolated, well tested and thus a branch is maintainable. Bernd Agree.. bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
On 9/15/06, Jürgen Hoffmann [EMAIL PROTECTED] wrote: Hi to all Developers, I have been following this thread for some time now. Being a Person that is only watching, I came to the conclusion that You as Developers have a totally different understanding as of what should be a 2.4 Release. As always, well observed ;-) Right now you are quarreling about things that should be defined once and then be clear to everyone. Looking at the Message History, quarreling and endless discussions are quite common to this project. ... and probably common many others here at Apache. (Some are even worse ;-)) It is sometimes painful, but this community is not driven by project management, it is driven by _consent_. It's not always as pragmatic as everyone would like to have it. And there are means to come to conclusions, mostly from shorter or longer ;-) discussions. Votes are only the ultimate choice. This project is healthy and very verbose in terms of communication. Just take a second, do a quick man-power calculation and think about how few people with very few effort (compared to other software development) put out great software for free! I know I am an outsider talking, but my Company is spending a certain amount of time and money into this project by giving Norman the opportunity to support this project (the official way). That's really great. I'd guess you get some real value back for that! We chose james because we felt that James has a good codebase, and gives us the opportunity to extend its functionality to what we need. We have a lot of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing was as easily extendable as james. On the Contrary, the Feature Set is still very limited. That said, there have been great efforts in widening this topic. Our Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail Server which can be used as a drop-in solution with best-of-breed solutions to common problems. What we have found out is, that this project is willing to walk the way with us. BUT I have also found out, that the Members are hindering themselves to some extent by not talking objectively about certain topics. There is no way talking objectivly. This is our free-time dedication, we are enthusiastic about it! The only thing we have to adhere to is to deliver mail server software for free. Successful Open-Source Projects (Eclipse, ...) have a strict Release Plan (Minor Releases every 6 Months, Major Releases every Year), with a certain set of features. The Feature Sets should be chosen, so that the release is possible. The Projected Release Dates are fixed to some extend. If a Release Date is coming closer, and it is obvious that a certain feature can not be implemented/integrated to the projected date, there should be a vote on what to do. Move the Release Date, or Move the Feature to the next Release Cycle. There is some truth in this. But Eclipse is driven by companies, it is like a software company. We are not this way. That does not mean we aren't successfull, but this is not an objective opinion either ;-) I am not willing to follow strict release cycles. But it would be good to have a common perspective. That's what is still evolving from the mailing list discussion. It is not simply a thing of voting. Those Rules should be clear to everyone, so noone has to argue or quarrel about what is a next release. That said/written please vote about how release planning should be considered in the future. I guess, release planning is done through discussing the topic on public mailing lists. Not changing that, no vote needed. I would consider the discussed road map to be the 3.0 road map, Norman and Stefano should be responsible for its development. Features that are wanted in 2.4 should be backported by the people that want it within 2.4 release. Noel and Vincenzo should be responsible fpr the 2.4 release. If there are Problems during backporting/migration of features Stefano and Norman should be available for helping, but should keep their focus on 3.0 Well, that's not how it works. (For example, just as a side note, you are exluding me from the list.) We could have a release manager but he'd have no additional rights than all the others. So please step back from terms of throwing trunk on people and the like, and keep focus on the project. Clear the misunderstandings out, vote on release planning/cycles terminology. Keep focus on the project in favor of interpersonal dislikings. I really honestly see no personal dislikings. We are (mostly) always on subject. What you read as dislikings are different technical opinions and goals (which will never change) and maybe some cultural differences. But we still are a team working together on concrete software. Again I know I am an Outsider, but still I hope you consider my suggestions to this project And this is where it gets interesting. ;-) Of course we want to hear from our user base. As a user, what
[jira] Created: (JAMES-616) Add chi-square-based spam filter approach to BayesianAnalyzer.
Add chi-square-based spam filter approach to BayesianAnalyzer. -- Key: JAMES-616 URL: http://issues.apache.org/jira/browse/JAMES-616 Project: James Issue Type: Improvement Components: Matchers/Mailets (bundled) Affects Versions: Trunk Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Fix For: Trunk We should add chi-square-based spam filter approach to BayesianAnalyzer, based on Gary Robinson's blog and paper (http://garyrob.blogs.com//handlingtokenredundancy94.pdf). I will first of all write him an email asking for some clarifications. My impression for now is that the work should not be so difficult. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
Hi Stefano, Stefano Bagnara schrieb: So, do you think that current 2.3.0rc3 should be released as 3.0? no. what is 2.3.0rc3 is, and stays 2.3.0rc3 and will be released as 2.3.0 possible Bugs within it should be released as 2.3.1 Main development (your roadmap to 2.4) should now be 3.0 (Norman and Stefano, ...) anything that gets into 3.0 which would be great to have within 2.3 should go into 2.4 BUT by the 2.3/2.4 Maintainers (Noel and Vincenzo, ...) Did that make it clear? IMO a string release plan is not in our possibilities now: we have less than the equivalend of 2 fulltime developers working on it and not on a regular basis (I don't know about Norman but I cannot take the responsibility to work every day on James, I can only say I would like to do that). Eclipse project as hundreds of developers supported by their own companies. We could have much strict roadmaps and much more stable releases and we would probably need a good project manager to handle it (and not a lazy PMC ;-) ). I see this a little dsifferent. I have been active with turbine for a while, and they had the same sort of problems you guys have now. Today development has stalled and the project (which is great) is short on developers willing to contribute. Because they do not see where or with what to help. Nobody sees the main target, or where the rpoject wants to go to. I still don't know what Vincenzo and Noel want to do with the next-minor release so I'm not able to vote now the number of their release. We also don't have a string roadmap for next-major release (6 months) and I would be more inclined in using 2.x if we don't add some more major change in current trunk, but I won't be against 3.0 or any other number. I simply say that I'm fine with next-minor and next-major and we can define the number as the release content is more concrete. I think that in 3 months we'll be able to evaluate a number for next-major, I can't say anything about next-minor until I say the list of things that they want to backport (it seems to me that the roadmap for this next-minor is not so defined yet) Great. So let us keep it in that way. You are fine with 3.0 = Trunk 2.3 = Release Branch with possible bugfix sub releases 2.4 = Features that went into 3.0 which would be great to have within the 2.3 application layout (This Integration Effort is do be done by the 2.4 maintainers) So please step back from terms of throwing trunk on people and the like, and keep focus on the project. Clear the misunderstandings out, vote on release planning/cycles terminology. Keep focus on the project in favor of interpersonal dislikings. I want to say it again because I don't want to be misunderstood. Don't take my ideas or my objections as trunks on people and I'm just trying to keep the focus on the project. You weren't the one i was citing ;) I think we should use votes much more frequently and avoid endless discussions. I already wrote a proposal for the next spf/mime4j release, a proposal for a website change (to accomodate 2.2, 2.3 and next-minor/next-major docs) and a proposal for the next-minor/next-major stuff because I want to keep the focus on concrete things. agreed. One of the part I liked much more in your message is the X and Y should be responsible for A and Z should be responsible for B. This is really important in project management: we cast votes, we take decisions, +1 votes should always mean active commitment toward a goal and we should try to take responsibilities or to delegate to people we trust some of them. As I said, I trust Vincenzo and Noel enough to know that if they work to make a release they will do a good release so I don't need to review and vote every single diff between trunk and 2.3 to decide what to do: I know I may have different opinions on the risks related to a given patch or to the importance a give feature has for our users, but I understand that 1) I'm not the only developer, 2) this is not *my* project, 3) other committers have enough experience to avoid big mistakes. That would be a giant leap into the right direction. PS: if it is official that your company support Norman in the james work you may want to submit a Corporate CLA (http://www.apache.org/licenses/cla-corporate.txt) as an additional piece of paper to protect ASF from possible licensing problems. If it wouldn't be official, I would have to fire him ;) I can sign this if it is necessary. No Problem. Jürgen Hoffmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
Hi Bernd, Bernd Fondermann schrieb: ... and probably common many others here at Apache. (Some are even worse ;-)) It is sometimes painful, but this community is not driven by project management, it is driven by _consent_. It's not always as pragmatic as everyone would like to have it. And there are means to come to conclusions, mostly from shorter or longer ;-) discussions. Votes are only the ultimate choice. This project is healthy and very verbose in terms of communication. never said it isn't. And it is good to see that the project is active. :) Just take a second, do a quick man-power calculation and think about how few people with very few effort (compared to other software development) put out great software for free! I am a big fan of Apache, do not get me wrong. I am a strong believer into open-source. And I personally know how difficult it is to support the project next to the daily business. I know I am an outsider talking, but my Company is spending a certain amount of time and money into this project by giving Norman the opportunity to support this project (the official way). That's really great. I'd guess you get some real value back for that! At this point in time, the amount of value put into the project is much much greater. There is no way talking objectivly. This is our free-time dedication, we are enthusiastic about it! The only thing we have to adhere to is to deliver mail server software for free. Well, by objective I meant, to put personal interests aside, and focus on the problem at hand. Sometimes it seems as if there are developers sitting and persisting on their viewpoint for days and weeks. That is not helping the problem at hand, Hopefully I could get this point across now. Successful Open-Source Projects (Eclipse, ...) have a strict Release Plan (Minor Releases every 6 Months, Major Releases every Year), with a certain set of features. The Feature Sets should be chosen, so that the release is possible. The Projected Release Dates are fixed to some extend. If a Release Date is coming closer, and it is obvious that a certain feature can not be implemented/integrated to the projected date, there should be a vote on what to do. Move the Release Date, or Move the Feature to the next Release Cycle. There is some truth in this. But Eclipse is driven by companies, it is like a software company. driven by the community though. Take jboss for another example. We are not this way. That does not mean we aren't successfull, but this is not an objective opinion either ;-) I am not willing to follow strict release cycles. But it would be good to have a common perspective. That's what is still evolving from the mailing list discussion. It is not simply a thing of voting. Well from my Point of View there are certain standards on how to plan releases and release cycles. Instead of re-inventing the wheel, I suggest to vote for a proven method. If it is Method A or B is not important to me. That everyone knows and understands it, is more important. That said/written please vote about how release planning should be considered in the future. I guess, release planning is done through discussing the topic on public mailing lists. Not changing that, no vote needed. So you are saying that it makes more sense to discuss how to do the next release each and every time a release was made? I would consider the discussed road map to be the 3.0 road map, Norman and Stefano should be responsible for its development. Features that are wanted in 2.4 should be backported by the people that want it within 2.4 release. Noel and Vincenzo should be responsible fpr the 2.4 release. If there are Problems during backporting/migration of features Stefano and Norman should be available for helping, but should keep their focus on 3.0 Well, that's not how it works. (For example, just as a side note, you are exluding me from the list.) We could have a release manager but he'd have no additional rights than all the others. Bernd, this was by no means to be understood as an offense or anything against other active contributors on this project. This List is neither complete nor a concrete suggestion. Replace the Names in the Lists with A, B, C, and D. So please step back from terms of throwing trunk on people and the like, and keep focus on the project. Clear the misunderstandings out, vote on release planning/cycles terminology. Keep focus on the project in favor of interpersonal dislikings. I really honestly see no personal dislikings. We are (mostly) always on subject. What you read as dislikings are different technical opinions and goals (which will never change) and maybe some cultural differences. But we still are a team working together on concrete software. Again I know I am an Outsider, but still I hope you consider my suggestions to this project And this is where it gets interesting. ;-) Of course we want to hear from our user base. As a user, what concrete features do you
Re: Team Work and *my* approach to open source (Was: LONG JAMES v2.4 Road Map)
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: [...] There is some truth in this. But Eclipse is driven by companies, it is like a software company. We are not this way. That does not mean we aren't successfull, but this is not an objective opinion either ;-) I am not willing to follow strict release cycles. But it would be good to have a common perspective. That's what is still evolving from the mailing list discussion. It is not simply a thing of voting. I really agree on the whole paragrapg but the last sentence: I think that it is ok to use the vote as a pragmatic way to define the limits of our discussions. +1, fully. What I wanted to emphasize is: It's not only a matter of proposing and voting _alone_. proposal = bone discussion = flesh vote = skin well, then comes development, of course... _all_ of those taking part in the discussions are required to discuss + technical + short and on the point + on-topic or fork new thread + be consent driven if everyone remembers those points before hitting send, you will see, discussion outcome will dramatically improve. there is _so_ much noise, repetition and re-iteration going on currently, I have trouble following. I bet others have the same problems, too. BTW, that also applies to the number of proposals that get started virtually in parallel. I have noticed all, I have read some, I understood 1 or 2, I will try to answer all of them. My apologies for not having more time for them. Really, there is so much good stuff you put out, I only wish I had more time. If this is causing frustration on some part: it is not ingorance, it is the missing time. I don't like to discuss ages without a conclusion when I know we could have done both of our different ideas if we simply discussed less and to end up without anything done. I think I'm able to work in team but the team works if we agree we have advantages in working together. OK, agreed, help us to keep disussions short. ;-) You brought us the biggest new feature in James: Unit tests. I think that your contribution, in term of code, is what is making me more happy to be still in James and not working on my own local branch. Wait for the stuff I am going to contribute in future! ;-) I, for my part, like Postage much more than the unit tests. But obviously opinions vary. snip/ instead I preferred to work on the commons-net change and we have been all happy with it. that was cool, couldn't have done that myself so quickly, many thanks again. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Version numbers (Was: LONG JAMES v2.4 Road Map)
Jürgen Hoffmann wrote: I still don't know what Vincenzo and Noel want to do with the next-minor release so I'm not able to vote now the number of their release. We also don't have a string roadmap for next-major release (6 months) and I would be more inclined in using 2.x if we don't add some more major change in current trunk, but I won't be against 3.0 or any other number. I simply say that I'm fine with next-minor and next-major and we can define the number as the release content is more concrete. I think that in 3 months we'll be able to evaluate a number for next-major, I can't say anything about next-minor until I say the list of things that they want to backport (it seems to me that the roadmap for this next-minor is not so defined yet) Great. So let us keep it in that way. You are fine with 3.0 = Trunk 2.3 = Release Branch with possible bugfix sub releases 2.4 = Features that went into 3.0 which would be great to have within the 2.3 application layout (This Integration Effort is do be done by the 2.4 maintainers) I think the main problem in this discussion is that I believe that changes that are in trunk now and that I would like to put in the 6 months release (next-major) are on the same line and on the same layout of 2.3 and they would be part of 2.3 if we didn't branch before. In fact the only common thing between 2.2 and 2.3 is that it is storage compatible and it didn't changed too much the mailets api (but they changed, and furthermore we changed the WHOLE avalon references from components to services). From 2.3 to trunk and to the other features we listed as possible candidates for inclusion there is nothing different from this: we'll keep it storage compatible. (I avoided committing storage incompatible changes because I thought to this personal roadmap few months ago). So if I was the only one to choose names I would use the 2.4 for the next-minor and 2.5 for what we defined next-major and delay major changes in the architecture for 3.0 (dsn support, container changes, repository changes) and I would use 2.4 for next-major in the case there was no next-minor release. I thought this (my idea) was clear enough, but I prefer to be clear so I tried to explain it one more time. I think that the numbers are appropriate from a developer perspective: imho the first number change has to be related to total rewrites or to major architectural changes included. The second number is changed when new features are included, the third for minor releases (tipically bug fixes or really small changes). I also understand the marketing importance of big version numbers, as M$ teach us, but I don't like James XP or James 2006 ;-) and that's why I alsways said that I prefer 2.3 for the current branch and not 3.0 and why I think the next should be consistent with that schema. And about consistency if I knew that the next-major will be an increment in the first number I would probably have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this reflect much better what we changed). I hope I have explained enough the why behind my ideas and I don't think I need to convince anyone that my idea is better than another. In past PMC decided to give me the rights to vote (and I hope I deserved it), so I will simply vote my preference and be sure I won't use a -1 for the version number. The only thing I care is to be able to work on my goals when I have the right mental state to do a good job: if we call next-major 3.0 I simply have more freedom on changes than what I would have if the branch is called 2.5 ;-) so this is enough to be happy even with a bigger number. Furthermore if we use a major number we can also deprecate things and remove some old deprecated code. So I think we should just wait for Noel, Vincenzo and anyone else that is willing to work for the next-minor release to prepare a list or things to be included and we can decide what the version will be (and I believe that if such release will be prepared we'll probably agree on the 2.4 branch/2.4.0 release). About next-major we have 2-3 months before branching and I would like to keep storage compatibility anyway until that day (if possible), so we have a lot of weeks before we'll have to svn copy trunk branches/vX.X ! Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
On 9/15/06, Jürgen Hoffmann [EMAIL PROTECTED] wrote: Hi Bernd, Bernd Fondermann schrieb: That's really great. I'd guess you get some real value back for that! At this point in time, the amount of value put into the project is much much greater. how can you say that?! you get other's and my craftship and expertise for free! :-) There is no way talking objectivly. This is our free-time dedication, we are enthusiastic about it! The only thing we have to adhere to is to deliver mail server software for free. Well, by objective I meant, to put personal interests aside, and focus on the problem at hand. Sometimes it seems as if there are developers sitting and persisting on their viewpoint for days and weeks. That is not helping the problem at hand, Hopefully I could get this point across now. Everyone participating is free to put up a vote. Why doesn't it happen more often? But Eclipse is driven by companies, it is like a software company. driven by the community though. Take jboss for another example. Well, JBoss is not a good example. There is an open source project JBoss and there is a company JBoss who owns (to use neutral wording) the project. We are not this way. That does not mean we aren't successfull, but this is not an objective opinion either ;-) I am not willing to follow strict release cycles. But it would be good to have a common perspective. That's what is still evolving from the mailing list discussion. It is not simply a thing of voting. Well from my Point of View there are certain standards on how to plan releases and release cycles. Instead of re-inventing the wheel, I suggest to vote for a proven method. If it is Method A or B is not important to me. That everyone knows and understands it, is more important. I am doing project management all day, being managed all day. Sorry, I am not able to work like that, here. And don't get me wrong. I want to have a professional result. I want to release often, I want cool features. But I simply cannot commit myself to a project plan. If we'd vote, say, to release 12th december, it would be a nice target. But it would not have any binding in terms of delivering to the user base. That said/written please vote about how release planning should be considered in the future. I guess, release planning is done through discussing the topic on public mailing lists. Not changing that, no vote needed. So you are saying that it makes more sense to discuss how to do the next release each and every time a release was made? No, doesn't make sense probably. But, you see, as this community changes, so does release management and notion thereof. I would consider the discussed road map to be the 3.0 road map, Norman and Stefano should be responsible for its development. Features that are wanted in 2.4 should be backported by the people that want it within 2.4 release. Noel and Vincenzo should be responsible fpr the 2.4 release. If there are Problems during backporting/migration of features Stefano and Norman should be available for helping, but should keep their focus on 3.0 Well, that's not how it works. (For example, just as a side note, you are exluding me from the list.) We could have a release manager but he'd have no additional rights than all the others. Bernd, this was by no means to be understood as an offense or anything against other active contributors on this project. This List is neither complete nor a concrete suggestion. Replace the Names in the Lists with A, B, C, and D. -1. Not agreed. I favor all the committers working together on the current release. We don't want to split the community up. Other projects here at Apache are in deep, deep trouble just because of this! Again I know I am an Outsider, but still I hope you consider my suggestions to this project And this is where it gets interesting. ;-) Of course we want to hear from our user base. As a user, what concrete features do you want in the next release? Keep on your good discussion on the mailing list and you are no longer an outsider. Features that I want into the next release are many. Most of Norman knows about. Will they be in the next release? I do not know. And this is because I think I may not decide on what should go into the next release. I have not enough inside into the codebase. All I know is that the E-Mail Standard will change rapidly in the next years, starting with big companies deploying their Standards. To have an _opinion_ on a whish list item does not require you to have an insight into the codebase. (Or do you know anything about manifacturing your MP3 player which is on your personal birthday wish list.) So do we/you want to deliver standards, or do you want to chase them? Is that related to IMAP? Hopefully, this will be added soon. Sorry that we aren't able to deliver more quickly, but we try to improve. We welcome all people who'd like to contribute. If the day had 72 hours, I'd be a contributor.
Re: LONG JAMES v2.4 Road Map
Bernd Fondermann wrote: Bernd, this was by no means to be understood as an offense or anything against other active contributors on this project. This List is neither complete nor a concrete suggestion. Replace the Names in the Lists with A, B, C, and D. -1. Not agreed. I favor all the committers working together on the current release. We don't want to split the community up. Other projects here at Apache are in deep, deep trouble just because of this! I've proposed the next-minor/next-major because I don't see it as a split. It is simply a group of people that put efforts to consolidate some of the features we have in trunk, while new work in trunk is being done. So I don't think at this as a project fork, but simply a consolidation branch, like we did for 2.3. The main difference between 2.3 is that this time I already said I can't (and want) put my efforts on the consolidation branch. Nothing terrible at all, nothing to call home for. Imho the 2 active trees rule we agreed in past is still valid: trunk is always the main active tree. We're waiting to close 2.3 so the next-minor can be started and only when next-minor will be closed we're going to open the next-major release. Imho this make sense. We can't think we'll have the efforts of every committer for everything we decide to do. There are many James committers that did nothing since 2.1 but they still have the power to vote (even if they don't do this so often). As you said everyone should be able to do what he wants (by respecting the high-level project goals) and when he wants (and not being managed) and we should only try to synchronize/optimize our efforts. Furthermore, I already wrote that the split could give our users the best results (3 releases in 6 months!!) and let everyone work on the preferred tree. So do we/you want to deliver standards, or do you want to chase them? Is that related to IMAP? Hopefully, this will be added soon. Unfortunately I guess that IMAP won't be included in next-minor or next-major, but we can only expect to be able to do some steps in that 2 releases (it would be *really* cool if we were able to put experimental unstable support for imap in next-major but this is not realistic to me). Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES Server Nightly Build Report
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: JAMES Nightly Build System wrote: --- Updating From Source Control --- Reverted 'src/java/org/apache/james/transport/mailets/UnwrapText.java' Reverted 'src/java/org/apache/james/transport/mailets/OnlyText.java' At revision 446534. Anyone knows why the build server keep reverting this 2 files? I checked that the native eol-style is set and that running fixcrlf for the file does not need change them. What am I missing? Stefano I'd like to get familiar with the automatic build process. On which machine is it, and what script is running that? At first I thought it must be minotaur/people, but did not find it. Thanks, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
yet another James manager 0.6 / A web-based GUI to administrate James users
Hello, to whom it may interest: There's a new version of yaJamesManager on Sourceforge. It now has an error-handling for all kind of problems that may could appear. Sourceforge: http://sourceforge.net/projects/yajamesmanager Testride: http://www.nameservice.biz/yajamesmanager/ What's it about? See my initiatory posting: http://mail-archives.apache.org/mod_mbox/james-server-user/200609.mbox/4501ED58.8090108%40lotk.de Enjoy! Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES Server Nightly Build Report
Bernd Fondermann wrote: I'd like to get familiar with the automatic build process. On which machine is it, and what script is running that? At first I thought it must be minotaur/people, but did not find it. Thanks, Bernd Hi Bernd, The only automatic thing ASF give us is GUMP. Under the gump folder in svn you can try to find more informations and you can also find the descriptor used to build james there. Unfortunately I don't know much more about this but this page that I keep monitored: http://vmgump.apache.org/gump/public/james-server/james-server/index.html This mail, instead, come from a Noel server. This is not something that ASF give to us. I also have a CI based on continuum where I build all of the james products using maven2. It is still experimental but I plan to give more visibility to other developers in future. Last time I worked on it I was trying to automatically produce our full website but including much more developers reports (like clover) and all the latest trunk instead of stable releases (that instead should be published on the official site). This does not work very well because of a bug in a maven plugin (I think) but I had no time to work more on this and I'm already happy with the automatic builds it give me now. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: Bernd, this was by no means to be understood as an offense or anything against other active contributors on this project. This List is neither complete nor a concrete suggestion. Replace the Names in the Lists with A, B, C, and D. -1. Not agreed. I favor all the committers working together on the current release. We don't want to split the community up. Other projects here at Apache are in deep, deep trouble just because of this! I've proposed the next-minor/next-major because I don't see it as a split. It is simply a group of people that put efforts to consolidate some of the features we have in trunk, while new work in trunk is being done. I am jumping on the expression be responsible for (which has been cut out by me). It sounds to me like a project manager's assignment. Please, let's not split responsability. Imho the 2 active trees rule we agreed in past is still valid: trunk is always the main active tree. We're waiting to close 2.3 so the next-minor can be started and only when next-minor will be closed we're going to open the next-major release. Agreed. I like sandboxes, I like 2.3 branch, I like trunk. I am fine with all that. Furthermore, I already wrote that the split could give our users the best results (3 releases in 6 months!!) and let everyone work on the preferred tree. I am very much in doubt that those 2 additional releases will be possible or at least are honest goals. And if they would become reality, I am fearing it would become impossible to merge branches again. What makes me suddenly think that people want to accelerate development and releases like mad when some month ago they didn't care much about releasing at all? (That said when the 2.3 release is not even through the door.) Let's at first work together on trunk and then decide to release (when time is due but quite soon). If there are developments which are not completed, ok. Lets disable them, or mark them as experimental, but release what we have. Then, let's move on. I am not opposing doing larger refactorings, or maybe even break features for a limited time. But let's move forward carefully nonetheless. So do we/you want to deliver standards, or do you want to chase them? Is that related to IMAP? Hopefully, this will be added soon. Unfortunately I guess that IMAP won't be included in next-minor or next-major, but we can only expect to be able to do some steps in that 2 releases (it would be *really* cool if we were able to put experimental unstable support for imap in next-major but this is not realistic to me). Yes, seems so. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES Server Nightly Build Report
I think the reverted message is given because at the last build the file was fixed in terms of tabs vs. spaces by our build script. Next time, gump sees the local change and reverts the file to the svn version. On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: I'd like to get familiar with the automatic build process. On which machine is it, and what script is running that? At first I thought it must be minotaur/people, but did not find it. Thanks, Bernd Hi Bernd, The only automatic thing ASF give us is GUMP. Under the gump folder in svn you can try to find more informations and you can also find the descriptor used to build james there. Unfortunately I don't know much more about this but this page that I keep monitored: http://vmgump.apache.org/gump/public/james-server/james-server/index.html This mail, instead, come from a Noel server. This is not something that ASF give to us. I also have a CI based on continuum where I build all of the james products using maven2. It is still experimental but I plan to give more visibility to other developers in future. Last time I worked on it I was trying to automatically produce our full website but including much more developers reports (like clover) and all the latest trunk instead of stable releases (that instead should be published on the official site). This does not work very well because of a bug in a maven plugin (I think) but I had no time to work more on this and I'm already happy with the automatic builds it give me now. Stefano - 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: JAMES Server Nightly Build Report
BTW, I didn't check: Are the builds now propagated to the download location? On 9/15/06, Bernd Fondermann [EMAIL PROTECTED] wrote: I think the reverted message is given because at the last build the file was fixed in terms of tabs vs. spaces by our build script. Next time, gump sees the local change and reverts the file to the svn version. On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: I'd like to get familiar with the automatic build process. On which machine is it, and what script is running that? At first I thought it must be minotaur/people, but did not find it. Thanks, Bernd Hi Bernd, The only automatic thing ASF give us is GUMP. Under the gump folder in svn you can try to find more informations and you can also find the descriptor used to build james there. Unfortunately I don't know much more about this but this page that I keep monitored: http://vmgump.apache.org/gump/public/james-server/james-server/index.html This mail, instead, come from a Noel server. This is not something that ASF give to us. I also have a CI based on continuum where I build all of the james products using maven2. It is still experimental but I plan to give more visibility to other developers in future. Last time I worked on it I was trying to automatically produce our full website but including much more developers reports (like clover) and all the latest trunk instead of stable releases (that instead should be published on the official site). This does not work very well because of a bug in a maven plugin (I think) but I had no time to work more on this and I'm already happy with the automatic builds it give me now. Stefano - 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: LONG JAMES v2.4 Road Map
Bernd Fondermann wrote: Let's at first work together on trunk and then decide to release (when time is due but quite soon). If there are developments which are not completed, ok. Lets disable them, or mark them as experimental, but release what we have. Then, let's move on. I am not opposing doing larger refactorings, or maybe even break features for a limited time. But let's move forward carefully nonetheless. Sorry, I think that with all this messages I'm not sure I understood your position. Norman and I agreed on a possible release plan for what we identified temporarily as next-major: We proposed to include everything we have in current trunk + what we are able to implement until the beginning of January choosing from a list of issues we already defined (and maybe something more, discussing it). In January we will branch and start consolidating things to be released (and I expect a first alpha/beta really soon after the branch). Vincenzo and Noel seems to agree on branching from 2.3 and backporting some few selected changes to make an interim release (If I understood it they would not do any new development in the branch, but only backporting+bugfixing). They have not published the list of this few issues, but maybe they will do this soon. Do you agree with one of these 2 plans? Have you, instead, a third proposal (possibly including expected date to branch/date to release and expected feature list)? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES Server Nightly Build Report
Bernd Fondermann wrote: BTW, I didn't check: Are the builds now propagated to the download location? As I wrote they are stalled on 29 august: http://people.apache.org/builds/james/nightly/bin/ Maybe there's something we committed that broke the build process, or simply something else on Noel machine. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES Server Nightly Build Report
Bernd Fondermann wrote: I think the reverted message is given because at the last build the file was fixed in terms of tabs vs. spaces by our build script. Next time, gump sees the local change and reverts the file to the svn version. I thought that, too, but Vincenzo fixes tab/spaces few days ago, and that message keep appearing in the builds... Not important at all.. I wanted only to let Noel knows something was probably wrong. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (JAMES-424) Invalid DATA for Message shows up in Headers in mailstore
Maybe i forget to say that this is the handling i prefer.. bye Norman Norman Maurer (JIRA) schrieb: [ http://issues.apache.org/jira/browse/JAMES-424?page=all ] Norman Maurer updated JAMES-424: Attachment: headerFix.diff With this diff it handles like qmail. Not sure what is the most RFC conform. Invalid DATA for Message shows up in Headers in mailstore - Key: JAMES-424 URL: http://issues.apache.org/jira/browse/JAMES-424 Project: James Issue Type: Improvement Components: MailStore MailRepository, SMTPServer Affects Versions: 2.2.0 Environment: WinXP Reporter: Scott Carr Priority: Minor Attachments: headerFix.diff If you open a connection to the server, and send in the following in the DATA for the message: This is a test . Then the data shows up in the headers instead of after the headers like it should. Here is what I recieved in the message: Return-Path: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1]) by QRGMAIN (JAMES SMTP Server 2.2.0) with SMTP ID 792 for [EMAIL PROTECTED]; Thu, 6 Oct 2005 21:40:21 -0500 (CDT) this is a test Date: Thu, 6 Oct 2005 21:40:21 -0500 (CDT) From: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Message-ID: [EMAIL PROTECTED] Notice where 'this is a test' appears in the message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
Hi Stefano, Hi Bernd, Bernd, this was by no means to be understood as an offense or anything against other active contributors on this project. This List is neither complete nor a concrete suggestion. Replace the Names in the Lists with A, B, C, and D. -1. Not agreed. I favor all the committers working together on the current release. We don't want to split the community up. Other projects here at Apache are in deep, deep trouble just because of this! I've proposed the next-minor/next-major because I don't see it as a split. It is simply a group of people that put efforts to consolidate some of the features we have in trunk, while new work in trunk is being done. I am jumping on the expression be responsible for (which has been cut out by me). It sounds to me like a project manager's assignment. Please, let's not split responsability. Well the only reason why I put this out is that it seems to me, that we have contributors, which have different viewpoints about what should be in the nexte major-/minor-/whatever release. I just wanted to *suggest* a way on how both parties can reach their particular goal. Nothing more. Imho the 2 active trees rule we agreed in past is still valid: trunk is always the main active tree. We're waiting to close 2.3 so the next-minor can be started and only when next-minor will be closed we're going to open the next-major release. Agreed. I like sandboxes, I like 2.3 branch, I like trunk. I am fine with all that. So it is true? We all do want the same? :) Furthermore, I already wrote that the split could give our users the best results (3 releases in 6 months!!) and let everyone work on the preferred tree. I am very much in doubt that those 2 additional releases will be possible or at least are honest goals. And if they would become reality, I am fearing it would become impossible to merge branches again. this is exactly why there should be certain assignments ( I did not use responsibilities with a purpose ;) ) I see two parties right now. One that ones to do the big thing, work on the next major release, and the other party that just wants to do minor/little changes, and release that. Which is fine. Why should the guys developing the main features decide on what goes into the minor changes and what does not. In fact they really do not care, do they? But others do. The other Party is interested into the main features, and wants the coming into james anywhere in the future. And they want to keep things stable. Watch all the important things, like JDK Compatibility, etc. This does not mean, that the Developers should start developing on 2 Branches! I see this a bit like the Linux Kernel Source Development. There are still Maintainers for the old 2.0 Kernel, and it has released some time ago. Why People still use the old Kernel? This is really beyond my scope. But what I am trying to say is, that there must be people out there still using the old Kernel, And they must have a reason for doing so. So the maintainer saw something great getting into the actual Kernel and thought, hey, We can use that also! So he went on, and backported the feature. Plain and simple. What is important, that people agreed, that the 2.0 Kernel is not developed anymore, and main development should go into the 2.4 and 2.6 kernel. So if it is clear that the Main development is being done on 3.0 (or whatever release number) and only some features wanted, are being backported into the next minor 2.4 release, than there should be no more problems. Or do I see this totally wrong? What makes me suddenly think that people want to accelerate development and releases like mad when some month ago they didn't care much about releasing at all? It is not acceleration. It is planning. It is Feedback to the Users. It is showing confidence. It is by no means about acceleration. As I said the dates are not to be put into concrete ( German saying, don't know if that maps to the english language ;) ). It just represents a goal, each contributer commited to. It just says, We plan to put this and this feature set into the release. If we see that we cannot meet the goals, we can still decide on leaving it out or move the release date. (That said when the 2.3 release is not even through the door.) exactly! Let's at first work together on trunk and then decide to release (when time is due but quite soon). How do you want that to be done, if you have developers that want to achieve different things? They will be vetoing changes etc. I do not even know if we are fine with sandboxes. At least I recall that there was some discussion about the topic. If there are developments which are not completed, ok. Lets disable them, or mark them as experimental, but release what we have. Then, let's move on. How does that conflict with my suggestion. You have an release. Then after the release, if there are bugs found, they are put into 2.3.1 or 2.3.2
Re: LONG JAMES v2.4 Road Map
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: Let's at first work together on trunk and then decide to release (when time is due but quite soon). If there are developments which are not completed, ok. Lets disable them, or mark them as experimental, but release what we have. Then, let's move on. I am not opposing doing larger refactorings, or maybe even break features for a limited time. But let's move forward carefully nonetheless. Sorry, I think that with all this messages I'm not sure I understood your position. Norman and I agreed on a possible release plan for what we identified temporarily as next-major: We proposed to include everything we have in current trunk + what we are able to implement until the beginning of January choosing from a list of issues we already defined (and maybe something more, discussing it). In January we will branch and start consolidating things to be released (and I expect a first alpha/beta really soon after the branch). I am totally fine with this. Vincenzo and Noel seems to agree on branching from 2.3 and backporting some few selected changes to make an interim release (If I understood it they would not do any new development in the branch, but only backporting+bugfixing). They have not published the list of this few issues, but maybe they will do this soon. I am OK with this, as you write it down theoretically. My objection is: I think it is unrealistic. There would very probably be changes on the patch branch which then would have to be forward-backported (immediatly or later or never?) to trunk. If it is only a digest of patches, that's OK. Do you agree with one of these 2 plans? Have you, instead, a third proposal (possibly including expected date to branch/date to release and expected feature list)? As I said, let's go forward with trunk. (Exception: make hotfixes to 2.3 and release that as 2.3.1 onward.) Then, at some time in the future, let's branch and release. Just like we did with 2.3! The date may be January. Maybe but unlikely: before January. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
On 9/15/06, Jürgen Hoffmann [EMAIL PROTECTED] wrote: Hi Stefano, Hi Bernd, this is exactly why there should be certain assignments ( I did not use responsibilities with a purpose ;) ) I see two parties right now. One that ones to do the big thing, work on the next major release, and the other party that just wants to do minor/little changes, and release that. Which is fine. Why should the guys developing the main features decide on what goes into the minor changes and what does not. In fact they really do not care, do they? I care. You are stating we have two parties, with two different goals? And you are seeing that as a problem for the project? Then you suggest those two parties would get around each other easiest by everyone doing there own thing? I don't think this is true. Instead: We have a bunch of people, having one goal, developing James. Everyone is having its own thoughts about reaching that goal. Everyone can commit code to trunk or supply patches. That's where it gets tricky. Because most code is liked, but some isn't, discussions raise up. You say: Discussion have to be fruitful. I say: Damn right! Those have to come to a conclusion. Conflicts have to be resolved. Not circumvented. This is what this project is essentially all about. Not about branches, timelines, vetoes, assignments, parties and whatnot. (I am not totally sure about parties. We should have a release party soon! ;-) ) What makes me suddenly think that people want to accelerate development and releases like mad when some month ago they didn't care much about releasing at all? It is not acceleration. It is planning. It is Feedback to the Users. It is showing confidence. It is by no means about acceleration. As I said the dates are not to be put into concrete ( German saying, don't know if that maps to the english language ;) ). It just represents a goal, each contributer commited to. It just says, We plan to put this and this feature set into the release. If we see that we cannot meet the goals, we can still decide on leaving it out or move the release date. Can't argue with you on this one. Exept that I cannot commit myself to anything but the next task. Sometimes not even that. I only can volunteer. And commit to svn of course. How do you want that to be done, if you have developers that want to achieve different things? They will be vetoing changes etc. I do not even know if we are fine with sandboxes. At least I recall that there was some discussion about the topic. A veto is there to be resolved, not to postpone or block changes. Anything else would is a misuse. So do we/you want to deliver standards, or do you want to chase them? Is that related to IMAP? Hopefully, this will be added soon. Unfortunately I guess that IMAP won't be included in next-minor or next-major, but we can only expect to be able to do some steps in that 2 releases (it would be *really* cool if we were able to put experimental unstable support for imap in next-major but this is not realistic to me). IMAP? This is not what I meant by *setting* a standard? It is a standard for Years. This is an example of chasing it ;) spf, surbl, greylisting, sieve, tight integration into existing business environments is what i am talking about. There is not even a solid Alias/Forward/Virtual Domain Implementation. As far as I can tell, James is far away from being a standalone Business Ready Mail Server Solution, As opposed to a very good Relaying, Mail Processing Solution. Well, this is a volunteer-driven project. I am all for that. Not opposing anything. But also not trading new features for quality. No bad fast hacking here. That is done somewhere else. (Well, I am not totally sure where, but must be somewhere ;-) ) I see a great future for the project by setting standards, because I feel that the E-Mail Standard is finding itself new. It is getting more and more important to fight spam and other email related problems without changing the existing infrastructure. I believe we can set Standards with James. Instead of chasing them. I like that. Let's keep the team working together and other will join us. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processor Flexibility Enhancements
+1 (will there be unit tests?) On 8/28/06, Noel J. Bergman [EMAIL PROTECTED] wrote: One of the things I'd like for us to do is change the SMTP handler to allow specifying the entry point for injecting messages into the pipeline, rather than the hardcoded root, and likewise for FetchMail. So messages coming from FetchMail might enter the pipeline in a different processor, and go through a different route before merging at a delivery point. Related to that, I'd like to enhance ToProcessor to allow: mailet class=ToProcessor from-attributesome.attr.name/from-attribute processorsome-default-processor/processor /mailet which would send the mail to the processor specified in the attribute, and to the named processor if the attribute isn't present. I might have that default processor set to send a warning to the administrator, and record the message into a holding repository for later respooling after the configuration error has been corrected. --- 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: JAMES v2.4 Road Map
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd When I say that it is only a number and I don't care of the number I mean *NOW* that we are planning a ROADMAP I don't care too much of the numbers. I agree that the number is really important for a release but I think we could simply decide the right number for our marketing purposes just before releasing it. Either way we need a way to talk each others about the different roadmaps/branches, so I thought at the next-minor, next-major labels... I'm trying to reduce the number of things to be discussed now to the minimum so to increase the probability that we come to some agreement on what to do. If anyone want to start a proposal for a new numbering, I suggest to do it as a separated thread, and I will add my ideas and I will vote about it. I already said that I'm not against the numbering proposed by Vincenzo (or your), and we discussed few times about the current 2.3 in terms of 3.0: we finally decided to use the 2.3 number. I think we should have no worry to make proposals and cast our votes. You know I really used few -1 in past, so don't think that every time I have a different idea it means I will veto it. I usually say I would probably veto this if I think I will do that and when I say I don't agree / I have a different idea it means that I will probably vote -0 and propose something alternative. ok, sure, fine. what's the point? I don't start that proposal now because I already wrote 2 proposals that are awaiting answers or actions by the people with karma so I don't want to put too many things in the in-progress list. trying to get through to it, but you are writing _lots_ of text, man! that's really eating up my time. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LONG JAMES v2.4 Road Map
Bernd Fondermann wrote: Do you agree with one of these 2 plans? Have you, instead, a third proposal (possibly including expected date to branch/date to release and expected feature list)? As I said, let's go forward with trunk. (Exception: make hotfixes to 2.3 and release that as 2.3.1 onward.) Then, at some time in the future, let's branch and release. Just like we did with 2.3! The date may be January. Maybe but unlikely: before January. Bernd So your idea perfectly matches what me and Norman would like to do. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version numbers (Was: LONG JAMES v2.4 Road Map)
Bernd Fondermann wrote: Stefano, Sorry, cannot parse this. You lost me way before you said that -1 should not be the next version number for James. I feel stupid. You are using too much words for me to cope with. Do you have 3 or 4 simple words summarizing your ideas? Are you saying that, the higher the next version number will be, the more substantial changes can be made? - That, I would agree upon. More easy: Let's do the changes first, we'll define the numbers later. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
