Unfortunately, I am spotting a lot of submissions that didn't follow convention, and appear to have been "lost" on the mailing list. For example, it looks like the code from this message:
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg01721.html got lost in the shuffle, and it was even asked for by Danny and Serge. I can't find any indication that it was rejected, just lost. That is just an example of possibly lost code. In this case, I suspect that the code was "lost" because Blas Rodriguez Somoza <[EMAIL PROTECTED]> submitted DIFF files, and Serge had asked for complete files to go into the proposal section. Also on the subject of virtual hosts (one of the most frequent requests), here were two other submissions: http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02643.html http://www.mail-archive.com/james-dev@jakarta.apache.org/msg01718.html If you've submitted code for JAMES that hasn't been either incorporated, placed into proposals/ for others to view, or rejected, please don't take it personally. Consider updating it to match the current CVS tree, and re-submitting it. Not all code will be accepted, but you should at least find out why it is rejected. For example, the above referenced archive messages address virtual hosting in three different ways, sometimes with other items. Eventually, one way will be added to James. It may be one of the above, or it may be a completely new mechanism. Changes need to be made in the context of other changes that are planned. SUGGESTION: if you are working on an area, please start a discussion on the mailing list, and get feedback on your approach. Others may be working on the problem, too, and you may be able to merge efforts. Also, you may get feedback suggesting a change in your approach that works better in the overall picture. For example, a virtual hosting solution that works only with one type of user repository won't be accepted into the mainstream (although it could be put into a proposal), because we need a uniform mechanism that hides the repository implementation from the rest of James. (Plus we need it to properly work with the admin tools, such as they are.) Anyone who read the discussions on Mailet API v2 (and mailet logging) early this summer should understand that although discussion can involve heated disagreements, the discussion is about CODE and APPROACH, not about personalities. Steps: 1. Please make sure that the code is based upon the current CVS, not an older snapshot! 2. Please DESCRIBE the problem being solved, and HOW THE SUBMISSION WORKS. 3. Please submit a DIFF (cvs diff -u) in the case of a patch, and be prepared to submit a whole source kit if the decision is to make it a proposal before incorporating it into the mainstream code. 4. PLEASE *TAG* YOUR MESSAGE PROPERLY. The convention is to prefix the message with [PATCH] if you are submitting a patch/change. I don't know if we have a convention for marking code that isn't intended for the mainstream, yet, but you can clearly indicate that in your message. AND STILL TAG THE MESSAGE so that it doesn't get lost. Often the [PREFIX] is used to filter higher priority items, especially when people are very busy. If there are other [PREFIX] conventions of this nature, perhaps someone can fill us all in, so that they can be used properly. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
