james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [PROPOSAL] Release Plan
Date Tue, 10 Feb 2004 05:01:13 GMT
Noel J. Bergman wrote:
> *** 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.

Better idea, create an issue in JIRA and upload it as an attachment. :)

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

We had 6-10 changes an alpha release, so I think it's fine.  If we put 
out an emergency patch, then maybe not.  But more releases the better in 
my mind.

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

I understand that this isn't really that big of a deal.  There was some 
brief discussion (board or community?), and the conclusion was that 
copyright date didn't mean much... an archive to substantiate the date 
matters much more.

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

Whatever with the dates is fine with me.

> We also agree on leaving out the repository from the Mailet API in this next
> release.


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


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

Sure, that's the basic idea of "next".  The only reason I wouldn't is 
because if someone sees their issue as fixed "next," what does that tell 
them?  Usually we will know the next version number.

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

Yes, issue tracking is just tracking, not discussing.  Some people used 
Bugzilla to make statements, but I don't like that practice.

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

Well, you just pushed me back on the other side of the fence.  :)

If notices do not go to the mailing list, then someone has less 
motivation for posting arguments to the issue tracker.

Serge Knystautas
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message