james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [PROPOSAL] Release Plan
Date Tue, 10 Feb 2004 22:10:41 GMT
Noel J. Bergman wrote:

Hi Noel,

Thanks for taking the time to write this up.

>
> 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.

I think being fine grained is good. For issue reporting knowing exactly what
build an issue relates to is clearly useful. This requires all of the builds
to be entered into JIRA. Declaring the next release in JIRA (eg: 2.2.0) is
useful too as it allows us to identify issues that need to be fixed and
tasks that must be accomplished prior to each release.

We can declare issues and tasks with fix targets of a build, such as
2.2.0a16 or the release - 2.2.0, or Undefined, which is making no commitment
to any milestone.

JIRA is flexible enough to allow any targets to be changed if we change our
minds, or goof-up as I did yesterday! All in all, JIRA should help us by
giving visibility to the issues we have, what we are trying to accomplish
and what is required to get to each milestone.

> 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.

Agreed.

> 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!  :-)

We might want to record who is grabbing which directories to avoid
duplication of effort. In JIRA?

> 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.
Yep. Else we'll never get it out!
>
> 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

Just to confirm, "the release after this" means a subsequent release such as
2.2.1 right?

> > 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?

As discussed previously, I feel we should track issues against the builds
they pertain to, such as 2.2.0a15, and record actual fixes against the
builds which contain them. This way we have a concrete record of our
progress.

When we create a build, in JIRA we should mark that build as released and
create a new unreleased build as the next milestone. One day a build
milestone will be good enough to be a release. We will then rename the
already created next build milestone as the first build milestone for the
next release (remembering to also have a virtual party).

> I'd also like to start using JIRA to record (not to discuss)
> the Roadmap.

That would be cool.

> 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.

I think we need nail down how we use JIRA and get used to it. It is possible
for users to add watches to issues so that they get notified when an issue
changes. I don't see an option for adding watches on a project wide level.
If there is such an option, this would give each user the ability to opt-in
to notifications on an issue or project wide basis.

Do we want to start a new thread on how to best use JIRA to avoid polluting
this one? I'ld be happy to record the results in the (new) Wiki.

-- Steve


---------------------------------------------------------------------
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