james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hane <ch...@hane.com>
Subject Re: [PROPOSAL] Release Plan
Date Tue, 10 Feb 2004 16:45:44 GMT

I doubt if I have any changes that I want to (or can - need to get 
approval) submit before you cut the next release.  I have only just now 
started to make changes for our internal use.  However, we will want to 
contribute the code back eventually.  When I create the patch files, I will 
attach them to a JIRA issue.

I have a couple of questions first.  Which version do you want me to work 
against?  I noticed that the Mailing list mailets were not in HEAD.  Are 
they going to be moved there during the merge?

Chris....

At 10:36 PM 2/9/2004, you 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: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message