Mailing-List: contact server-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "James Developers List" <server-dev@james.apache.org>
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <server-dev@james.apache.org>
Cc: =?us-ascii?Q?Andreas_Goggerle?= <andreas.goeggerle@pansoft.de>,
	"Chris Hane" <chris@itsolut.com>,
	"Josh Parreco" <josh@parreco.com>,
	"Alex Zhukov" <zhukov@ukrpost.net>
Subject: [PROPOSAL] Release Plan
Date: Mon, 9 Feb 2004 23:36:18 -0500
Message-ID: <NBBBJGEAGJAKLIDBKJOPIEFEHDAB.noel@devtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <4027BA95.5050603@lokitech.com>

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