Hi Noel, I had planned the following: Steve Short's JMX enhancements (i will finish testing them today) Andreas Goggerle's DSNBounce still needs some testing and documentation. Bug fix for the connectionLimit issue Finally I am working on exposing options on SMTP MAIL FROM and RCPT TO to be added as MailAttributes, so mailets can react on those, but i guess this will be for a future release.
--S�ren On Tuesday 10 February 2004 05:36, Noel J. Bergman wrote: > This is a bit long, so let me start right up front and ask whom has code > that they would like considered for the next James release? > > Vincenzo: S/MIME code? > Bayesian code? > Danny: Bayesian code? > Andreas Goggerle: DSNBounce mailet? > Chris Hane: Mailing List enhancements? > Craig Raw: I have your XMLVirtualUserTable code, thanks. :-) > Josh Parreco: SpamAssassin Mailet? > Alex Zhukov: Maildir > +------- > Consider |Enhanced JNDI/LDAP repository > After |Virtual domains > Release |SMTPACL > > Would you guys, and anyone else whom I have missed, please speak up and > make sure that we have your current patch. > > *** ONE TIME OFFER: Because of the recent Internet worm, the ASF has > installed new filters for the mail server. One of the victims is ZIP > format, which is currently banned as a virus payload. JAR and TAR files > are accepted. But we should also be able to accept patch and java files as > attachments. There have been problems with some of those attachments, and > I would like to resolve them. So please CC me just this one time when you > send your attachments to the list. I want to check the raw MIME, and see > why the server is filtering out the attachments. > > On to the release plan ... > > Serge wrote: > > We need to sort out releases quick... > > What's the next release we're planning? 2.2a17? > > Should we be that fine-grained in JIRA, or should we targeting actual > Release builds? I'm leaning towards the fine-grained approach, but that > would result in a lot of versions. Consider how many we put put in 2003 > alone. > > As for the next release, I am off-line again as I type this, so I can't > readily check the next release, but I thought it was 2.2.0a16. We have not > be lax over the past year getting out builds, but we do need to take stock, > consolidate, and put out a Release. I expect that is what will come from > the merger, so ... > > What I have on my list for Release $NEXT (version 2.2 or 3.0, I don't > particularly care what label we give it), are: > > - Adoption of Apache Software License v2 > > This is done, but with a caveat. When we replace the faux short form with > the full ASL v1.1 a year or so back, we "lost" original copyright dates. > Similarly, all of the ASL v2.0 instances in the MAIN branch use 2000-2004. > I am in the process of correcting the Mailet API to use 1999-2004 based > upon the presence of internal dates within the files. More importantly, > things such as FetchMail should be changed to 2003-2004, so that the > copyright date is not EARLIER than the code. > > Anyone who has the time to grab a directory or few, look at the CVS history > and/or check for a date in the file, and amend the copyright date is most > welcome to do so! :-) > > According to http://www.apache.org/dev/apply-license.html, we also need to > put a copy of the License into the CVS and SVN root, and provide a NOTICE > file. > > - Merger of branch_2_1_fcs with MAIN > > In progress. As soon as the Mailet API can be checked in (I am unlikely to > be able to do that before Wed night -- I don't know if anyone else has > time), the build will help identify things to change. There may be a few > minor iterations getting the Mailet API to a point we are all happy with. > > Danny and I agree on moving the date classes into the Mailet API as part of > the merger. If we could, I think I would like to hide SimplifiedDateFormat > and SynchronizedDateFormat, and expose just the three RFC related classes, > but that isn't a critical issue. > > We also agree on leaving out the repository from the Mailet API in this > next release. > > That leaves us with: > > String getName(); > void setName(String name); > void setLastUpdated(Date date); > Date getLastUpdated(); > > We could debate them, but with the exception of using getName for > diagnostic purposes, these all relate to the repository interface, so what > would be the point? Therefore, I believe that we can agree to leave these > out of the Mailet API for this release. > > Danny and I just discussed if getName should be public, but in retrospect, > I am reluctant to add getName as a public API. The reason is that "name" > is probably not the best label for a unique ID/repository key, and also I > am wondering if we should expose it as a Mail Attribute, even though the > James implementation would special case that key rather than store it in > the attributes set. At the least, if we are going to add it to the public > API, we should give it a name we want to live with, and deprecate getName() > internally. > > Basically, I'd like to make as little change in the Mailet API as possible > until after this Release. > > Feature-wise, we would: > > - Clean up RemoteDelivery looping (probably done during the merger) > - New Virtual User mailets based upon Craig Raw's > contribution, plus additional enhancements > - Refactor RemoteDelivery into a generic base class and a > specialized subclass. > - other contributions (see above) > - change our JavaMail use to reduce memory footprint > - misc. other changes, e.g., dnsjava update > > These are all post-merger, pre-release changes. > > This Release Plan would put us onto the current Avalon code, incorporate > the majority of pluggable enhancements, leave us with a unified codebase > for the next round of enhancements, and give us a good solid Release. > > The next round of enhancements that I believe should go into the release > after this include: > > - JNDI > - enhanced version of SMTPACL > - IMAP (between Jason's work and Maildir, Darrell and others > should have a suitable persistent store > - Sieve > > > We should create something as the next release (even if we just name > > it release "Next"), and mark this as fixed for that. > > Is it possible to have a version called "sc" ("source control") or > whatever, and then move issues to the actual release when we make one? > > I'd also like to start using JIRA to record (not to discuss) the Roadmap. > But I also notice, as I am typing this in the car, how nice e-mail is when > you are off-line. :-) > > > right now JIRA is sending emails to each developer... > > should I change notices to instead go to the server-dev > > mailing list? > > I would be in favor of that change, unless you can think of a reason > otherwise. > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- S�ren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 �byh�j Email: soren.hilmer <at> tietoenator.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
