james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Søren Hilmer ...@tefs.dk>
Subject Re: [PROPOSAL] Release Plan
Date Tue, 10 Feb 2004 08:27:14 GMT
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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

-- 
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message